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
>> <mailto: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
>> <mailto:mmoay...@unicon.net>
>> 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: 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:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
