Generalize RP Selection Mechanism

[Cantor, Scott]

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


>
>To be honest, I stopped when I saw that 
>RelyingPartyConfigurationSupport#byGroup was backed by something called 
>"SAMLMetadataContext" that I took at face value to be SAML-specific. 
>Maybe it's just a naming thing, but names matter. If it's intended to be 
>a general API that can be implemented by any SSO protocol, it should have 
>a name that reflects that purpose.
> 

It's SAML metadata because it is a SAML specification, but it's not 
specific to SAML profiles. The SAML part in the context name is just 
referring to the thing it's holding.

"Metadata" alone wouldn't be a great name because it's an overloaded term. 
We can change the name, but I'm not sure there's anything clearer to use.

We don't have a separate module for metadata at this point, we just put it 
into the saml modules. In certain cases that might create unnecessary 
dependencies, but for this project we have to include all of that code 
anyway, so separating it doesn't buy much.

>That's a fair analysis. Looking more closely at SAMLMetadataContext, I 
>see that I can probably create a CAS-specific EntityDescriptor, but the 
>*Descriptor classes are very XML-oriented and contain some SAML-specific 
>concerns. I don't see any showstoppers yet, but I'm not sure this will be 
>easier to implement. But I'd trade a harder implementation for easier 
>configuration any day, so I may go this route.

It's not easier to implement, no, although eventually you can just feed in 
actual metadata for CAS and there's no extra work, but to mock it up is 
more work, yes. I think it will be easier to configure potentially (but 
that's without exactly knowing what the alternative would look like, the 
groups have to come from *somewhere*).

An EntityDescriptor itself is not protocol-aware, so there's nothing CAS 
about that. What you want (in full) is a RoleDescriptor of an appropriate 
type (a CAS client is an SPSSODescriptor), and then you mint URIs:

- a protocol support enumeration constant
- a binding constant representing the CAS protocol to stick into 
AssertionConsumerService elements

And that's about it for an SP with a CAS-like flow. OpenID was essentially 
the same.

As an old example:
https://wiki.shibboleth.net/confluence/display/DEV/OpenIDMetadataProfile

Of course, how much of that is actually needed depends on what's calling 
the metadata APIs. The group material wouldn't require any of that, and in 
theory you wouldn't even need the role at all.

-- Scott