<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there anything that describes in detail Shib's implementation of the<br>
CAS protocol, at least in terms of its flow?</blockquote><div><br></div><div>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:</div><div><br></div><div><a href="http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html">http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html</a><br></div><div><br></div><div>There are two notable differences from the 2.0 protocol specification:</div><div><br></div><div>1. Lack of LT support at /login URI.</div><div>2. Addition of attribute release in CAS protocol response payload.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I assume this means that CAS protocol v1 URI /validate is not<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
supported, and there are no plans to?</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Is there a roadmap where we can generally track these?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Does the IdP implementation verify the service URL against the registry before proceding with the user authentication?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>M<a href="mailto:users-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div><div>[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.</div><div><br></div></div></div>