[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] n--1 type federation and more SAML 2.0 questions
> My understanding is, that in general, transient federation should be used to > handle group like access, where multiple IdP users can be mapped then to a > single SP user ... In that case, I read from the standard, that attribute > statements should be used for transferring the information required by the > SP for finding the correct SP user ... That's one use case, it's not the only one. Transients are best thought of as "I don't want to use a NameID but I have to for Logout to be possible". > The agreement, > what attributes to use and how to interpret them is done out of band, right > (please correct me if I am wrong)? Pretty much, but there are good ways and bad ways and much existing practice in some communities. > My main question, however, is for the persistent identifiers. Let us assume > I have either 2 IdP accounts or 1 account each at 2 IdPs ... which I want to > map to a single SP account. Does the SAML standard define, whether it shall > be possible to have n--1 mappings of IdP users (respectively persistent Ids) > to SP users? Or would we assume, that the latest mapping wins, and only a > single persistent identifier is mapped to the SP user? Out of scope. What you do behind the scenes is up to you. > In case we have multiple to one mappings at the SPs, what would be the > desired behavior for deferation? I again assume, that calling a defederate > endpoint should only defederate the single mapping for the currently used > opaque identifier, is this correct? On the wire, you defederate a specific identifier, and that's all it says. > Another stupid question regarding conformance modes and interoperability. > Does each and every IdP and SP require to support the ECP modes and PAOS? Each implementation, supposedly. > If yes, why is that the case? If no, how comes that in the Liberty Interop > matrix, > <http://www.projectliberty.org/liberty_interoperable/interoperable_products/ > saml_2_0_test_procedure_v3_0_full_matrix_product_table> ), the IBM and RSA > products achieved IdP and SP conformance modes, but do NOT support the ECP > conformance mode? That would imply that Liberty conformance and SAML conformance are not the same thing. > I understand that I can specify in the AuthNRequest a list of authentication > context classes deemed acceptable by a certain SP. Is now this > "PreviousSession" always implicitly included in that list? I could not find > any information on that in the standard. I think that's possibly an errata issue, What seems to happen is that for most impls, it's implicit because the resulting assertions don't usually assert it (see recent discussion on AuthnInstant). > If the SP specifies a list of 3 authentication context classes, it will > still only receive "PreviousSession" if SSO took place ... how does the SP > in that case know, what method was previously used for setting up the user > context at the IdP? That's why it normally isn't asserted. We use it internally as a hook for ForceAuthn usage just to be consistent within our handler config, but as far as using it explicitly, I don't think so. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]