Requested/Supported Principals

[Marvin Addison]

>
> writing your own X509 flow with a different
> bean definition at the end in place of ValidateX509Certificate should work
> around the issue for now.
>

That's what I'm actively working on now. I'll follow up with results.


> If you create a version of that class that builds its own Subject or
> explicitly removes Principals from the input parameter, I think it will do
> what you want.
>

I'm going with the removal route. Based on my analysis I also have to do
something like the following:

        final RequestedPrincipalContext rpCtx =
authenticationContext.getSubcontext(RequestedPrincipalContext.class);
        // Clear any previously-set matching principal
        rpCtx.setMatchingPrincipal(null);
        // Set the first requested principal type that matches on the
authenticated subject
        for (Principal requested : rpCtx.getRequestedPrincipals()) {
            for (Principal supplied : subject.getPrincipals()) {
                if (requested.equals(supplied)) {
                    rpCtx.setMatchingPrincipal(supplied);
                    return;
                }
            }
        }

The matchingPrincipal field is what drives population of the SAML
AuthnContextClassRef in the message actions down in the SAML profile flows.
I didn't see any existing action that sets that field from subject
principals, so it seems I have to explicitly deal with it.

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150513/bbdca587/attachment-0001.html>