TAMeb Naughty Installer - SMS Part 1

I've long been an admirer of IBM Tivoli security software. The components mostly do exactly what you would expect.

However, I've always been a bit confused by the means and mechanisms used to install the software. This week, I had a brilliant example of pure laziness on the part of the developer within IBM who had responsibility for coding the installer for the Tivoli Access Manager for e-business SMS component!

Consider the following facts:

• Windows 2008 Server (64-bit) platform
• WebSphere 7 already deployed
• Tivoli Access Manager for e-business Policy Server already deployed and configured

Installing the SMS component should be as simple as running the installer from the TAMeb Base package and following the on-screen instructions. Unfortunately, on my system, the installer failed to recognise that WebSphere was installed and insisted on installing its own version of WebSphere.

And the reason for this failure to detect the WebSphere installation? I could plainly see that it was deployed at d:\IBM\WebSphere\AppServer. I could plainly see that WebSphere was running by checking the list of Windows Services. The installer, however, could not.

It was time for some code-hacking to determine what was going on and after a little bit of digging around the installer, I found that it was checking for a WebSphere installer by looking through the Windows registry.

Interesting, I thought. Surely there must be a reference in the registry for WebSphere? Well, that may indeed have been the case, but it certainly wasn't where the installer was looking for it!

A colleague of mine had installed WebSphere using his credentials. I was installing SMS using my credentials. The SMS installer was looking for WebSphere registry keys under LOCAL USER in the registry. And they didn't exist there because I didn't install WebSphere!



The addition of the following registry keys (under my session) allowed the installer to recognise the WebSphere instance:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\IBM]

[HKEY_CURRENT_USER\Software\IBM\WebSphere Application Server Network Deployment]

[HKEY_CURRENT_USER\Software\IBM\WebSphere Application Server Network Deployment\7.0.0.0]
"BinPath"="D:\\IBM\\WebSphere\\AppServer\\bin"
"InstallLocation"="D:\\IBM\\WebSphere\\AppServer"
"LibPath"="D:\\IBM\\WebSphere\\AppServer\\lib"
"MajorVersion"="7"

That said, I wanted to install the SMS components on to my D: drive. Do you think that would work? Do you think if I installed the software there that the smscfg routine would work? If you think positively about these questions, then it's time to think again! Check back for the next thrilling episode in the SMS Installation Series!

A Proxy For Google

I was recently asked why I write down my thoughts on Identity and Access Management in a blog. In fact, I was recently asked why I give away all our secrets and didn't I know that my actions were damaging to my long-term job prospects. In effect, educating others means more competition in the job pool.

I have some answers to these questions:

1) I enjoy writing down my thoughts and it helps solidify the concepts in my own head. It also allows me to refer back to past experiences

2) I like the idea that others read my blog and are maybe inspired to take the thoughts and improve them

3) Educating others relieves me of the responsibility of being the custodian of a certain piece of information and allows me to concentrate on learning new things. After all, we should always aspire to learn new things and stretch our imaginations

Having said all that, my time is precious. When viewers of my blog request help, I will try my best to provide guidance and pointers but I may not respond immediately. I don't actually provide this as a service and therefore there is no SLA! Requests should also be thought through - I don't like being a proxy for Google, for example. (You may get a response including a Let Me Google That For You link!)

In short, I enjoy writing my blog and I enjoy helping people but I prefer to help people who have demonstrated that they have already made a good attempt at addressing their problem.

How To Externalise JavaScript in ITIM Workflow

Every now and again, I seem to hit on a problem which requires that my JavaScript seems to be veering towards being environment specific. As we all know, we want our ITIM workflows to be consistent between our development, test and production environments and workflow which contains environment specific code has got to be a bad thing.

But, it happens.

What if, however, we could maintain the same workflow between the environments but externalise the JavaScript to a file. The pain point of altering the workflow between environments would just go away!

Achieving this is really quite simple and has been alluded to in other forums - though rarely in a way that gives the reader all the information they require to complete the task. The following method works with ITIM v5.1.

JavaScript Node
To read an external JavaScript file, we require the following code:

// Open the external JavaScript file

var myScriptFile = new java.io.BufferedReader(new java.io.FileReader("/path/to/file");

var myLineOfCode = null;

var myCode = "";

// Read the file and add each line of code we find to a variable

while ((myLineOfCode = myScriptFile.readLine()) != null) {

   myCode += myLineOfCode;

}

// Close the file

myScriptFile.close();

// Execute the code that we have gathered together

eval(myCode);

Our external JavaScript file can contain any JavaScript code we require for our node:

Enrole.log("external", "Hello world - I'm an external script!");

scriptframework.properties
Of course, to expose the java.io methods to our JavaScript, we need to configure this ability in our scriptframework.properties file (and restart ITIM). Adding the following property to scriptframework.properties will do the trick:

ITIM.java.access.io=java.io.*

And there you go... from within our script nodes, we have access to the java.io classes. We can externalise our scripts. We can read files. We can write files. Why not let me know how you put your java.io capability to use in the script nodes.

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:

PERL
#!c:/perl/bin/perl
my $user = $ENV{"HTTP_IV_USER"};

JSP
<%
String user = request.getHeader("iv-user");
%>

ASP
<%
user = Request.Headers["iv-user"];
%>

PHP
<?php
$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:

[aznapi-entitlement-services]
TAM_CRED_ATTRS_SVC = azn_ent_cred_attrs

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

[TAM_CRED_ATTRS_SVC]
person = azn_cred_registry_id

[TAM_CRED_ATTRS_SVC:person]
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.

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
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?

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!

Let Me Introduce Myself

I get a lot of emails each day (as I'm sure most people do nowadays). Most of it is rubbish and can be binned immediately, some of it is from people I already know quite well and then some of it is from people who are introducing themselves to me. These new people could be people who want to hook up on LinkedIn or Facebook and tend to have job offers for me or are looking for a job.

My first reaction these days is to ask my good friend Google to do a background check on these people. That way, I'll get to maybe see a photo of them - putting a face to a name is always a good thing - and I'll get to see what they are up to, what their interests are and whether there is any point in responding to their introduction.

And so it came to pass that I did precisely this yesterday but with the result that I found someone's Twitter account and their last tweet was asking for payment from another Twitterer via bank transfer. Astonishingly, this tweet also contained my new acquaintance's account details - Sort Code & Account Number.

I pondered this information for only a short time. I had this person's name, address, sort code, account number, list of friends and interests within just a couple of minutes. If I was so inclined, I could have some fun with the information as I'm sure others would dearly like to do.

We should always be mindful that the information we release on to our computers then in to the WWW is accessible by others. Not only can the information be damaging to our reputation, but in the case above, our bank accounts could come under threat. That's not to say that we should stop releasing information, of course. We just need to be a little more careful about what we say, to whom and choose the medium to communicate wisely!