Need to modify AuthnContextClassRef in ExternalAuth
Cantor, Scott
cantor.2 at osu.edu
Mon Dec 14 20:14:36 EST 2015
On 12/14/15, 7:59 PM, "users on behalf of Stefan Santesson" <users-bounces at shibboleth.net on behalf of stefan at aaa-sec.com> wrote:
>In my Java code I set the principal returned like this:
>
>Principal principal = new UsernamePrincipal(userName);
> Subject subj = new Subject();
> subj.getPrincipals().add(principal);
If that's all you return, then the flow will auto-add all 3 of those AuthnContextClassRefPrincipals into the Subject for you.
You have to turn that off (set shibboleth.authn.External.addDefaultPrincipals to java.lang.Boolean.FALSE) and change that code to add the specific AuthnContextClassRefPrincipal you want it to carry back.
>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.
That will happen, but that's because it sees all three values in the Subject's principal set, and picks the one to return that satisfies the original request.
>How can I accept a request with no requested class ref, and determine in the ExternalAuthn servlet, which should be returned?
By adding the ones you specifically want included and turning off the auto-add setting.
The default behavior accomodates what most people want, which is to attach a bunch of interchangeable values that all mean the same thing, and not have to write any code to do it.
If the values are not interchangeable but the product of a runtime decision, you have to bypass the built-in behavior and do it in code, both of which are very simple to do *for External*. It's not as simple with most of the built-in flows that are constructing their Subject internally. That is, the built-in flows are hardwired to do simple things like V2's login handlers were. The External flow provides complete control (just as a custom flow does) if it's needed.
-- Scott
>
More information about the users
mailing list