I agree the right improved feature here is for ClearPass to only accept proxy tickets with blessed non-empty proxy chains, which is to say for ClearPass to reject service tickets.
I'd like to put a little context behind the current behavior of accepting service tickets. In concept, what's going on in CAS is end-user authentication (obtaining a TGT representing an SSO session, obtaining STs off of that to authenticate to particular applications) and then the end-user delegating authentication authority to the applications he logs into (proxy tickets). I log into uPortal via CAS and thereby delegate to it authority to authenticate as me to services that trust my authority delegated through the portal. And so uPortal might then be able to authenticate to ClearPass on my behalf. The conceptual abstraction is that uPortal is able to use a sliver of my authority to authenticate to a sliver of the stuff I would have been able to authenticate to. That was the design. That's why service tickets are valid wherever any proxy ticket would have been valid in the Yale Java CAS client and, until Misagh's patch is realized, in the Jasig Java CAS Client. It turns out that design concept needs evolved, that there are use cases where you want an application (itself authenticated via proxy callback) exercising a user's delegated authority to access services in addition to rather than just a subset of those you'd have allowed the end user to access directly. I.e. ClearPass. Allow the user to exercise ClearPass when delegating authority through uPortal or through the OWA bridge but not allow the user to exercise ClearPass when exercising his authority directly without delegation. Okay. CAS is already fully communicating the proxy chain on PT validation, so this is just an evolution of the client libraries. This additional discrimination of what tickets to accept can already be achieved today in the Jasig Java CAS Client by adding an additional filter to reject service tickets that the Client would otherwise have accepted, since the proxy chain is exposed in the session (or Request) after the Client parses it. This pull request seems to be working towards making that extra ServiceTicketRejectingFilter unnecessary, instead adding a configuration option to the Java CAS Client ticket accepting filter to configure whether it should accept Service Tickets, that is, tickets with empty proxy chains. https://github.com/Jasig/java-cas-client/pull/24 Were that option available in the Java CAS Client, the ClearPass usage would configure it to reject Service Tickets, and that would block end-users from directly authenticating to the ClearPass service to view their password. I suggest that's the right path forward. Kind regards, Andrew On Thu, Dec 13, 2012 at 11:17 PM, Misagh Moayyed <[email protected]>wrote: > I’d like to add a few notes here on forcing clearPass to only be available > via proxy authentication. **** > > ** ** > > I recently discovered that turning off the casAuthenticationFilter alone > is not sufficient to disable clearPass from directly rendering credentials > on the page. It is still possible for clearPass to render credentials on > the page using the following URL:**** > > > https://sso.server.edu/cas/login?service=https://sso.server.edu/cas/clearPass > **** > > ** ** > > This is seemingly due to the fact that the Java CAS client and > specifically its proxy-enabled validation filter allows for an empty proxy > chain that is constructed by the above URL. Until the next CAS client > release, the quick remedy is to provide an extension of the > ‘Cas20ProxyTicketValidator’ which would be responsible to disallowing empty > proxy chains. **** > > ** ** > > Regards, **** > > *-*Misagh* > > * > > ** ** > > *From:* Domazlicky, Eric [mailto:[email protected]] > *Sent:* Wednesday, December 05, 2012 10:04 AM > *To:* [email protected] > *Subject:* [cas-user] Note to ClearPass users of CAS 3.5**** > > ** ** > > I would recommend to any users of CAS 3.5 with ClearPass configured to > take a look at the changes in the pull request for CAS-1209:**** > > https://issues.jasig.org/browse/CAS-1209**** > > https://github.com/Jasig/cas/pull/151**** > > ** ** > > Basically the pull request removes the CAS Authentication Filter from > clearPass-configuration.xml. If you don’t remove the CAS Authentication > filter your user’s cleartext passwords can be disclosed if an attacker > gains access to their browser session and visits the clearPass URL (usually > https://server.edu/cas/clearPass). With the CAS Authentication Filter > disabled in clearPass-configuration.xml, the remaining CAS Proxy Filter > protects against an attacker seeing the cleartext password, even if they > gain access to the user’s browser session by use of the allowedProxyChains > attribute. **** > > ** ** > > This may seem like a pretty remote security issue since the attacker has > to gain access to the users’ browser session first. But at least in a > Higher Ed environment I think this happens more than we realize (students > walking away from computers without logging off etc..). **** > > ** ** > > ---**** > > Eric Domazlicky**** > > Portal/E-Mail Administrator**** > > Tacoma Community College**** > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user**** > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
