CAS Service Registry

[Cantor, Scott]

On 4/9/15, 2:02 PM, "Marvin Addison" <marvin.addison at gmail.com> wrote:
>
>Hopefully an example will clarify:
>
>
>                <bean class="net.shibboleth.idp.cas.service.ServiceDefinition"
>                      c:regex="https://([A-Za-z0-9_-]+\.)*vt\.edu(:\d+)?/.*"
>                      p:group="standard-vt-services"
>                      p:authorizedToProxy="false" /> 
>
>That allows all secure services in the VT DNS namespace to use CAS. That is the single most common use of the service registry: to restrict SSO to institutional boundaries.

Ok. That would, IMHO, not be addressing "services" in the SAML sense but rather provides a form of endpoint checking.

But what Walter means, in part, is having the ability to customize the login UI using various pieces of metadata (in the generic sense, not the SAML sense). For that, you have to discriminate by actual services.

So I guess the way to say it is, if all you want is endpoint checking, what you have there is fine. But if you want to create policy based on actual services in a location-independent way and attach metadata to them, you're going to have to end up with individual service descriptors. That also applies to do other things that are useful, like location-independent policies, and even using strong, scalable credential management for the authentication of the callback.

It's very straightforward to handle all of this behind a MetadataResolver facade because you're handed the CAS service URL as the input, so mocking up an EntityDescriptor in response to that if all you have is the service registry snippet above is not hard to do. In that case, you just don't have any of the data Walter's looking for.

But using the MetadataResolver API in the CAS flow would mean people who choose to can plug in actual metadata following a CAS profile that could have all that extra material in it. Your code wouldn't know the difference, or care that it's there, it just populates the SAMLMetadataContext and ignores it.

A harder task is indirecting the lookup. CAS doesn't allow for names and locations to be separate things, so on the surface all you can do is require that the SAML entityID in the metadata match the location. That's not ideal, but it's a step.

A further step would be a more advanced wrapper around the current batch MetadataResolvers that indexes the results by ACS location (which is what the CAS service URL is) and does a lookup against that as well, although given that it's many to many potentially, it's not guaranteed to produce a unique result, but that's more of a deployment consideration.

-- Scott