Service Ticket Not Removed from Browser URL, After Authentication

[Bobby Esfandiari]

Hello All,

As the subject shows, I'm trying to figure out a way to strip the Service Ticket out of the browser URL after a user has been authenticated and allowed to access a resource.

Everything seems to be working properly in terms of functionality for the user, but the Service Ticket is still present. The CAS Protocol Diagram indicates that it should be stripped off after the protected service validates the ST, but that's not happening in my case.

My service is using Spring Boot with spring-security-cas, so please let me know if I'm in the wrong place. I'm not sure how much interplay exists between Spring and CAS for this client module, but I've seen some very helpful responses here before so I thought I'd try.

I even tried to specifically set the Artifact Parameter in the ServiceProperties bean to "ticket" (even though it should be that by default), but nothing changed. I've also looked through the spring-security-cas code and haven't come across any code that would be removing the ticket.

This is creating some problems with routing in the front end, so I'd appreciate some advice on how to do this and send the 302 to the proper URL (without the ticket parameter).

Thanks in advance!

[Ray Bon]

Bobby,

The ST parameter should be removed by your service (or spring security cas) when it performs a redirect after validation. The target url should be the one the user was trying to get to originally.

Is the request with the ST a 302?

What is the URI of the secured page that you are trying to access?

Ray

-- 

Ray Bon

Programmer Analyst

Development Services, University Systems

2507218831 | CLE 019 | rb...@uvic.ca

I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations.

[Bobby Esfandiari]

Hi Ray,

That's the outcome I was hoping for given the docs. I just wasn't sure if spring-security-cas works the same way since, I didn't see where it would strip out the ticket in that package's source code.

I did notice that the response is coming back with a 200 instead of a 302, which is different than what's outlined in the CAS protocol. Not sure why this would be though, I don't see anything in the current config that would do this.

The GET request's Request URL:

https://localhost/?ticket=ST-3-R9wC28zg5JOm-2y0LsP1ELdlu7lSPqXBa6nYgp3fGdmUIkhpowR53vYq-j--oWHMgcad2CBbqEYpsCrE-localhost

And that's where I'm sent to after, with the ticket parameter + value still present.

[Ray Bon]

Bobby,

I looked at an odd bit of code that I have (not spring security) and it does the work that you are seeking. I also logged into one of our applications that does use spring security and it moves through a login page.

localhost/app/protected/a

localhost/cas?service=localhost/app/login

localhost/app/login?ticket=ST...

localhost/app/protected/a

The login 'page' can be strictly server side.

Ray

[Bobby Esfandiari]

Ray,

Thanks for those steps. They look about the same as what I see until the last one, where the ticket is not being removed.

Just to clarify, you're using custom code to strip out the ticket and its value in those apps? Right now I'm manually stripping out the ticket using Angular in the front end, but that's not an ideal solution. It'd be really nice if spring-security-cas would do it out of the box and I'm trying to understand why that's not happening.

[Ray Bon]

Bobby,

One option might be to store the secured destination url in the session. In the login page, retrieve that url and redirect.

It might be too presumptuous for spring security to do the redirect in case you wanted to interrupt the post log in flow.

Ray

[Bobby Esfandiari]

Thanks Ray, much appreciated!