[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: W-15 Delegation and Intermediaries - specific suggestions
The chairs are "eager" to move this work item forward, so now that I have a slightly better sense (in my head at least) of what the SAML 2.0 SSO protocol might look like, I propose a bit more detail. None of this accounts for or offers a resolution to the questions around how to synch up SAML and ID-FF SSO, which have some low-level differences. I will say that this work item isn't going to get very far in certain directions without a signed assertion delivered during SSO. Whether that leads to multiple signatures (and whether that's realistically possible) I leave for the reader. 1. Lifetime RL Bob already mentioned changing the assertion validity to represent the token/session lifetime instead of the bearer delivery window. As of now, about the only loss of function to that I see is the IdP having some control over that window instead of leaving it to the SP. A related change would be adding the ability to request the SSO assertion with a specific validity lifetime, which probably has some relation to the session question. As it stands now, without an explicit session construct presented (so far), I would be inclined to say that the lifetime of a SSO assertion should correspond to the session length indicated to the SP by the IdP (obviating the need for the ID-FF <ReauthenticateOnOrAfter> element). 2. SP Impersonation It should be possible for an SP named in the assertion (an Audience) to go back to the IdP and exchange that assertion for a new one that asserts the SP's right to authenticate to another SP as the original principal. This would be subject to policy set for the principal. I don't think (but could be wrong) that any flags or bits are really needed in the request or assertion to control this if the SAML authority is the exchange point. I also think this is probably just an AuthnRequest SOAP message with the original assertion included somehow. Maybe WSS, but I'm inclined to say it might fit better as data within the request, since it's not really authenticating the SP. The signed assertion returned would name the new SP as the relying party, probably would have a lifetime within that of the original, and if a privacy-preserving NameIdentifier was in use, could be newly generated or appropriately protected. For example, it could be a federated identifier shared between the IdP and the new SP, encrypted so as not to expose it to the original SP. It could also (and probably should) have a stronger subject confirmation like holder-of-key, so the original SP could sign it into messages to the new SP or authenticate with X.509 to prove the confirmation to the new SP. As described, this would be simple impersonation. If we wanted to do a bit more work, delegation could be introduced to expose both the identity of the principal and of the proxying SP. Related to this, we might want to standardize a control condition to limit the repeating of this exchange process (preventing it from hopping back another link from the new SP). We want to keep this all easy to implement and understand. That's SAML's strong suit, and I don't propose to suddenly make it a hugely complicated mess. 3. SSO with stronger SubjectConfirmation Several people have noted that there are cases where doing SSO without using bearer confirmation make sense. The Kerberos discussions are one such case. Another I can think of that may or may not be of interest is browsers with X.509 certs, with the public key bound in as the confirmation key. The use case is to validate the cert at the SP by proxy through the signature of the IdP around the key in the assertion. This is especially interesting with shorter-lived certs that might be generated on the fly for the browser perhaps with Kerberos in the mix (see Michigan's KX509 work): http://www.nsf-middleware.org/documentation/NMI-R2/0/KX509KCA/ In general, any time the client can prove possession of a key to both the IdP and the SP (whether over HTTP, or SOAP, or something else), it can go into the SSO assertion so we should spec that. I think this can be generically described around a single AuthnRequest message delivered to the IdP over various bindings to address the non-browser use cases. Some will result in a bearer assertion and some not, but I think it all works. 4. Non-SAML tokens delivered during SSO or AttributeQuery RL Bob's second bullet I think can be addressed by standardizing the carriage of some token formats as SAML attributes, base64 encoded in some cases, obviously. But we should pick standardized names for Kerberos tickets and the like. I don't know enough technical detail about Kerberos at the lowest level to know exactly how this will work, or what exactly has to be passed in the attribute to permit an SP to authenticate to a Kerberized service. I am prepared to help produce concrete spec for these proposals once the designs or variants of them are accepted. I've got a lot of work items though, and some of this pushes the technical envelope for me anyway, so help would be welcome. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]