[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-dev
Subject:    Re: Authentication Method defaulting in SAML1 and SAML2
From:       "Cantor, Scott" <cantor.2 () osu ! edu>
Date:       2014-03-11 16:47:33
Message-ID: CF44B5A1.4B618%cantor.2 () osu ! edu
[Download RAW message or body]

On 3/11/14, 12:17 PM, "Rod Widdowson" <rdw@steadingsoftware.com> wrote:
>
>I'm guessing that this is because the AuthnContextClassRef is a real thing
>which may crop up in SAML2 Authentication requests hence the generic SAML2
>AuthN flows need to be able to deal with them.  If so my apologies for not
>internalizing this earlier.

Yeah, essentially. It was so that the inputs to the flow selector would
use custom principal types appropriate to the eventual representation of
how authentication happened that has to be fed back in when the assertion
is built.

>I am also guessing that the reason that this generically that this is a
>List<Principal> and not a Principal is that we may want to try a cascade
>of
>authentication mechanisms if one fails.

Well, it's a precedence list, but yeah, in practice obviously that doesn't
make much sense unless failover is possible. There is another case though,
and that's if you have an active method Foo, you could reuse Foo for SSO
even if it's second in the list.

>So the follow up question is
>whether we want to pass this through to the parsing of the
>defaultAuthenticationMethod inside <RelyingParty> and allow a series of
>space-separated strings to be configured in V3.  Absent someone defining
>their own authentication method with a space in its name, this would be a
>forward compatible change...

Hadn't decided, but I did think about it. Probably what we should do is
just leave it single for now and we can decide later to either do that, or
add a new construct for it.

-- Scott


--
To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net
[prev in list] [next in list] [prev in thread] [next in thread]