On Fri, Jan 30, 2009 at 3:05 AM, Daniel J. Lauk <[email protected]>wrote:
> Hi Les. > > 2009/1/30 Les Hazlewood <[email protected]>: > > On second thought, maybe 'assumeIdentity' is just that - the Principal is > > assumed and everything else about 'bob's Subject state (session, > > authentication, etc) is retained. > > That's what I'd suggest and what I implemented. > 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... > >> subject.getPrincipals() > > If I understood correctly, the first item in the PrincipalCollection > is the main Principal (i.e. the one used with authorization). > So, I figured, the assumed identity's principal has to be prepended to > the original PrincipalCollection. 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. 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. > For the other methods, I'd say, just leave them. I'm inclined to agree. It would certainly make this implementation effort easier :) > The 'stack like' functionality might be cause for a separate feature in > the > > future, say 'switchUser' to mimic a full stack-like behavior like what I > > outlined originally, if users actually desire such a feature. > > That's what "substitute user" (Unix-ish) would be, right? > Reminding you of some previous discussion, I think this is what we > agreed on (or stopped going on discussing): 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 ;) All we do is "assume the identity of another subject". We do not > "substitute the user" in their entirety. > 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... > Feedback is still welcome ;) > > You asked for it... ;-) > It is much appreciated :) Thanks! Regards, Les
