Script the value of the discovery url for SAML auth flow? (discovery-config.xml)

Jeremy A Scott jeremy.scott at
Wed Jul 29 21:02:08 UTC 2020

Thanks Scott! 

I totally missed the misspelling in the example. __

I was able to script the functionality I needed there, and here is the result for anyone in a similar bind who wants to present different SP's a different WAYF/DS.

Currently we only have the one SP who needs a different WAYF/DS layout (what we call 'legacy') and we control that with query parameters so this script will suffice.
(As much as I hate hard coding things, it'll do for now.)


<!-- Alternatively specify a Function<ProfileRequestContext,String> to return the URL. -->
    <bean id="shibboleth.authn.discoveryURLStrategy"
            parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript">

		        logger = Java.type("org.slf4j.LoggerFactory").getLogger("net.shibboleth.idp.authn.impl.ScriptedDiscovery");
        	   	        logger.debug('Starting ScriptedDiscovery');
		        logger.debug('Default discoveryURL is ' + discoveryURL);
		        rpCtx = profileContext.getSubcontext("net.shibboleth.idp.profile.context.RelyingPartyContext");
				relyingPartyId = rpCtx.getRelyingPartyId();
		        logger.debug('relyingPartyId is ' + relyingPartyId);

 	                      switch ( relyingPartyId ) {
					case '':
						discoveryURL= discoveryURL + '?layout=legacy';
					case '':
						discoveryURL= discoveryURL + '?layout=legacy';
				logger.debug('Effective discoveryURL is ' + discoveryURL);

On 7/29/20, 12:46 PM, "Cantor, Scott" <cantor.2 at> wrote:

    On 7/29/20, 12:49 PM, "users on behalf of Jeremy A Scott" <users-bounces at on behalf of jeremy.scott at> wrote:

    >    Is there a better way for me to change the discovery URL for SAML authn based on the relying party?

    Use shibboleth.ContextFunctions.Scripted

    (note the plural)

    > (Something in relying-party.xml or, even better, metadata?)

    You can certainly use metadata, but you have to be able to dig into the API and get used to accessing entity attributes. The conditions are all predefined to know how to access those, but using them in functions requires actually digging them out.

    However, you can repurpose the Java code defined for deriving properties in relying-party.xml and use them for this purpose by hacking them a bit to access property names using a different URL prefix than the ones we use for those lookups in our namespace.

    I would have to go dig out the example I came up with for somebody else if you wanted to do it, but the classes that do all of that are wired up inside relying-party-mddriven.xml in the system tree. There's an aliases property where it takes in "alternate" URL prefixes for the tag names to go search for.

    The MDDriven lookup function classes are all API, so using them in other places is "safe".

    -- Scott

    For Consortium Member technical support, see
    To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list