Using a different SP entity ID with the IdP SAML authn flow

[Wessel, Keith]

Finally circling back to this, and I thought I had it figured out until I saw your mention of getOperator returning "exact". I was imagining something like this:

    <bean id="proxySPEntityIDStrategy" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript"
        <constructor-arg>
            <value>
                <![CDATA[
                spEntityID = "https://sp.example.org/shibboleth";
                var requestedPrincipals = input.getParent().getSubcontext(RequestedPrincipalContext.class).getRequestedPrincipals();

                for (i=0; I<requestedPrincipals.length; i++) {
                    if (requestedPrincipals[i].getName() == "https://refeds.org/profile/mfa") {
                        spEntityID = "https://sp.example.org/shibboleth/mfa";
                    }
                }

                spEntityID;
                ]]>
            </value>
        </constructor-arg>
    </bean>

Is it necessary to use getOperator instead of just iterating over the list of requested principals and calling getName() on each which, to me, looks like it just returns a string on which I can use a standard equal operator?

Thanks, and sorry if I'm being dense on this.

Keith

-----Original Message-----
From: Wessel, Keith 
Sent: Tuesday, September 7, 2021 8:57 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: Using a different SP entity ID with the IdP SAML authn flow

I've finally had time to look over the Javadocs and process your suggestion, Scott, and it makes sense. The value returned from getName should correspond with the authnContextClassRef string -- in this case, the Refeds MFA profile. Correct?

Only remaining question is what's the best way to search the principal objects returned from getRequestedPrincipals? A for loop is the most obvious, calling getName on each item in the list. Is there a more efficient technique? Sorry to have to take this post to coding advice.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Friday, September 3, 2021 7:05 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: Using a different SP entity ID with the IdP SAML authn flow

On 9/2/21, 3:57 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    So, something like this?

The RequestedPrincipalContext is not a context class in the SAML sense, it's one in the IdP sense. It's a Java object containing the extracted details from the AuthnRequest in neutral form. The javadocs on it will demonstrate how to use it to examine the contents once you have a handle on it.

>    Does that look sane? If it doesn't work, I'll certainly study the 
> docs for some of the objects I'm using to get the requested authnContextClassRef since, as you stated, that's a rough guess.

You need the docs.

https://urldefense.com/v3/__http://shibboleth.net/sites/release/java-identity-provider/4.1.4/apidocs/net/shibboleth/idp/authn/context/RequestedPrincipalContext.html__;!!DZ3fjg!q8-3DZjj0gKM4esg9z51MvuPzgLw0n9AS8PbHgj0VjF8BVrrZYv9krgbgDjJfZWufg$ 

Basically assuming getOperator() is "exact", the getRequestedPrincipals() method will return the AuthnContextClassRefPrincipal objects that got build from the SP's request that you can search through for a match, which in turn will return the context class string via getName()

All the abstraction and extra layers is needed to get portability, it's not a SAML feature internally, just an abstracted equivalent based on it. So it works similarly for OIDC and CAS.

-- Scott


--
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!q8-3DZjj0gKM4esg9z51MvuPzgLw0n9AS8PbHgj0VjF8BVrrZYv9krgbgDgW2lUuMQ$
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net