Team, The CAS project officially bundled the clearpass extension starting with CAS 3.5.0. Support for communicating credentials is ultimately implemented through a special proxy granting ticket that is obtained for clearpass. While this approach may work for simpler CAS integrations, I have in mind that we could perhaps simplify the process a bit more to make it easier for client applications to obtain the password specially when the deployment environment is nontrivial. The current approach presents the following complications:
When the CAS server is clustered, PGTs need to be kept in sync across all nodes Since the password is kept in node memory, that needs to also be kept in sync across all nodes Coordinating the keep-alive and expiration time of the password, which is tied to the TGT expiration policy also can be tricky and confusing. When the receiving application is clustered, the callback may simply get lost in the event that the load balancer is not properly configured to stick to the same request session. If that fails, the callback url must point to the exact node via CAS client settings which exposes the node. Doing the proxy dance is generally more than nontrivial if one is using a non-official cas client or if the app is backed by a security framework that does not make this too easy. For the developer, debugging and troubleshooting this flow should things go wrong is really difficult Now that the CAS protocol is able to release attributes natively, I would like to propose that we capture and release the password, configuration permitting, much in the same way. The password can simply be another attribute released, stuck into the authentication, under a specially designated name. …or, in order to make this more explicit, a small protocol rev may be suitable to give the password its own special tag. The client will be able to consume the password directly, provided it’s allowed via the service registry. Since we don’t require client authentication for attribute release, for extra security the password may be [optionally perhaps] encrypted via a secret key. This should alleviate the problems enumerated above, and makes it easy for both apps and app developers to consume the password. The immediate advantage of this proposal is specially attractive for uPortal, which requires the password from CAS in order to allow portlets to talk to exchange or make other web proxy-related calls to backend services that require the password. I don’t suppose the development effort would be all that much, specially with changes that have gone into 4.0 and master today. Thoughts? Misagh -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
