spring security, spring remoting, cas proxy authentication

[piotrj]

[*] What URL are you submitting the proxy ticket to? If the request was submitted to the filterProcessUrl (/j_spring_cas_security_check) regular service ticket authentication is performed which will do redirects.

Exactly - my request is submitted to filterProcessUrl (/j_spring_cas_security_check)

public class CasAuthenticationCommonsHttpInvokerRequestExecutor extends
		CommonsHttpInvokerRequestExecutor {
	
	@Override
	protected PostMethod createPostMethod(HttpInvokerClientConfiguration config) throws IOException {
		PostMethod postMethod = super.createPostMethod(config);
		String ticket = ((CasAuthenticationToken)SecurityContextHolder.getContext().getAuthentication()).getAssertion().getPrincipal().getProxyTicketFor("https://10.128.17.191:8443/securityTest2/j_spring_cas_security_check");
		postMethod.addRequestHeader("ticket", new String(Base64.encode(ticket.getBytes())));
//		postMethod.addParameter("ticket", new String(Base64.encode(ticket.getBytes())));
		return postMethod;
	}
}

[*] Did you ensure to set authenticateAllArtifacts property to true as is done in the sample?

Yes, it was set to true

[*] I also noticed that you are looking in the request headers for the proxy ticket. I am not aware of this being part of the specification. As far as I know the proxy ticket should be present as a HTTP parameter. Is there any documentation that you have found that allows the ticket to be specified as a header?

I didn't find that in documentation. When I was setting ticket as parameter

postMethod.addParameter("ticket", new String(Base64.encode(ticket.getBytes())));

I was getting null when trying to get it out from request in filter. My guess is that why is difference in URL in filter. It was not /j_spring_cas_security_check but it was remote method's I invoke: /remoting/RemoteTestService. Parameter was somehow stripped off while processing? Not really sure, but when I changed it to request header it was present in request. Hope this will be helpful.

[Rob Winch]

Thank you for your response. I'm not certain why if you followed the bullets I outlined and used the branched code why this would not work. As I mentioned before, there are integration tests using commons httpclient that demonstrate it working. I assume that you have tried submitting as a parameter when using the branch code to the URL you wanted (i.e. not the filterProcessUrl)? I'm trying to ensure that I did not miss something when implementing the code in this branch.

Exactly - my request is submitted to filterProcessUrl (/j_spring_cas_security_check)

If you are submitting to j_spring_cas_security_check, how are you getting your application to process the actual request you want? For example if the purpose of the request was to save a message, how are you getting this code to be invoked?

I didn't find that in documentation. When I was setting ticket as parameter

postMethod.addParameter("ticket", new String(Base64.encode(ticket.getBytes())));

I was getting null when trying to get it out from request in filter. My guess is that why is difference in URL in filter. It was not /j_spring_cas_security_check but it was remote method's I invoke: /remoting/RemoteTestService. Parameter was somehow stripped off while processing? Not really sure, but when I changed it to request header it was present in request.

So it sounds like you are using the header value as a work around.

[piotrj]

I couldn't run this integration test - something was wrong about path - probably with 'Documents and Settings'.

I think the best way is to test my code yourself, so I send it.
security-remoting-cas.zip is my working version.
security-remoting-cas-965 is with branch - You have to add your code or add important dependecies (attachment with it was too big to send).
Maybe You will find what I did wrong or why it doesn't work as desired.

[Rob Winch]

Thanks for providing feedback on this solution. This will help to ensure the feature works for those that need it. I will try and take a look at what yo have attached later tonight.

Do you mind describing the issue you had with running the sample? What OS (I'm guessing Windows) and what OS version do you use? A complete stack trace and logs would be helpful. You can get more information if you use ..\..\gradlew.bat -d -S appTest.

Thanks again for your contributions back,

[piotrj]

No problem.

My OS: Windows XP Professional with Service Pack 2
Log in attachment.

I'm not familiar with gradle. Honestly speaking I didn't know such thing exists until now. So forgive my ignorance if the problem is trivial.

[Rob Winch]

I did not have time to look over your code in detail. I will have to do that this weekend. A few things jump out at me when I look over the attached code:

In security-remoting-cas-965.zip/security.tests/ the CasAuthenticationCommonsHttpInvokerRequestExecutor has a few things that look like they might cause the redirect

The code is requesting a proxy ticket for /j_spring_cas_security_check, but it looks like the the request is being submitted to https://10.128.17.191:8443/securityT...oteTestService. This means that the service used to authenticate the proxy ticket will not match. To fix this you probably want to use postMethod.getURI().toURL().toExternalForm() or something similar for the argument to getProxyTicketFor method.

createPostMethod(HttpInvokerClientConfiguration config) throws IOException {

                ...
		String ticket = cat.getAssertion().getPrincipal()

			.getProxyTicketFor("https://10.128.17.191:8443/securityTest2/j_spring_cas_security_check");

		postMethod.addParameter("ticket", new String(Base64.encode(ticket.getBytes())));

This should not be Base64 encoded. Just use the String value. The value will automatically be form encoded by http commons.

The last thing I am not sure if it is an issue or not since I don't have all of your code. Did you ensure that you had a version of AbstractAuthenticationProcessingFilter that calls the successfulAuthentication with a FilterChain argument? I was not able to determine if you had noticed that this was also a change in the code. If it is not used, then the code will not work either.

I'm not familiar with gradle. Honestly speaking I didn't know such thing exists until now. So forgive my ignorance if the problem is trivial.

Not a problem...things should just build (you shouldn't need to know anything about gradle other than the command to run things). I appreciate your time in telling me that it is not working and providing information on it. I'm a Linux guy myself so it is good to have someone let us know when things are broken on Windows. It looks like the Gradle issue you are having is related to this. Luke has fixed that in master, but I have not merged with the changes that fix this. I will update the branch this weekend to make it easier for you to try things out (I'll post an update when I do).

Let me know if you find the initial pointers fixed your problem, otherwise I will try and dig in this weekend.

Thanks again for taking the time to provide feedback.

[Rob Winch]

I rebased the branch from master so it should fix the gradle issue you had.

I went ahead and tried to run your sample locally. The changes I mentioned were the only things needed for me to fix authentication. However, since I had never done anything with Spring Remoting I did not realize that specifying the POST parameter would break Spring Remoting. This is because it expects serialized data in the body and not the form encoded ticket. This means despite this being against the specification, you likely will need to use the header if you want to use both CAS and Spring Remoting.

The takeaways I got out of this is that I should probably provide a method that can easily be overriden for obtaining the artifact (ticket). This would be similar to how the UsernamePasswordAuthenticationFilter allows the obtainUsername(HttpServletRequest) method to be overridden to obtain the username. This would allow you and others to just override a single method to use a header.

Another take away is that the sample should demonstrate how to respond with an HTTP status code for failed authentication when doing proxy authentication. This would give you better error information if the proxy ticket was unable to be authenticated (i.e. the service ticket did not match the one used to create the proxy ticket).

The last takeaway is I should probably ensure there is a bit better logging going on to help users troubleshoot issues better.

Thanks again for your feedback,

[samirn]

I have a similar issue. However I am unable to make the stateless configuration work. I posted my particular issue here :
http://forum.springsource.org/showth...load-balancing

Any help is greatly appreciated.

[chrispaul3]

You likely do not want to do this anyways since there would be an extra request each time you want a protected resource. Additionally stateless authentication does not get used so you have to get a new proxy ticket each time. The branch does not require a redirect for proxy ticket authentication and it allows for stateless mode to be used when doing proxy ticket authentication.

__________________
tissot prc200 automatic gents watch