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

Wessel, Keith kwessel at
Thu Sep 2 19:56:56 UTC 2021

So, something like this?

    <bean id="proxySPEntityIDStrategy" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript"
                spEntityID = "";
                authnCtxClassRef = input.getParent().getSubcontext(RequestedPrincipalContext.class);

                if (authnCtxClassRef == "") {
                    spEntityID = "";


Then use it like this:

<bean parent="RelyingPartyByName" c:relyingPartyIds=""
    <property name="profileConfigurations">
            <ref bean="SAML2.SSO">

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.


-----Original Message-----
From: users <users-bounces at> On Behalf Of Cantor, Scott
Sent: Thursday, September 2, 2021 2:25 PM
To: Shib Users <users at>
Subject: Re: Using a different SP entity ID with the IdP SAML authn flow

On 9/2/21, 3:04 PM, "users on behalf of Wessel, Keith" <users-bounces at on behalf of kwessel at> wrote:

>    Thanks, Scott. So, to make this dynamic and use a different SP entity ID based on, for example,
> authnContextClassRef of the original incoming request, I can create a bean and set the
> relyingPartyLookupStrategy on the specific relying party override bean to point to that bean. Is that correct?

I think you mean responderIdLookupStrategy (and if not, that's the correct setting), but yes.

>    I assume my custom bean just returns a string with the entity ID that Shibboleth should identify itself as. Any
> pointers to other beans in the IdP configuration that would be a good example for me to base mine off of?

Nothing that would be relevant to looking at the AuthnRequest I can think of, and this is much more tricky, you're talking about this running when it's in the middle of proxying, so the tree is very messy at that point. Your function runs against a ProfileRequestContext that's sitting underneath the AuthenticationContext, it's nested. You probably want to base it on the cooked data, not the AuthnRequest.

input.getParent().getSubcontext(RequestedPrincipalContext.class) in that lookup strategy call should actually go up and then back down to where the requested context class(es) have been pulled out and stuffed into the tree during authentication.

All of that could also be wrong, this is just a back of the envelope guess.

-- Scott

For Consortium Member technical support, see;!!DZ3fjg!s7F3NKZ-taJgCWSGTGiCUljiQhHt4GqJZOKTioD6AWsTumcrO5L9AWFQeIMnCQmj6A$ 
To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list