CAS Service Registry

[Marvin Addison]

>
> I wouldn’t personally want to implement policy the level you describe, but
> it seems that it could technically be mapped to a SAML entity.  An entity
> could just describe “VT Campus Resources,” or somesuch.


The Service Registry is the simplest solution for deployers that want to
register groups of relying parties in a single stroke. I see this new
facility living alongside the Service Registry.


> So, I guess a question is, when folks implement a policy like the above,
> would attribute release be implemented at the same granularity?
>

Too many unknowns at this point to say.

The biggest sticking point that comes to mind is that the CAS service
> parameter is currently being passed to the Attribute Filter, which probably
> wouldn’t be what one would want if CAS clients were represented as first
> class entities.
>

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], 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.

M

[1] It's possible to configure a static service URL in most CAS clients,
but I would say that configuration is the less common one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20150410/49cf6489/attachment.html