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