Secure Portal - My First Observations

Well, it's been an interesting few days. A colleague and I spent some quality time building a prototype of a secure portal. This is part of a larger project to provide single sign-on from the Windows desktop to back-end applications such as SAP, via portlets.

For the prototype, we used: -

MS Windows Server 2003 Enterprise Service Pack 2
MS Active Directory 2003
WebSphere Portal Express 6.1.0.1
Tivoli Access Manager for eBusiness 6.1 ( including GSKit, Policy Directory, WebSEAL etc. )

In essence, WebSEAL uses a "junction" to intercept certain URLs e.g. /wps/myportal etc. to direct users to its own HTTP server instance, where the user is requested to sign on using Basic Authentication ( log-in window ) or Forms-based Authentication ( log-in form appears in page ). Once the user is authenticated, they are directed back to the portal server.

TAM can also be used to provide authorization, so that portal resources ( portlets, pages etc. ) can be authorised by TAM roles, rather than the default of using LDAP groups.

The order of play was roughly: -

• Install and configure Active Directory
• Install Portal
• Configure Portal to use AD
• Install TAM
• Configure TAM to work with AD
• Configure Portal to work with TAM

I'm going to do a more complete write-up as time permits, but we did learn a few lessons: -

• Don't try and install software on an Active Directory Domain Controller ! One wouldn't do this in production,
  
• Use ADSI Edit (adsiedit.msc) to validate AD as an LDAP, check Distinguished Names etc.
  
  http://technet.microsoft.com/en-us/library/cc773354.aspx
  
  
• Ensure that the user used to "bind" TAM to AD has the proper level of authority, including Domain Admin and Schema Admin
• Ensure that the portal admin. user created in AD has an appropriate group e.g. we used PortalAdmin and PortalAdmins respectively
  
• Follow the WebSphere Portal Information Centre when configuring Portal and TAM
• It's possible to set up a transparent junction in WebSEAL so that URLs such as /wps/myportal can be passed through TAM. This means that the URLs are more "portal-like" rather than the default of, say, /wpsv61/wps/myportal.
• Remember that, whilst TAM can populate users and groups into AD, the same is not true, by default, in reverse. Therefore, it is necessary to use tools such as TAM's own pdadmin to import users and groups from AD into TAM. This caught us out when we tried to authenticate to portal via an AD user that did not yet exist in TAM !
  
  It is possible to automate the AD -> TAM population, using the included Tivoli Directory Integrator software. It really depends what mechanism one chooses to use to manage users e.g. AD, TAM or an alternative solution such as Tivoli Identity Manager

Will post more when I get some more time ...