Wednesday, February 16, 2011

WebSEAL Landing Page Personalisation

Creating a Landing Page for WebSEAL authenticated users can be a useful technique for ensuring a consistent user experience, providing a means of delivering messages to end users and providing a personalised experience. This does not mean that you have to invest in a heavy-weight portal product to provide this functionality, though.

Simple ASPs, JSPs, PHP scripts, PERL scripts and any number of other scripting technologies can be used to greet the user and personalise the landing page without resorting to performing a lookup in the credential store for information. How can we do that? Well, to reuse a well-known modern-day philosopher's phrase, it's simples!

WebSEAL can pass the User ID of the user to the protected landing page in an HTTP header called IV_USER. We can pick this up as follows:

my $user = $ENV{"HTTP_IV_USER"};

String user = request.getHeader("iv-user");

user = Request.Headers["iv-user"];

$user = $_SERVER['HTTP_IV_USER'];

Note: The names of the HTTP Header will vary depending on the scripting technology being used.

So now I have my User ID, I can make use of this information in my page to say something like "Welcome sswann". I nice touch, I'm sure you will agree.

But of course, WebSEAL can be so much more powerful that that. It can also send IV_GROUPS out of the box which will be the groups that the user is a member of. With this information, we could build a list of hyperlinks that are available to that user. In code/pseudo code, that could look like this:

String groups = request.getHeader("iv-groups");
if (groups.indexOf("administrators") >-1) {
   // Show a link to the administrator's application
if (groups.indexOf("auditors") >-1) {
   // Show a link to the auditor's application

Wonderful, you might think, with the obvious next question being "what else can I do?"

Well, we could add any attribute assigned to the user object in the TAM LDAP as a similar HTTP header object. To do so, though, is a two-step process:

Step 1: WebSEAL Configuration
Let's assume that we want to make the forename and surname for our user available to our landing page. We need to configure WebSEAL to retrieve these attributes from the LDAP and make them available within the credential. To do so, the WebSEAL configuration file needs updated as such:

TAM_CRED_ATTRS_SVC = azn_ent_cred_attrs

[aznapi-configuration ]
cred-attribute-entitlement-services = TAM_CRED_ATTRS_SVC

person = azn_cred_registry_id

tagvalue_credattrs_sn = sn
tagvalue_credattrs_givenname = givenname

Step 2: Junction Configuration
Next we need to ensure that we pass these attributes to our landing page. On the WebSEAL junction hosting this "personalised" landing page, we would perform the following pdadmin commands:

pdadmin> object modify /WebSEAL/webseal_instance/junction_name set attribute HTTP-Tag-Value credattrs_sn=surname
pdadmin> object modify /WebSEAL/webseal_instance/junction_name set attribute HTTP-Tag-Value credattrs_givenname=forename

Now, we can extract the HTTP header variables for forename and surname and provide a "Welcome Stephen Swann" message because these header attributes will be passed to our landing page process:

String surname = request.getHeader("surname");
String forename = request.getHeader("forename");

We haven't had to perform any lookups in a data repository and our landing page can be kept very simple indeed with just a couple of lines of scripting.

Tuesday, February 15, 2011

ITIM Accesses and SoD

Just like all enterprise applications, IBM Tivoli Identity Manager has evolved over the years. New releases bring new functionality or even a new look and feel (as per v5.0 move away from the Ice Cream Parlour look of v4.x). The new functionality is typically a response to customer needs, competitor functionality or a general shift in focus.

Recent functional additions have included Accesses, Separation of Duties and Recertification. Fabulous you might think. However, I can't help thinking that some of these functions could be improved to make them actually work in a real world scenario.

Accesses can be applied to roles and groups and allow end users to "request" these accesses through the self-service screens. This is great as it now provides us with a means of allowing users to request access to a File Share, for example. Or is it great? If all file shares were made accessible you might find that there are a lot of accesses that the end user needs to wade through. And what if the user isn't even entitled to an AD account which is a pre-requisite to getting access to a File Share? Well, in the ITIM world, the File Share access would still be displayed on screen!

What if you manage external users inside your ITIM. Can these external users (who may only access a web portal page, for example) now see the structure of your AD Groups because they are now accesses?

In short... why are accesses not locked down by ACIs in the same manner as almost all other ITIM data objects?

Separation of Duties
SoD has become a big issue in recent years and it is terrific that it is being addressed in ITIM. However, the implementation is restricted to Static Role clashes only. If, for example, I have a role in ITIM assigned to me by virtue of some attribute on my person record (ie. a Dynamic Role) then this cannot be used in the evaluation of SoD rules.

Take this example: I'm assigned the role of Approver because my Job Title is Manager (via a Dynamic role). A superior of mine assigns the role Auditor to me (via a static role). Ideally, I want to create a rule that states that Auditors cannot be Approvers. Unfortunately, I cannot create this rule in ITIM as the role of Approver is a Dynamic role.

I have no doubt that these issues are already well understood within IBM and that the next version of ITIM will address them. If that is not the case, that would be a terrible shame and a missed opportunity. Maybe my thoughts can help steer the product owners in the right direction? Do I have that amount of clout?

Thursday, February 03, 2011

WebSphere And IHS - What Gives

As regular readers will be aware, the majority of my professional work is in the field of Identity and Access Management. Indeed, it is with IBM Tivoli products that I play with day-in and day-out.

IBM Tivoli Identity Manager (ITIM) is a J2EE application which runs within a WebSphere Application Server instance or cluster and I often-times develop mini Java apps as either a helper for ITIM or as an extended authentication service for Tivoli Access Manager for e-business. The curious thing about ALL of these Java applications, however, is that from a user session perspective, they are short-running (typically) and don't really require any state to be maintained during that short interaction with the user.

In the WebSphere world, it seems to be good practice to deploy the IBM HTTP Server (which is a hybrid of the Apache HTTP Server). There are a number of reasons as to why this is a good idea including:
  • it adds a layer in front of your application server
  • it can perform load balancing
  • it can provide caching services
  • it can provide port translation
  • it can help maintain state within a clustered environment

All of this is fine and well, but remember... I work in a field where I typically have a WebSEAL reverse-proxy in place which can provide almost all of the above. Where it might fall down, is when session state becomes crucial.

That said, in a world where the applications purring away inside that WebSphere cluster will only ever see short running sessions (ie. log in, change password or log in, approve a request) then state isn't an issue.

In effect, surely it is quite acceptable to build your infrastructure without the added overhead of the IHS (where WebSEAL is already in place).

I've had this conversation a number of times down the years and the conclusion I've always come to is that the IHS in my configuration is pretty superfluous. However, it is "good practice" and sometimes it is easier to deploy it than have the political bun-fight with the powers that be who point at these architectural best-practices and tell me I can't deviate from the infrastructure design.

So this begs the question. Who writes these best practices/guidelines and can they please word them in such a way that allows those out in the field a certain amount of flexibility when the occasion demands?

NOTE: Should the application hosted within the application server be a long-running enterprise-scale application that is mission critical... please, please, please deploy the IHS. In other words... make sure you deploy components for the right reasons and not just out of fear because of some design pattern dreamt up in some lab by someone who has never deployed this stuff in a production environment!