2

we have a custom web application hosted on a tomcat server and want to achieve to get an LTPA2Token when logging into this application on tomcat. All applications on both application servers are using the same LDAP.The application on the tomcat server cannot be hosted on a Web Sphere Application Server (WAS).

The idea is the following:

1.Type in username and password on the tomcat web application via web browser. 2 Generate a custom token with the credentials 3. Send those credentials to a custom TAI on a Web Sphere Application Server

The question is, if we can obtain a LTPA2Token from the TAI after the succesful login and send it back to the tomcat application so that the LTPA2Token can be set in the browser?

Thanks and best regards Benjamin

ﾤ ﾡ
  • 5,669
  • 6
  • 43
  • 57
Ben
  • 1,579
  • 4
  • 20
  • 34

2 Answers2

1

This might work, but both servers should be on the same sso domain e.g. tomcat.company.com and websphere.company.com. In WebSphere admin console in Security > Global security > Single sign-on (SSO) specify in Domain name for example .company.com. You could define several domains there, but will be easier to debug, if there will be only one.

The easiest approach would be to create dummy web app with one jsp that would send redirect to your tomcat app. Protect that application with JEE security and create TAI that would intercept call to this app, and create TAIResult based on passed token with user id using:

public static TAIResult create(int status, String principal);

This will find a principal user in WAS registry, authenticate it and create LTPA token. Then will pass to your page, which in turn will redirect to tomcat, setting cookie in the browser.

Maybe it would be possible to just do it in the TAI, but I've never tried that solution (and the solution with custom app will work).

However you have to create good custom token, otherwise someone else might be able to use your TAI to authenticate as someone else.

PS.
Why your tomcat app cannot be deployed on WAS? Maybe it will be easier to solve that than to create this TAI solution?

Gas
  • 17,601
  • 4
  • 46
  • 93
  • Thanks for your answer. There are several reasons for us why deploying this app on WAS is too much effort. The two main points deal with transaction management (WAS does not provide a standard JTA javax.transaction.TransactionManager) but only proprietary APIs. In addition, our application has its own asynchrounous Thread-management which has to be changed in order to get it work on the WAS. If you are interested in details, you can read this: http://www.bpm-guide.de/2012/01/22/run-activiti-on-ibm-websphere-application-server-with-camunda-fox/ – Ben Aug 21 '14 at 07:39
1

You certainly don't want or need to pass credentials (e.g. password) to WebSphere; the TAI process has no need of an actual password - the very nature of the framework is to allow trust relationships via alternate means.

Additionally - there's also no pressing need to roll your own TAI class and associated proprietary SSO protocol (token, encryption, etc).

WebSphere 7+ ships with both OAuth and SAML TAIs out of the box (though configuration is required to set them up). This gives you two open standard specifications to choose from - both of whom have wide Java library support for your Tomcat app. You end up writing no code on the WebSphere side, and as an added bonus you can use IBM PMR support process if anything goes wrong or doesn't appear to work - not the case with the home brew TAI solution as it is purely custom code. Your Tomcat half of the solution would also work with other service provider applications on other platforms in the future. These SSO protocols are widely adopted and mature - vetted by an entire industry of web developers, with few or no attack vectors if implemented properly. DNS or domain alignment is also not necessary with these approaches - they are designed to work across domains.

Scott Heaberlin
  • 3,364
  • 1
  • 23
  • 22