Hi, I don't know the issues related to uPortal, but I've always seen ClearPass as a backup solution we should always try to avoid. ClearPass is a good solution but for a bad objective.
I don't feel comfortable with sending back the password as a user attribute: it can lead to so many problems. Are we so stuck that there is no alternative solution we could go towards? Thanks. Best regards, Jérôme LELEU Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org 2014-12-19 6:07 GMT+01:00 Misagh Moayyed <mmoay...@unicon.net>: > > 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: lel...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- 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
