Good practices and pitfalls when bypassing a SSO system through another server?

Question

I'm in charge of maintaining a web application (Lives on a Tomcat server) which has two different access points, through two Apache HTTPD servers which are outside of my reach.

The two access points are meant to log in user either through a third-party SSO system or a good ol' authentication page which prompts for login and password.

The trick is, this SSO puts a limit on the size of files which can be uploaded or downloaded. As SSO users will need to retrieve and send things heavier than that, I need a workaround for this, most likely simply offering a link pointing to the correct resource location through the other server.

What concerns me here is security, in case someone enters a cleverly guessed address to get a document he's not supposed to. The person in charge doesn't want to hear about a SessionManager to make sure the user has the rights to retrieve the documents, but suggested that I could simply use their JSESSSION_ID to confirm their identity...

I am not sure about how to implement this, and have a serious gut feeling that this will backfire in a quite horrible fashion.

Can anyone who had to deal with a similar problem points some of the pitfalls and possibly share a few useful tips on how to securely bypass this SSO ?

Answer 1

One possible way to implement this is to protect the resources on the non-restricted site with a one-time password with a very short life time. Example:

• User clicks on a link to open a document on the SSO protected site. The link should not provide the document directly.
• The Tomcat server generates a one time password and redirects (using http code 303) the user to the un-restricted site with this password as an http parameter.
• 3. When the browser connects to the un-restricted site, check that the password is correct and provide the document. Delete the password so that it cannot be used again. The password should only be valid for say 30 seconds. You may also record the user's ip-address and validate that.

You should not use the jsession id for this. It is not a good practise to expose the jsession id in a parameter on the address bar or in an html page.

However, you say that the other access point is protected by username and password. If so, will not the user have to log in here anyway? And if so, does not that login protect the resources?

Answer 2

If you provide a link pointing to the correct resource, we need to consider the security.

https://www.owasp.org/index.php/Top_10_2010-A2

The most important thing is XSS and CSRF and solutions are provided in the above website.

Session Hijacking can be another security threat if we provide a direct link which can directly access the resources.