Hi.
>> BTW: I never got feedback about the files i attached to JIRA (or I missed
>> it).
>
> Ah yes, I forgot to add that to this thread last night. I reviewed the
> files and they were along the line of what I was thinking initially - thanks
> very much for contributing. However, from what I remember late last night
> (and if I'm wrong, please correct me), the files you attached didn't address
> the PrincipalsCollection issue - nothing wrong with that of course, I'm just
> checking for clarity. See below...
I did address the issue. But I'm not sure, if I did it right.
That's why there are @todo lines in the javadoc comments to
AssumeIdentitySubject.getPrincipals(). :-)
> Storing the assumed identity in the session is perfectly fine as I
> recommended originally and as your uploaded files do, but I wasn't thinking
> about the PrincipalCollection at the time. Now the question is _should_ the
> assumedIdentity go in the 'owning' user's principals collection or, when
> calling getPrincipals(), a new PrincipalCollection is returned that wraps
> the assumed identity + the existing PrincipalCollection?
>
> I ask because the former approach requires methods to prepend the assumed
> identity to the existing PrincipalCollection instead of creating a new
> instance. Methods like MutablePrincipalCollection.set( index, realmName,
> value ) or MutablePrincipalCollection.add( realmName, value) - that kind of
> thing.
----8<--------8<--------8<--------8<--------8<--------8<----
> This might have repercussions for RememberMe: the PrincipalCollection is
> serialized and encrypted as a cookie. If the end-user does not log out, and
> they come back and RememberMe is enabled, should it also remember the
> assumed identity? That would happen if we modified the original user's
> PrincipalCollection.
>
> It would not happen though if we create a temporary instance that wraps the
> assumed identity + the original Collection, and then return that temporary
> instance from the getPrincipals() call during the life of the owning
> session. It would not be remembered since the assumed identity would not be
> in the RememberMe cookie and when the owning user's session dies, so does
> the assumedIdentity association.
I thought, that's what I did. But I am not sure, if I did it right as
I face issues with relinquishing (funny word...) the assumed identity.
(I decided to go on with other issues first, as logging out does the
trick).
<code>
public PrincipalCollection getPrincipals() {
if (getAssumedPrincipal() == null) return
decoratedSubject.getPrincipals();
PrincipalCollection authPrincipals =
decoratedSubject.getPrincipals();
String realmName =
authPrincipals.getRealmNames().iterator().next();
SimplePrincipalCollection spc = new SimplePrincipalCollection();
spc.add(getAssumedPrincipal(), realmName);
spc.addAll(authPrincipals);
return spc;
}
</code>
>> For the other methods, I'd say, just leave them.
>
>
> I'm inclined to agree. It would certainly make this implementation effort
> easier :)
----8<--------8<--------8<--------8<--------8<--------8<----
> Yep, switchUser/substituteUser functionality would probably require proper
> stack-like retention of state (session, authentication state, and anything
> else). I'm not sure that users even care about this either and I don't
> think I'm going to worry about it unless someone asks for it ;)
I daresay that there are other items to be taken care of for the 1.0 release.
I assume that the most important use case is for
supporters/administrators to help a user out, and this solution solves
that.
>> As the difference is so subtle (to me), I'd still recommend the "act
>> on behalf of" naming, which IMHO makes it easier to distinguish.
>> But beware: I'm no English native speaker, so my perception of
>> "subtleties" may be completely out of balance ;-)
>
>
> No disrespect of course, but I view them almost the same. I think
> 'actOnBehalfOf' is a little vague as to what actually is supposed to happen,
> where I think 'assumeIdentity' is a little more focused on its intentions.
> Just my opinion though...
Thanks for reflecting on it. As I'm currently reading about and
working on identity management, it could well be that I'm just over
sensitive. The terminology has so many facets, that experts disagree
to a certain amount. Even the people in our small team working on the
topic have (slightly) different views of the meaning of "identity".
The notion I especially like about "actOnBehalfOf" is that there are
two entities involved (e.g. the support guy resets the password on
behalf of the user).
A final idea would be: ("loginAs" or rather) "authenticateAs"
By the way: What was the outcome of the poll? Which naming did the
others prefer?
But after all: "What's in a name?"
As long as the API documentation precisely describes what is going on,
the subtle differences make no big deal, I guess.
Cheers,
DJ
