Feature Proposal: User masquerading while keeping your real identity

Preface

This proposal is actually about an enhancement to TWiki::Access::checkAccessPermission() and TWiki::Users::IsInList(). But simply explaining the exact nature of the enhancement wouldn't make sense a lot for most people. So the title and the description of this proposal is focusing on a use case of the enhancement - user masquerading.

Motivation

It's handy if you can access TWiki on behalf of somebody else with a trace of your real identity rather than completely becoming a different user TWiki-wise. For example, your login ID would be "REAL_ID/MASQUERADE_ID" while you are acting on behalf of MASQUERADE_ID.

Description and Documentation

There are a few benefits compared to completely becoming a different user.

• The true actor is recorded in the log clearly. It's possible to record masquerading in a log entry, but then, it might not be obvious which action is taken under the masquerade.
• A masquerading can be in effect at some places while it's not at other places. For example, a masquerading takes effect in one web but not the others. This is possible because TWiki knows both the real and masquerade IDs of the current user and can decide how to deal with those when needed rather than doing masquerading at an early stage.
• You are still authenticated as yourself. Masquerading is another layer.

There's more to it especially for a large TWiki site. Usually, TWiki administrators are the members of TWikiAdminGroup and can do anything on the TWiki site. This is like doing everything as root on Unix and doing everything as an administrator account on Windows, which is not regarded as a good practice now. TWiki Administrators are likely to be TWiki users and they shouldn't have privilege while they are using TWiki. They should exercise their privilege only when they administer. For that, instead of putting TWiki administrators into TWikiAdminGroup, allowing them to act on behalf of "admin" is desirable assuming "admin" is a TWikiAdminGroup member.

A custom TWiki::Users::UserMapping class can do this for the most part, but the current TWiki::Users gets in the way to masquerade completely. Specifically, a user wiki name on e.g. ALLOWWEBVIEW cannot match a masquerading user because TWiki::Users::isInList() compare the current user's CUID and CUIDs in a user list using the "eq" operator.

A bit of enhancement is required in the TWiki core.

Examples

Here's one concrete scenario I have in mind.

A masquerade ID is provided by TWIKI_ON_BEHALF_OF cookie. The login handler recognizes the cookie and makes the login ID "REAL_ID/MASQUERADE_ID"

Impact

Implementation

Changes to the following functions make it possible.

• core/lib/TWiki/Access.pm
  • checkAccessPermission()
• core/lib/TWiki/Users.pm
  • isInList()
  • isAdmin()
  • isEquivalentCUIDs() (new)

This ultimately boiled down to how TWiki::Access::checkAccessPermission() behaves. Two methods called from checkAccessPermission() matter - isInList() and isAdmin() of the TWiki::Users class. Because user masquerading is web and topic dependent, isInList() and isAdmin() need to take $topic and $web arguments. This is the change made to checkAccessPermission().

isInList() and isAdmin() in TWiki::Users calls methods of the same name in the user mapping handler. Those method calls need to have $topic and $web as additional arguments.

TWiki::Users::isAdmin() caches results obtained from isAdmin() of the user mapping handler, which needs to be modified. The cache needs to have $web and $topic into consideration.

"$identCUID eq $cUID" in TWiki::Users::isInList() gets in the way to handle "REAL_ID/MASQUERADE_ID" as equivalent to "MASQUERADE_ID". Replacing that with "$this->isEquivalentCUIDs($cUID, $identCUID)" and then defining isEquivalentCUIDs() properly is needed.

Then, isEquivalentCUIDs() would check if the user mapping handler for $cUID has the isEquivalentCUIDs method, in which case it calls it. Otherwise, "$identCUID eq $cUID" becomes the return value of the function.

Actually, this is not enough. Because a masquerading taking effect or not may depend on situation. For example, you may define web owners in one way or another and you may want to allow the owners to act on behalf of another person in the web. But you don't allow the masquerading in other webs.

As such, isEquivalentCUIDs() in the user mapping handler needs to take topic and web as its arguments. This means TWiki::Users::isEquivalentCUIDs() needs to take those arguments, which means TWiki::Users::isInList() needs to take the topic and web arguments, which means TWiki::Access::checkAccessPermission() needs to hand the topic and web arguments to TWiki::Users::isInList().

These changes don't affect existing login handlers and user mapping handlers.

-- Contributors: HideyoImazu - 2012-06-28

Discussion

May be I miss something, but how about creating a custom TWiki::UserMapping class? This is what user mapping is for, change the ID of a user to something else.

-- PeterThoeny - 2012-07-01

I wasn't clear enough. User masquerading is implemented in a user mapping handler. But the current behavior of TWiki::Users::IsInList() prevents it from working thoroughly. A small enhancement is needed there, which I added to the tail end of the Description section.

-- HideyoImazu - 2012-07-04

Looks good.

-- PeterThoeny - 2012-07-04

This is now accepted by 7 days feedback period.

-- PeterThoeny - 2012-07-11