Generalize RP Selection Mechanism

[Cantor, Scott]

On 11/13/14, 8:23 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:


>
>If you extended EntityDescriptor, you definitely do not want to do 
>that...it's the role types that are meant to be extended for different 
>use 
>cases.

I just took a quick look...implementing that interface is certainly an 
option, but what I really was suggesting was to map the protocol 
requirements to the existing data model and mock up the objects using the 
existing builders.

If by "group" what you meant was how to control enabling the CAS profile 
flow for matching services, I wouldn't necessarily see that as a group use 
case, rather you could do it by implementing pretty simple code that 
generates the metadata to "authorize" the CAS flow based on that regex.

Just as a strawman, say you had a simple CAS MetadataResolver that 
examined the input criteria and spat out simple metadata for any CAS 
request matching the rule(s) you configure, and not otherwise. If you did 
that, the "group" concept is really configured in the metadata resolver, 
and not in the RP layer.

The RP part might be exactly the same as the SAML ones, enabling CAS for 
"DefaultRelyingParty" and not for "unverified" ones. The only verification 
is just that it happened to get metadata out of that resolver.

That's a rough idea anyway.

-- Scott