[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Summary of players in SSO and client/proxy use cases
If it helps frame discussion and perhaps scoping, I tried to break down the inputs Ron proposed by use case (or my interpretation of them anyway). ------ AuthnRequest in the "traditional" SSO/ID-FF use case: 1. the entity requesting the assertion SP, <Issuer>, may be authenticated using simple message signature or by passing message signed by WSS via a SOAP intermediary, or could be unauthenticated because of nature of SSO protocol. 2. the entities able to use the returned assertion. Default is for this to be only the immediate sender, can authenticate via any means supported by chosen binding. Could specify other entities (such as the SP) as a means of getting an impersonation assertion during SSO, but would need a way of implicitly or explicitly including the message sender in this list since the typical case is for an assertion usable only by message sender as a bearer token. 3. the subject of the returned assertion. The immediate sender, can authenticate via any supported means. Requester does not know who the subject is in most cases, but could imagine that during a reauthentication operation, the SP might explicitly reference the subject for some reason. 4. the target services (audiences?) at which the assertion may be used By default, the requester (SP) is one. Others as specified to constrain forwardability of assertion. ------ AuthnRequest in the "client" or "proxy" use cases presented by the Kerberos and SOAP solution proposals: 1. the entity requesting the assertion <Issuer>, can authenticate via any means supported by binding. 2. the entities able to use the returned assertion. Default is for this to be the sender/requester, can authenticate via any means supported by binding. Could specify other entities as a means of getting an assertion usable at other hops without extra work but this is just an optimization. 3. the subject of the returned assertion. Default is for this to be the immediate sender/requester, can authenticate via any supported means. But could be an arbitrary subject if the requester is asking to impersonate subject. Permission to do this may depend on presenting additional security tokens of various sorts that demonstrate relationship to subject. Need to work through examples of this as well as how impersonation would be expressed. 4. the target services (audiences?) at which the assertion may be used As specified by requester. -- Scott, hoping I'm helping with all these emails and not just making a mess
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]