Using shibboleth.authn.SAML.discoveryFunction

[Cantor, Scott]

On 4/7/21, 7:50 AM, "users on behalf of Vincent Feyaerts" <users-bounces at shibboleth.net on behalf of vincent.feyaerts at uantwerpen.be> 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