One idp application serving as two idps (with different entityIDs)

[Brent Putman]

On 2/11/16 11:16 AM, Cantor, Scott wrote:
>> However, what would the configuration have to look like in case one
>> wants an IdP to respond to both these SPs (or rather all SPs it has
>> metadata for) with an entityID that is picked (from a list of entityIDs)
>> or computed based on information of the authentication request (e.g. the
>> Destination attribute)?
>> Is that possible by means of  configuration?
> Don't think so. There's kind of a mix of "static" and "dynamic" behavior in a lot of the properties, and responderId isn't a function entry point, just a static String property.
>
> We'd have to build in an injection point for that I guess to make it a function.


Aside from a new Function-based approach: If the desired task is to
select a RelyingPartyConfiguration (including responderId) based on
something other than the entityID, like info in the SAML request,
couldn't this be done today pretty easily by just attaching different
activationCondtion(s) to the RPC, as a
Predicate<ProfileRequestContext>.  I thought that was the whole point of
the v3 DefaultRelyingPartyConfigurationResolver impl, it just loops over
the RPC's in order and takes the one(s) that match the predicate (with
usually only the first one really being used by most things).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160211/f7b0f290/attachment.html>