Passwd in response

[Anthony Colebourne]

Hi,

At the JA-SIG conference last week I spoke to several people about
Patches they were running that leaked the users password back to
specially allowed CASified applications.

I had several debates about the moral virtues of doing this and realize
that no school wants take responsibility for releasing such a Patch.

All things considered, I'm going to look into applying this patch
locally. I'm convinced its our only hope of encouraging adoption.

So, where might one begin when looking to re-write this evil (un)patch?

Thanks,
Anthony.
--
Anthony Colebourne
IT Services Division
The University of Manchester
_______________________________________________
Yale CAS mailing list
cas@...
http://tp.its.yale.edu/mailman/listinfo/cas

[microcline]

Anthony,

I've been thinking about this as well.  This feature requirement comes
up more often than it's pleasant to admit.  Especially with uPortal 3
shipping with CAS and the uPortal password caching and replay features
built into the framework and used by even more available channels and
portlets (email preview, briefcase, and now the open-sourced Toro
portlets), I'm thinking this is a feature worth soberly, carefully,
centrally, and aggressively optionally, off-by-default, including in the
CAS server distribution as a mainstream feature.

Whether it's morally virtuous to use this feature can be left open for
debate.

I worry that implementing this feature locally multiple times invites
redundant effort and local adoption of less-ideal implementations of
this feature than could be achieved centrally.  If one is going to be
passing passwords around with CAS, one wants a solid, considered, secure
implementation that passes the information securely and authenticates
the the services before giving them the password and that doesn't break
anything.  It seems a waste to invite people to locally trip over these
issues for lack of a shared implementation of this feature.

Rutgers/Benn Oshrin have a thread going about where CAS can go next and
what additional extension points/features would be welcome.  I'll look
to engage that thread on this idea and invite you and other interested
people to chime in.

Andrew



Anthony Colebourne wrote:

> Hi,
>
> At the JA-SIG conference last week I spoke to several people about
> Patches they were running that leaked the users password back to
> specially allowed CASified applications.
>
> I had several debates about the moral virtues of doing this and realize
> that no school wants take responsibility for releasing such a Patch.
>
> All things considered, I'm going to look into applying this patch
> locally. I'm convinced its our only hope of encouraging adoption.
>
> So, where might one begin when looking to re-write this evil (un)patch?
>
> Thanks,
> Anthony.
>  

_______________________________________________
Yale CAS mailing list
cas@...
http://tp.its.yale.edu/mailman/listinfo/cas

[Richard J Garbutt]

Hi Anthony, Andrew

As with Anthony's comment, the only hope we have of adoption of CAS at Hull
is if we can leak the password back to systems that are uncassifiable, as in
system we don't own that we have to integrate with. We have spent
development time getting CAS to expose the password, but as yet not been
able to retrieve (via uPortal) which would mean more development time. I
think there is a need for there to be a community solution to this issue as
I'm sure there are many institutions in the same position as us. We will
have to implement this solution regardless but will feel more confident in
terms of security if there was a combined effort in the community and a
possible release to future distributions, turned off by default obviously.

We'll be watching to the Rutgers/Benn Oshrin thread with interest, and happy
to contribute.

Richard
eSIG
The University of Hull


On 06/05/2008 18:47, "Andrew Petro" <apetro@...> wrote:

> Anthony,
>
> I've been thinking about this as well.  This feature requirement comes
> up more often than it's pleasant to admit.  Especially with uPortal 3
> shipping with CAS and the uPortal password caching and replay features
> built into the framework and used by even more available channels and
> portlets (email preview, briefcase, and now the open-sourced Toro
> portlets), I'm thinking this is a feature worth soberly, carefully,
> centrally, and aggressively optionally, off-by-default, including in the
> CAS server distribution as a mainstream feature.
>
> Whether it's morally virtuous to use this feature can be left open for
> debate.
>
> I worry that implementing this feature locally multiple times invites
> redundant effort and local adoption of less-ideal implementations of
> this feature than could be achieved centrally.  If one is going to be
> passing passwords around with CAS, one wants a solid, considered, secure
> implementation that passes the information securely and authenticates
> the the services before giving them the password and that doesn't break
> anything.  It seems a waste to invite people to locally trip over these
> issues for lack of a shared implementation of this feature.
>
> Rutgers/Benn Oshrin have a thread going about where CAS can go next and
> what additional extension points/features would be welcome.  I'll look
> to engage that thread on this idea and invite you and other interested
> people to chime in.
>
> Andrew
>
>
>
> Anthony Colebourne wrote:
>> Hi,
>>
>> At the JA-SIG conference last week I spoke to several people about
>> Patches they were running that leaked the users password back to
>> specially allowed CASified applications.
>>
>> I had several debates about the moral virtues of doing this and realize
>> that no school wants take responsibility for releasing such a Patch.
>>
>> All things considered, I'm going to look into applying this patch
>> locally. I'm convinced its our only hope of encouraging adoption.
>>
>> So, where might one begin when looking to re-write this evil (un)patch?
>>
>> Thanks,
>> Anthony.
>>  
>
> _______________________________________________
> Yale CAS mailing list
> cas@...
> http://tp.its.yale.edu/mailman/listinfo/cas

*****************************************************************************************
To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html
*****************************************************************************************
_______________________________________________
Yale CAS mailing list
cas@...
http://tp.its.yale.edu/mailman/listinfo/cas

[Benn Oshrin-2]

Andrew Petro <apetro@...> wrote on May 6, 2008 10:47:48 AM -0700:

] I worry that implementing this feature locally multiple times invites
] redundant effort and local adoption of less-ideal implementations of
] this feature than could be achieved centrally.  If one is going to be
] passing passwords around with CAS, one wants a solid, considered,
] secure  implementation that passes the information securely and
] authenticates  the the services before giving them the password and
] that doesn't break  anything.  It seems a waste to invite people to
] locally trip over these  issues for lack of a shared implementation
] of this feature.
]
] Rutgers/Benn Oshrin have a thread going about where CAS can go next
] and  what additional extension points/features would be welcome.
] I'll look  to engage that thread on this idea and invite you and
] other interested  people to chime in.

I think I generally agree with the overall assessment which is that
while nobody particularly likes this feature, enough people have a
legitimate need for it that there should be some level of "support" for
it, even if it requires jumping through some extra hoops and signing a
disclaimer.

I would imagine that the "official" implementation of this would be
tied into the CAS 4 roadmap.  However, given that some people may not
want to wait while the roadmap is developed and revised, we can
certainly start a discussion on the dev list much sooner as to what
might be considered a legitimate approach.

To be clear, Rutgers does not have a long-term interest in developing
this feature.  While we are happy to help guide the conversation, and
maybe even endorse an approach, any development required by a solution
accepted by the community will need to be provided by the community.

-Benn-
_______________________________________________
Yale CAS mailing list
cas@...
http://tp.its.yale.edu/mailman/listinfo/cas