Generalize RP Selection Mechanism

Cantor, Scott cantor.2 at osu.edu
Thu Nov 13 15:23:10 EST 2014


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


>
>Thanks for sharing that -- it immediately made clear your comment, 
>"eventually you can just feed in actual metadata for CAS." Unfortunately 
>that's a non-starter;
> no institution wants to explicitly register every relying party within 
>their walls that wants to use "local" SSO. 

Lots do, actually. We certainly do. If for no other reason than for 
accurate contact data, and for dealing with login UI, consent, etc.

>I have reproduced the service registry facility in the IdP [1], which 
>effectively creates a lightweight CAS-specific metadata facility. This 
>suggests to me that not all metadata needs can be captured by the SAML 
>metadata model.

You can always generate the metadata you need on the fly in response to a 
lookup, if you don't think it matters that it be registered. You could do 
that with a regex for that matter (same goes for endpoint checking). The 
point of the metadata is to authorize the code to respond, it doesn't 
matter why the metadata is put in that position from the perspective of 
the downstream logic. That's the point of having alternate metadata 
resolvers.

> I'd like to see at least a thin metadata API that has extension points 
>that can be met by non-XML metadata.

The API has nothing to do with XML apart from being serializable to it. It 
also has, as a data model, an extensible mechanism of attaching so-called 
object metadata to any node in the tree, which is how we expose the group 
data for example.

> You can see from my ServiceEntityDescriptor implementation that there 
>are pain points in extending existing components. In the end what I have 
>done will probably work, but I think a more general MD API would have 
>produced a cleaner result and could be generally beneficial to non-SAML 
>protocols.

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.

-- Scott



More information about the dev mailing list