How to change the issuer of an assertion

[Cantor, Scott]

> First, I tried to set the "responderId" of the current
> RelyingPartyConfiguration
> (got from the RelyingPartyContext), but that's not allowed. I'm not yet
> familiar enough with the whole RelyingParty configuration to find out myself.

No, it can't be statically set at runtime, those are singletons, they exist as a single bean for all requests.

> Can I use some available "Lookup" strategy? How would I configure multiple
> available responders with their entityID and corresponding credentials?

The responderIdLookupStrategy property installs a function that returns the ID. Can be Java or a script, anything that implements the Function<ProfileRequestContext,String> interface. There are some examples of scripts doing similar things in the wiki.

When anything in the code calls getResponderId(), your function gets run, so it has to return something even if it's too "early" to know the real answer.

You can't install one function to handle two settings. If you need to change the credentials also, that's a second lookup strategy. That one is also much nastier since the credentials are buried inside a complex structure (SecurityConfiguration). But the example in the wiki [1] shows this, using triggering SHA-1 as an example. Setting credentials would be similar, it requires setting different members of the SecurityConfiguration object, which we show examples of in the wiki on a different page [2].

If you marry it all together, it does the right things.

In your case, the scripts or Java code aren't looking at the relying party ID, but at internal user attribute state or possibly looking at some custom context class in the tree that stores off the information you got from the user. Perhaps a Java class called SWITCHAffiliationContext or something like that. It just depends what the data looks like.

I probably would do this kind of thing in Java to be able to configure it in some sensible way, scripts would be pretty messy.

For example, I could imagine wiring up beans in a Spring file that do all the mapping of affiliations to these settings, and then the Java classes get those injected to do their work and feed the context tree data into the mappings and get the answer to return. Or of course it could be database driven or something, even dealt with partly in the attribute resolver.

-- Scott

[1] https://wiki.shibboleth.net/confluence/display/IDP30/RelyingPartyConfiguration
[2] https://wiki.shibboleth.net/confluence/display/IDP30/SecurityConfiguration