There really is no big secret to how this stuff is possible - at some point in time an offline user will be online, and during that time instead of ceding their credentials to the service in the sky (or worse, it happens without choice), they spend the time granting access specific to the service that needs access.Pete continues
I have to agree with Kim on the notion of impersonation - at no time should anybody give the required access level for impersonation of themselves, on or offline.Pete is agreeing with Kim's assertion that the (as yet undefined?) WS-Trust delegation mechanism was preferable to Liberty Alliance's ID-WSF 'impersonation' mechanism.
Minor nitpick, quibble really, I hesitate to bring it up even.
ID-WSF in no way uses an impersonation model. The identity of the requestor is made explicit in any call to a service for some slice of a user's identity, and (in most cases) distinct from that of the user in question. The requestor acts in their own identity, and does not pretend to be something else, i.e. the user. So, like Rich Little at a funeral, no impersonation.
Liberty's model assumes that, as per Pete above, that the user will have previously defined access rules that state 'Service X can do operation Y to identity Z' (importantly, whilst still allowing for the user to add/clarify such policy at run-time).
But, instead of the request carrying a token created by the user (and of course presumably signed by them as well) expressing the delegation rights of the requestor, these access rights are assumed to be stored at the identity service itself. The user specifies policy for Identity Z where Z is held, not at any provider who might request it (privacy alarms sounding here).
As far as I can tell, Kim's misunderstanding is based on his interpretation of 'on behalf of' as used by Eve in a chat with Jim Kobelius. Kim must think that this means impersonation. As Eve is currently vacationing, I'll take the "liberty" of clarifying on her behalf (please note that both our identies were used) - it doesn't.
No comments:
Post a Comment