CAS Service Registry

[Cantor, Scott]

On 4/10/15, 1:51 PM, "Marvin Addison" <marvin.addison at gmail.com> wrote:

>Thanks for sketching out a concrete implementation, Scott. Can you clarify what you mean by "define a profile of metadata"? XML schema definition?

Not necessarily, it's at minimum just the text saying what has to show up where and what it means. Sometimes that involves extensions, more often not. Usually it involves defining some URI constants as signals.

An example:
https://wiki.shibboleth.net/confluence/display/SHIB/ADFSMetadataProfile

That's not a comparable example because it's profiling a spec that's essentially a braindead version of SAML 1, so it's much more comparable to SAML proper than CAS, but it includes certain common elements like defining a protocol URI to use to signal support, and defining Bindings for endpoints.

There are two ways to profile SAML metadata. One way is to ignore all of its built-in roles and just define new ones that live inside the general "EntityDescriptor" container. That makes it essentially usable for anything that's related to "entities doing stuff", which is a fairly broad brush. Microsoft did this when they decided to use it for WS-Trust in ADFS. It's fairly ugly stuff.

The other way is when you aren't trying to make a political point ;-) and you recognize that all SSO protocols are basically the same underlying thing and you just reuse the IDPSSODescriptor and SPSSODescriptor roles for thw two halves. Since there's not much need for profiling the CAS login service as an IDP, the main use case here is profiling SPSSODescriptor.

To do that, you would define:

- a CAS protocol URI to use in protocolSupportEnumeration
- a Binding URI that represents the CAS protocol
- the rules for what to put in the Location of the AssertionConsumerService elements and what the login service is supposed to do with them

There might be other applicable fields or endpoints (SingleLogoutService?) but that's basically the minimum.

I don't know what the CAS security model normally is, but what we kept pestering you about was that we would expect to be able to put a KeyDescriptor for the CAS client's credentials into its metadata also, at least if it's a public key/cert, and use the existing metadata-driven trust engines to do the authentication of the client.

We have a Standards Center wiki space now, so if we do this, we'd define it there eventually.

-- Scott