Hopefully we all agree that password replay is fraught with security
tradeoffs and that deployers should do so only with eyes wide open. In
practice there have been many situations (particularly sso portal
deployments) where the risks were acceptable. If you trust the
systems involved than the handling of the password is similar to
direct login to the target service (i.e. password "in the clear"
protected via SSL).
In any case, I agree the current Clearpass via PGT mechanism is overly
complicated now that attribute release is in the protocol, and believe
deployers would welcome a more straightforward and secure
configuration and deployment option.
Best,
Bill
On Fri, Dec 19, 2014 at 2:06 PM, Dmitriy Kopylenko
<dkopyle...@unicon.net> wrote:
> If it was up to me, I’d pour some kerosene on Clearpass and light a match
> ;-) But as Misagh pointed out, it is a “do or die” for some client apps
> wishing to integrate with CAS SSO to have users’ credentials replayed to
> them, unfortunately.
>
> I’d definitely +1 for a much simpler, robust and safe alternative to CP.
>
> Best,
> D.
>
> On Dec 19, 2014, at 12:20 PM, Misagh Moayyed <mmoay...@unicon.net> wrote:
>
> 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 | 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:
> 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:
> dkopyle...@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: wgt...@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
