In practice, enhancing the serviceValidate and proxyValidate responses to include the user attributes as additional XML elements does not break CAS client library's parsing of the response, insofar as I've never seen it break anything.
This customization is not uncommon, and it is required to achieve the CAS integrations documented in certain vendors' product, including DegreeWorks and EZProxy. Unicon has both assisted individual CAS adopters in implementing this customization to achieve CASification of products that require this customization to the CAS protocol, and has incidentally done other work on CAS deployments that have performed this customization without Unicon involvement in it. Certainly the customizations change the serviceValidate and proxyValidate responses such that they are no longer CAS protocol compliant. That's annoying, and introduces the possibility that the change breaks or confuses something. I've never seen them break anything, however. One way to isolate the change is to introduce additional validation endpoints with the additional behavior, such that relying parties prepared to cope with the modified response opt in to the modified response by choosing to validate against the nonstandard path. /cas/serviceValidateWithAttributes , say. This amounts to rolling your own rev of the CAS protocol to offer attributes in the ticket validation responses. This isolation presents challenges for client libraries that intuit by convention and do not allow explicit configuration of the serviceValidate and proxyValidate paths, but as long as you're hacking anything, adding that configuration to the client library seems in reach. Note well that nothing authenticates relying parties to the ticket validation endpoints. The presenter of a service or proxy ticket is *not* authenticated as the service to whom that ticket was intended to authenticate the end user. This is in contrast to a PGT, which does authenticate the pgtUrl in the proxy chain. If I were designing a CAS protocol rev to accomplish user attributes, it might be interesting to architect it like ClearPass, such that a relying party presents a proxy ticket to the CAS server to access the attribute vending endpoint. ClearPass can be thought of as a special case of secure attribute release from CAS, constrained such that there's only one attribute (the password). Perhaps the world needs an AttributesForProxyTickets add-on for CAS that, in exchange for a proxy ticket, and considering some kind of attribute release layer of what attributes should be released to a given proxy chain, returns a simple XML response bearing the selected attributes of the user originating the proxy chain. Kind regards, Andrew On Dec 16, 2011, at 9:31 AM, Marvin Addison wrote: >> Can I get the attributes in this Cas Server through the CAS 2.0 protocol? > > Not without adding customizations that effectively break the XML > payload described by the protocol. > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
