[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] W-15 Delegation and Intermediaries - specificsuggestions
> 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. Well, I think it's clear that most intermediate-backend scenarios will need signed objects. Whether that's a signed response or a signed assertion is an interesting question. I feel as though our response object is finding use as what I would call a "service ticket" in Kerberos terms (third-party provides access to specific service for client), but that we may think that an assertion should be able to fill that role, independent of embedding in a SAML-protocol object. The Liberty spin on assertion is reflective of this. So I think we need to figure this out. > 1. Lifetime So, just to be clear, the reason why lifetime is an issue is that the intermediate will probably need to use an assertion containing an authentication statement to interact with either the backend or a SAML authority, and will want to be able to do that at arbitrary times after initial authentication. This is similar to, but perhaps not identical to, the requirement to express lifetime for session purposes, as Scott mentions. As far as I'm concerned, a single lifetime is sufficient for both. > 2. SP Impersonation As I think I've said before, there is an appealing use case of achieving impersonation in the intermediate-backend protocol by having the intermediate simply pass the SAML response object (which the intermediate received as part of browser profile operation) to the backend as evidence for the desired impersonation. Obviously this would require a mechanism to pass the response in the relevant protocol (and this doesn't mean SOAP only). I think this would be acceptable in many common trust arrangements between intermediate and backend, assuming the response is signed, given that the response specifies subject, intermediate (as recipient or audience), validity and issue times. The work item would be describing this flow precisely and the security considerations related to it. The main appeal is that it requires no change at all to any existing schema or profile. > 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. Scott describes new mechanisms to give the intermediate a SAML object that would be more suited to achieving impersonation. One way of thinking about this is permitting different management of the policy regarding the intermediate's ability to impersonate. In the case I describe above, the backend gets info from the intermediate saying "I'm the intermediate, here's a SAML response I got from the user, please let me impersonate the user", and the backend has to evaluate whether the intermediate is permitted to do this. A method whereby the intermediate trades in the user's SAML response for something else permits its info to the backend to instead be "I'm the intermediate, here's an assertion from an authority saying that I can impersonate this user". The appeal in this is that the backend can just accept this and not have to be responsible for the evaluating the intermediate's impersonation capability.