Topic
  • 3 replies
  • Latest Post - ‏2014-02-15T14:10:54Z by george.baker
george.baker
george.baker
344 Posts

Pinned topic Web Express Logon using Active Directory and WAS 8.5

‏2013-10-17T15:19:56Z |

I have a requirement to perform single signon for a HATS application running on WAS v8.5 on a Windows Server in an Active Directory forest.  The user's Windows ID is the same as the RACF user ID, so I do not need a JDBC database to map network IDs to RACF IDs.  I understand how WEL works and how to set up DCAS.

The part I have questions on is the WebSphere setup for this environment.  Is there a tutorial, redpaper, redbook, etc. that can help me?

Also, when writing the WEL plug-in is it safe to assume that I can use a statement like:

String username = request.getUserPrincipal().getName();

Are there any special setup issues with WebSphere and/or the Active Directory to accomplish this?

As long as this environment has been available I'm certain that someone has written a plug-in for this environment, even if mapping the Windows ID to a RACF ID was required.

  • smithkenny
    smithkenny
    43 Posts

    Re: Web Express Logon using Active Directory and WAS 8.5

    ‏2013-10-18T15:44:29Z  

    For the WAS setup, make sure you set the classloader policy to application first. 

     

    For the WEL plugin, yes, that statement will work, unless you have some other app like siteminder inserting HTTP session vars into the header. You likely need a custom network plugin, but should be able to use the DCAS certificate based Credential Mapper Plugin.

    With WAS, and AD, nothing special. Use the wizard for creating a connection to AD as an LDAP source. I recommend a federated policy rather than a single LDAP source. 

  • george.baker
    george.baker
    344 Posts

    Re: Web Express Logon using Active Directory and WAS 8.5

    ‏2014-02-14T20:11:24Z  

    This works fine; however, there is a caveat, not with the network plugin, that was a piece of cake, but how you set up the authentication.  Do not use WAS to do the authentication with Active Directory, use IIS as your Web server and let it do the authentication.  I implemented IWS with NTLM.  You can set up WAS to authenticate your access to the HATS application, but your WEL macro will fail.  The user credentials are in the header when the HATS application is accessed, in fact I extracted the remoteUser() from the header and displayed in in the template, but when HATS launches the WEL macro it is spawned in a separate thread.  This blocks the new thread from accessing that header and you will always get null from getRemoteUser().  

    The message here is that when using WEL you cannot enable Application Security for your HATS application or the header will not be accessible.  This appears to be a J2EE security restriction because the macro is run in a separate thread.

    I hope this saves someone else a lot of lost time trying to make this environment work.

  • george.baker
    george.baker
    344 Posts

    Re: Web Express Logon using Active Directory and WAS 8.5

    ‏2014-02-15T14:10:54Z  

    A minor modification to my previous statement.

    Using Active Directory for Web authentication works fine; however, there is a caveat, and it is not with the network plugin, that part is a piece of cake.  The issue is how you set up the authentication.  Do not use WAS to do the authentication with Active Directory, use IIS as your Web server and configure it to do the authentication.  I implemented Integrated Windows Authentication (IWA) using NTLM.  If you configure WAS to do the authentication rather than externally via IIS WEL macro will fail.  WAS will do the authentication and place the credentials into the header, and when the HATS application is accessed the credentials are there.  To ensure that I extracted the remoteUser() from the header and displayed in in the template.  However, HATS launches the WEL macro in a separate thread.  When  this happens WAS does not allow your plug-in to access the remoteUser(), thus returning null from your getRemoteUser() command.  This is an architectural restriction.  The way around it is to perform your authentication and insertion of credentials before the request gets to WAS.

Feed for this topic