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

[Cantor, Scott]

> 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 guess it would work, yes. A little weird, wouldn't scale all that well depending on the number of possibilities, you're basically expanding a table of mappings out into separate overrides for every row of the table.

My more general question is how we might be able to accomodate more dynamic behavior in a lot of the profile settings, which I probably didn't think through enough. I left a lot of what I inherited alone and just tinkered at the margins, but I never really took a fresh look at all of it.

Something I should have done is convert the whole lot of them to interfaces. Some of them are, but some are classes. All API though. I would need to look into how much casting to the classes is going on, I know I tried to avoid that because that's a red flag for me anyway, but I didn't really step back from it enough.

It would be really nice to be able to just instantiate beans that support the right profile config interface but bury the ability to dynamically derive some of the settings in the implementation of the interfaces. I guess worst case simply subclassing the API classes would still work though.

-- Scott