RE: [saml-dev] n--1 type federation and more SAML 2.0 questions

["Scott Cantor" <cantor.2@osu.edu>]

> 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