CAS Service Registry

[Cantor, Scott]

On 4/10/15, 9:28 AM, "Marvin Addison" <marvin.addison at gmail.com> wrote:
>
>While I suppose it can be an arbitrary URI, the input into the metadata resolver MUST be the service URL. The difficulty is that CAS clients allow the service URL to vary for a single logical application [1]

Well, isn't it basically the case that the client just tells the login service where to send the response arbitrarily? There is no logical application notion within the protocol itself, right? No entityID equivalent. That's what I meant when I said that naming and locations in SAML are separate things, but I don't think that's true in CAS.

But I would expect that in that kind of scenario, you don't get the luxury of just predefining specific URLs as being valid, it will likely be whole families of URLs that are used. SAML avoided that by design to prevent the requirement to do pattern matching in endpoint verification, but I wouldn't expect that to hold for other protocols.

>, which leads to needing a matching engine like
> what's in PatternServiceRegistry now. That could be ported to a metadata resolver, of course, but it's a complexity peculiar to the CAS protocol that produces some impedance mismatch with SAML metadata IMO.

Well, the mismatch is really the overloading of identity and location. This is a very common thing in systems I didn't design. ;-)

In terms of endpoint validation, SAML metadata doesn't define that, the SAML protocol does. By which I mean, you could define a profile of metadata such that the Location attribute in an AssertionConsumerService element with a particular Binding was a regex. Nobody has, but if that's the use case, it's the use case.

-- Scott