However, the technical solution is only part of the problem; there is still the question of licensing costs.

Will the code be open for other cities/regions to use freely? You should be proud of yourself if you’re one of the few that have made a sustainable contribution to our nation. We need break throughs here, and I’d be happy if it’s from the west coast these break throughs origin.

Yes the TAI would run on the web-application where the authentication takes place. But note that if a replication domain has been set up between other WAS server that hosts other web application the subject created by the TAI will be replicated within the replication domain. This enables SSO, atleast as long as the applications are running on a WAS server. That can of course be a large limitation depending on whether a large number of different plattforms are used.

The TAI vs JAAS-login questions was looked on from a theoritic perspective only. From this overview the TAI implementation had some extra functionality that was needed from our point of view. As the JAAS (and TAI) implementation must be executed in the WAS_EXT classloader the existing JAAS login modules that was used within our system had to be moved from the EAR classloader up to WAS_EXT. Unfortunate these existing JAAS modules had a lot of dependencies and such a move couldn’t be performed within a POC. There for the TAI solution was the primary choice. If the JAAS modules would be implementated as a part of your project a JAAS solution would properly work just fine. But be sure to read about the extra features a TAI can give and counter these against using a IBM specific interface. But as noted already the JAAS implementation will also be referencing IBM classes.

I assume that you would deploy and run your PoC-solution on the same WAS as your web-application then? In a sense your approach seems to have a lot in common with alternative two (having some custom code that gives you a full integration with WAS), only that you achieved it by using a TAI instead of a JAAS-login module. It would be interesting to hear if you considered any alternative solutions before you decided to implement it as a TAI?

One of the main reasons that we have started to discuss a reverse proxy is that we want to reuse the solution for other web applications. For this purpose, having a separate solution in place could be the best alternative. I guess your solution doesn’t work for SSO between different web applications, or am I missing something?

The alternative one has the drawback when it comes to failover and as you point out propagation of the SSO to backend system and also other applications. When Websphere handles the subject of the users there are many positive effects. As part of a proof of concept I have looked in to the TAI usage. The basic concept was to remove the home grown subject storage that doesn’t comply to the JEE specification. As the login procedure is divided in a number of views (entering in username, choosing identification method, possible challenge respsone) the formed-based authentication wasn’t possible.

The solution the POC went for was using a hyrbid of your solution number 3. Instead of bying a expensive reverse proxy the login servlet was recieved two servlet mappings, one not JEE protected and one with form based JEE protection. The basic concept was that the user entered all details needed to perform the authentication against the unprocted servlet. But when all details has been entered (and stored in the web session) the next request went to the protected servlet. As the container now notice that a procted resource is called it checks if the user is authenticated. As this is not the case the container redirects to the login page. This page only performs a redirect back to the protected servlet and this will trigger the TAI which collects the information from the web session runs sets up the subject.

Its a quite non standard solution but works.

Some problem areas

* If the users is allowed to re authenticate themself, for example to a stronger authentication method the websphere specific ibm_logout_servlet must be called to remove the subject. This as the subject may not be changed after creation by the TAI to ensure that all propagated subjects has the same content.
* If the plattform exposes Web Services, how should the Subject be created?
* If external RMI-IIOP calls are made against the a EJB directly how is the subject created?

These question may apply based on the need for using the credentials in the plattform. Mostly this depends if the plattform allows unauthenticated users.

Hope this can help some.

Det håller jag med om. skulle eventuellt vilja skärpa till det ännu mera : “i vissa inte kunnat leverera ett användbar integration mellan byggen och ide”