Need to modify AuthnContextClassRef in ExternalAuth

[Stefan Santesson]

Hmm,

There is obviously something about this that I don’t understand to the degree I should have.

I do have multiple supportedPrincipals declared in my auth flow:

<bean id="authn/External" parent="shibboleth.AuthenticationFlow"
            p:nonBrowserSupported="false" 
            p:passiveAuthenticationSupported="false"
            p:forcedAuthenticationSupported="true">
            <property name="supportedPrincipals">
                <util:list>
                    <bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="http://id.elegnamnden.se/loa/1.0/loa2-sigmessage"/>
                    <bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="http://id.elegnamnden.se/loa/1.0/loa3-sigmessage"/>
                    <bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="http://id.elegnamnden.se/loa/1.0/loa4-sigmessage"/>
                </util:list>
            </property>
        </bean>



In my Java code I set the principal returned like this:

Principal principal = new UsernamePrincipal(userName);
            Subject subj = new Subject();
            subj.getPrincipals().add(principal);



And that’s it.

The effect of this is that if e,g, "http://id.elegnamnden.se/loa/1.0/loa2-sigmessage” is requested, then this is the context class ref returned in the assertion, given that authentication succeeded.
If the request contains no context class ref, then my default setting picks the default class ref and then that is the one returned.

How can I accept a request with no requested class ref, and determine in the ExternalAuthn servlet, which should be returned?

/Stefan








On 14/12/15 15:37, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

>On 12/14/15, 9:04 AM, "users on behalf of Stefan Santesson" <users-bounces at shibboleth.net on behalf of stefan at aaa-sec.com> wrote:
>
>
>>
>>I was told that this feature was deliberately removed from V3, that you needed to commit to one class ref before selecting authentication flow and then stick to that and return this class ref in the assertion.
>
>No, that's how *V2* worked. If you were circumventing that, you could have easily broken the IdP.
>
>V3 models all expressions like this as custom Principals. You can put any Principal objects you want into the Java Subject you return to the flow.
>
>You would have to ensure that all possible contexts were included in the external flow's supportedPrincipals property, turn off the setting that causes it to auto-add them all back into the Subject at the end, and ensure that the correct Principal(s) were included by your code.
>
>-- Scott
>
>-- 
>To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net