Cheers, Proxy tickets and proxy granting tickets are bearer credentials. When you grabbed the tickets, you became the bearer, and could then participate in the CAS protocol in all ways as the intended bearer of those tokens.
CAS authenticates the identity of the proxying service on issuing a PGT, by pushing the PGT to an https:// URL. That https:// server-side SSL cert is the proxying service's credential to obtain a PGT and that https:// URL is revealed in the validation response for all proxy tickets obtained from that PGT. PGTs are also bearer credentials. The proxying service uses its PGT to obtain PTs. The idea is that proxying services should protect their PGTs from hijacking by not exposing them. They should be protected from eavesdropping and man in the middle attacks by their transport via https:// when CAS vends the PGT and when the service redeems the PGT to obtain PTs. But there's no magic here. If the proxying service does something insecure with that PGT bearer credential, like displaying it to users, then anyone laying hands on that PGT can masquarade as the proxying service. It might be an interesting enhancement for CAS to e.g. authenticate the calling service on the /cas/proxy call, but that would just move the service authentication a little closer to the vending of the PT, which would still be a bearer token. Making PTs not-bearer-tokens in the general case would be difficult in that it's not clear how a CAS client library ought to authenticate the bearer of a PT except that the bearer is bearing a PT. Of course, there's nothing preventing your proxy-ticket-accepting application from authenticating requests in multiple ways in its specific case, i.e. it could restrict based on apparent remote address, require a client-side SSL cert on the request, *and* require a valid PT. That's actually a kind of cute idea. If you would end up enhancing CAS client libraries to implement support for that, would be a wonderful thing to share the resulting code. Kind regards, Andrew On Tue, Jun 11, 2013 at 6:00 AM, n99 <[email protected]> wrote: > Hello > > I have configured clearpass to release credentials using proxy cas. > > I have configured the clearpass-configuration.xml to have one host in the > "allowedProxyChains" bean for testing which is my own host. > > The clearpass Cas20ProxyReceivingTicketValidationFilter does the check to > make sure the host that requested the Proxy Ticket obtained through > > > https://cas-server.me.edu/cas/proxy?targetService=https://cas-server.me.edu/cas/clearPass&pgt=TGT-1-dfY33r3r3r3r3....etc > > is the same as this host in "allowedProxyChains" or an > > "org.jasig.cas.client.validation.InvalidProxyChainTicketValidationException" > is thrown. > > Is is all fine. > > However if I grab the proxyticket that is returned from > > > https://cas-server.me.edu/cas/proxy?targetService=https://cas-server.me.edu/cas/clearPass&pgt=TGT-1-dfY33r3r3r3r3....etc > with the response > > <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> > <cas:proxySuccess> > <cas:proxyTicket>ST-16-a...etc</cas:proxyTicket> > </cas:proxySuccess> > </cas:serviceResponse> > > and use wget or such like from any other server clear pass validates the > request and passes credentials to that machine. > > Should clearpass be also validating the request for the password also comes > from the same machine that requested the Proxy Ticket? > > Or is it an impossible scenario that Proxy Tickets can be hijacked? > > Cheers > > > > > -- > View this message in context: > http://jasig.275507.n4.nabble.com/clearpass-security-question-tp4659834.html > Sent from the CAS Users mailing list archive at Nabble.com. > > -- > 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
