Generalize RP Selection Mechanism

[Cantor, Scott]

On 11/13/14, 3:14 PM, "Marvin Addison" <marvin.addison at gmail.com> wrote:


>
>Since this configuration is deployer-specific, there's no default 
>configuration that can be applied to the default relying party. So I need 
>a way to do something like RelyingPartyByGroup with the CAS protocol. I 
>have a plan to make that work by leveraging 
>RelyingPartyContext#relyingPartyIdContextTree, but that is very much CAS 
>protocol-specific and less natural than I'd like. Ideally the notion of 
>"group" would be protocol agnostic and I could use RelyingPartyByGroup as 
>is. That's not possible at present since the notion of group is tightly 
>coupled to SAML metadata.

That's true, but only as an API and data model, not an underlying format. 
Any SSO protocol is trivially mappable to SAML metadata, so I'm not sure 
why the simpler solution isn't just to generate that metadata, because if 
you need to be able to supply the information at runtime you're going to 
have to feed in that exact information somehow.

>I would like to propose making group a first-order relying party concern 
>(e.g. RelyingPartyContext#group) so that it can be configured in a 
>protocol-specific fashion, leaving group activation to be a simple 
>selection on some attribute of RelyingPartyContext.
> Does that make sense?

I think you're suggesting that we put a group collection into the RPC and 
then just have an action in the SAML flows to copy the group data from the 
metadata over to that collection?

I don't think that's a bad idea, but my question is how you're planning to 
populate that in a different way? Because whatever that way might be, it 
could just generate the necessary metadata. Both end up in about the same 
place, but generating the metadata drives a lot of other useful code.

-- Scott