IdPv3 CAS questions

[Marvin Addison]

>
> Is there anything that describes in detail Shib's implementation of the
> CAS protocol, at least in terms of its flow?


The flows are intended to implement the requisite features of the CAS 2.0
protocol specification, for which there's no present online reference. The
3.0 protocol reference is very similar, though I haven't read it with an
eye specifically for what's different from 2.0:

http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html

There are two notable differences from the 2.0 protocol specification:

1. Lack of LT support at /login URI.
2. Addition of attribute release in CAS protocol response payload.

On 1 I think most CAS developers have come to the conclusion that it's a
feature that never realized its intended value. Moreover, login is a
capability provided by the IdP that felt squarely out of scope for the CAS
protocol implementation. As for 2, attribute release is a de facto feature
of the Jasig CAS server that many CAS clients support, and many deployers
expect, so I added it.

There are no design documents available, other than the code itself, that
describe _how_ the flows implement the protocol, though the flow definition
files provide an good overview of the protocol steps. You can even generate
flow diagrams from the XML using tools like IntelliJ IDEA. That's where I'd
recommend starting if you want to dig deeper.


> I assume this means that CAS protocol v1 URI /validate is not
>
supported, and there are no plans to?


It's not supported, but it would be almost trivial to add. I honestly
thought almost no one uses it. I'm open to adding support.


> Is there a roadmap where we can generally track these?
>

There's no roadmap other than Jira. Please file an issue for /validate
support if you want it. I might be able to squeeze that into a 3.2.0
deliverable.


> Does the IdP implementation verify the service URL against the registry
> before proceding with the user authentication?
>

Yes. Unlike the Jasig CAS server, the IdP treats a request to /login as an
error if a service parameter is not provided. One of the first steps in the
flow is looking up the service URL in configured metadata sources. [1]
That's done using the ServiceRegistry facility at present, though there are
plans for adding SAML metadata support (hopefully) for 3.2.0.

M <users-unsubscribe at shibboleth.net>

[1] It is possible to run in "open" mode where the IdP will issue tickets
to any service, but that's not the default configuration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150815/3f6cf5da/attachment.html>