I wouldn’t go so far as naming it a backup solution. Sometimes, it is the only
solution! :) There are applications that do require the password before they
can be integrated into the SSO environment. Things like WebAdvisor, Outlook Web
Access and many more…there are no other alternatives. Either you don’t CASify
the app, or you do it and give it the password. ("Do or do not; there is no
try” as Yoda would say)
What sort of problems do you have in mind?
All the PGT callback is doing is making sure the app is authorized to receive
the password, by having CAS configuration in place that says so. CAS also
authenticates the client by simply relying on SSL. If we release the password
as an attribute, we’re still going to be doing the same things conceptually:
CAS still needs to be configured to release the password to a specific app.
That app still needs to be protected by SSL
We could also encrypt the password and send it over, by default, only to be
decrypted by the client that holds the right key. (Something we are not doing
today)
If the client is already consuming password, I don’t see any issues with adding
one more to the list.
I think you are more concerned about turning on clearpass in general. I am too.
In a perfect world, we could have dropped support for clearpass but that is not
a reality today.
> On Dec 19, 2014, at 8:07 AM, Jérôme LELEU <lel...@gmail.com> wrote:
>
> 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
> <http://www.casinthecloud.com/> | Twitter: @leleuj
> Chairman of CAS: www.jasig.org/cas <http://www.jasig.org/cas> | Creator of
> pac4j: www.pac4j.org <http://www.pac4j.org/>
> 2014-12-19 6:07 GMT+01:00 Misagh Moayyed <mmoay...@unicon.net
> <mailto: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
> <mailto:cas-dev@lists.jasig.org> as: lel...@gmail.com
> <mailto:lel...@gmail.com>
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-dev
> <http://www.ja-sig.org/wiki/display/JSG/cas-dev>
> --
> You are currently subscribed to cas-dev@lists.jasig.org
> <mailto:cas-dev@lists.jasig.org> as: mmoay...@unicon.net
> 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
