Using shibboleth.authn.SAML.discoveryFunction

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Using shibboleth.authn.SAML.discoveryFunction

Vincent Feyaerts

Hi,

 

Is there an example somewhere, or can somebody provide a very basic one, of the use of shibboleth.authn.SAML.discoveryFunction in Idp 4.1? I’m afraid I don’t really know where to start writing this “function”, or what it should look like.

 

What I’m trying to do is to send the client to one or another SAML Proxy IdP, based on the SP EntityId and/or other parameters. This is for a test scenario where our Shib IdP is defined twice as a SAML application in Azure AD, where MFA will be enabled on only one of these. This way, we can decide to have MFA on some Shibboleth SP but not on all or none.

 

Thanks in advance

Vincent Feyaerts


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

smime.p7s (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Using shibboleth.authn.SAML.discoveryFunction

Cantor, Scott E.
On 4/7/21, 7:50 AM, "users on behalf of Vincent Feyaerts" <[hidden email] on behalf of [hidden email]> wrote:

>    Is there an example somewhere, or can somebody provide a very basic one, of the use of
> shibboleth.authn.SAML.discoveryFunction in Idp 4.1? I’m afraid I don’t really know where to start writing this
> “function”, or what it should look like.

Assuming you know the basics assumed to operate the IdP (Spring and Java), the documentation notes that the signature of the function is Function<ProfileRequestContext,String>. The function takes in the root of the state tree managing every request and returns a String, the entityID of the IdP to use. It's used when no user input is required to perform the task of determining the IdP to use and you want to do it programmatically based on the content of the original request.

The alternatives are to hardcode a value in a property, which simply hardwires in FunctionSupport.constant(<property>) as the discovery function (i.e., just return the property), or to actually leverage a full discovery service with a UI by redirecting to one, which is handled differently.

>    What I’m trying to do is to send the client to one or another SAML Proxy IdP, based on the SP EntityId and/or
> other parameters.

i.e., you have to supply a Java Function in an extension jar, or a script or some other implementation of a Java Function that does that, which requires background in the internals of the data the IdP places into the context tree.

This page [1] includes a fair amount of documentation on the internal system state during authentication with links to the javadocs of many of the context objects in the state tree that are accessible via the ProfileRequestContext, the root of the tree.

-- Scott

[1] https://wiki.shibboleth.net/confluence/display/IDP4/Authentication


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Using shibboleth.authn.SAML.discoveryFunction

Vincent Feyaerts
Alright thank you for pointing me in the right direction. I wrote a very simple script function, it's below in case somebody else wants to achieve the same thing: choose a SAML Proxy IdP based on the Relying Party Entity Id

From global.xml

    <bean id="shibboleth.authn.SAML.discoveryFunction" parent="shibboleth.Functions.Scripted" factory-method="inlineScript">
        <constructor-arg>
        <value>
                <![CDATA[
                relyingPartyId = input.getSubcontext('net.shibboleth.idp.profile.context.RelyingPartyContext').getRelyingPartyId();

                logger = Java.type("org.slf4j.LoggerFactory").getLogger("net.shibboleth.idp.profile");
                logger.info("RelyingPartyId is " + relyingPartyId);

                if (relyingPartyId == 'XXX')
                {
                        logger.info("This RP is configured to use MFA.");
                        "EntityId of the upstream SAML Proxy IdP";
                }
                else
                {
                        logger.info("No special requirements for this RP. We will not use MFA.");
                        "EntityId of another upstream SAML Proxy IdP";
                }
         ]]>
        </value>
        </constructor-arg>
    </bean>

-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: woensdag 7 april 2021 14:21
To: Shib Users <[hidden email]>
Subject: Re: Using shibboleth.authn.SAML.discoveryFunction

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


On 4/7/21, 7:50 AM, "users on behalf of Vincent Feyaerts" <[hidden email] on behalf of [hidden email]> wrote:

>    Is there an example somewhere, or can somebody provide a very basic
> one, of the use of shibboleth.authn.SAML.discoveryFunction in Idp 4.1?
> I’m afraid I don’t really know where to start writing this “function”, or what it should look like.

Assuming you know the basics assumed to operate the IdP (Spring and Java), the documentation notes that the signature of the function is Function<ProfileRequestContext,String>. The function takes in the root of the state tree managing every request and returns a String, the entityID of the IdP to use. It's used when no user input is required to perform the task of determining the IdP to use and you want to do it programmatically based on the content of the original request.

The alternatives are to hardcode a value in a property, which simply hardwires in FunctionSupport.constant(<property>) as the discovery function (i.e., just return the property), or to actually leverage a full discovery service with a UI by redirecting to one, which is handled differently.

>    What I’m trying to do is to send the client to one or another SAML
> Proxy IdP, based on the SP EntityId and/or other parameters.

i.e., you have to supply a Java Function in an extension jar, or a script or some other implementation of a Java Function that does that, which requires background in the internals of the data the IdP places into the context tree.

This page [1] includes a fair amount of documentation on the internal system state during authentication with links to the javadocs of many of the context objects in the state tree that are accessible via the ProfileRequestContext, the root of the tree.

-- Scott

[1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fdisplay%2FIDP4%2FAuthentication&amp;data=04%7C01%7Cvincent.feyaerts%40uantwerpen.be%7Cafd0c9d6ee0e47be011b08d8f9bfa611%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637533948824301199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=xFvVlPEhSeS5mdh5vR%2BN4tQ7haI9WMTP90nszPAWkoc%3D&amp;reserved=0


--
For Consortium Member technical support, see https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&amp;data=04%7C01%7Cvincent.feyaerts%40uantwerpen.be%7Cafd0c9d6ee0e47be011b08d8f9bfa611%7C792e08fb2d544a8eaf72202548136ef6%7C0%7C0%7C637533948824311192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=flUbYvIpoZo6rYZDLMfiM5bdHqvvCx4kiuxUNo5DSBc%3D&amp;reserved=0
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

smime.p7s (9K) Download Attachment