<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's not easier to implement, no, although eventually you can just feed in<br>
actual metadata for CAS and there's no extra work, but to mock it up is<br>
more work, yes.</blockquote><div><br></div></div><div class="gmail_quote"><div>It wasn't too much trouble to implement the fraction of EntityDescriptor that is required to satisfy my requirements and dangle it off SAMLMetadataContext:</div><div><br></div><div><a href="http://svn.shibboleth.net/view/java-identity-provider?rev=6894&view=rev" target="_blank">http://svn.shibboleth.net/view/java-identity-provider?rev=6894&view=rev</a><br></div><div><br></div><div>I'll verify in situ tomorrow after the nightly idp-distribution drops.</div></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As an old example:<br>
<a href="https://wiki.shibboleth.net/confluence/display/DEV/OpenIDMetadataProfile" target="_blank">https://wiki.shibboleth.net/<u></u>co<u></u>nfluence/display/DEV/<u></u>OpenIDMet<u></u>adataProfile</a></blockquote><div><br></div></div><div class="gmail_quote"><div>Thanks for sharing that -- it immediately made clear your comment, "<span style="line-height:19.7999992370605px">eventually you can just feed in </span><span style="line-height:19.7999992370605px">actual metadata for CAS." Unfortunately that's a non-starter; no institution wants to explicitly register every relying party within their walls that wants to use "local" SSO. In fact many if not most institutions want to allow SSO without any explicit registration for services that originate from their DNS domain. For that reason Jasig CAS has evolved a simple facility ("service registry") for registering logical groups of services by regular expressions that define allowed services by URL. Here at Virginia Tech we register a "catch-all" expression for *.<a href="http://vt.edu" target="_blank">vt.edu</a>, then handle special cases </span><span style="line-height:19.7999992370605px">(e.g. hosted services) </span><span style="line-height:19.7999992370605px">in a one-off fashion.</span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">I have reproduced the service registry facility in the IdP [1], which effectively creates a lightweight CAS-specific metadata facility. This suggests to me that not all metadata needs can be captured by the SAML metadata model. I'd like to see at least a thin metadata API that has extension points that can be met by non-XML metadata. You can see from my ServiceEntityDescriptor implementation that there are pain points in extending existing components. In the end what I have done will probably work, but I think a more general MD API would have produced a cleaner result and could be generally beneficial to non-SAML protocols.</span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">M</span><a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">[1] <a href="http://svn.shibboleth.net/view/java-identity-provider/trunk/idp-cas-impl/src/test/resources/spring/test-flow-beans.xml?revision=6894&view=markup" target="_blank">http://svn.shibboleth.net/view/java-identity-provider/trunk/idp-cas-impl/src/test/resources/spring/test-flow-beans.xml?revision=6894&view=markup</a>, </span><span style="line-height:19.7999992370605px">cas.serviceRegistry bean</span></div></div>