Specify a default authentication context in Relying Party config

[Cantor, Scott]

On 11/30/15, 5:53 PM, "users on behalf of Michael A Grady" <users-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:



>>>How can I set a particular default authentication context in relying-party.xml? I was trying to use the property p:defaultAuthenticationContexts, modeling after the examples for setting p:nameIDFormatPrecedence, but that raises an error, because I hadn't noticed at first that the defaultAuthenticationContexts list values need to be of type 'AuthnContextClassRefPrincipal', not simple string values.

Actually, you have me confused here. I don't see any property setter by that name, so I would not expect that to work. You should be getting a "no property or setter" error or something along that line. I didn't look when you asked, I just assumed you were going by the javadoc on that.

The public API for this is the one you're asking about now.

>Can't seem to get that quite right, but then (rediscovered) that there is one example in:
>
>  https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSelection
>
>that references the property 'p:defaultAuthenticationMethods' (aligning with the v2 defaultAuthenticationMethod)

Yes. I left it in place so there would be a way to specify methods "abstractly" as opposed to concretely (authenticationFlows). The old schema just injects a single instance into the collection.

> that can be used with (at least) the SAML2 SSO profile. That property doesn't seem to be documented anywhere else at this time (it is mentioned in the v2 to v3 config changes, but not as the plural form).

It's in the javadoc, that's the only official API documentation. Examples are fine, but they're not the reference.

> Is that a property that is intended to "stick around", and thus ok to use?

If it's in an API class, it's guaranteed to be around until 4.0.

>So I can get the behavior I want with:
>
>      <bean id="SAML2.SSO.requireDuo" parent="SAML2.SSO" p:defaultAuthenticationMethods="http://www.duosecurity.com/" />

The property doesn't take strings. If that's working, there would have to be some kind of auto-conversion happening. Spring is weird I guess. Maybe it can auto-convert if the underlying collection type is of an object type that itself has a string-based constructor (and this one does). I don't know how reliable that is. I think if you wanted to be 100% certain it can't break, you'd have to supply beans of the appropriate type (inheriting from shibboleth.SAML2AuthnContextClassRef in this case).

-- Scott