I remember being a follower of a blogger who wrote about IBM Tivoli security solutions and becoming quite concerned for his well being when he "stopped" blogging for a while. When he had gone fully six months without blogging, I had myself convinced that something terrible had happened to him personally.
And now I find that I have done the same thing. My periodical briefings have stopped. But fear not - it's not because of any ill health. It's not because of a change in career. It's not even to do with boredom. It has everything to do with being far too busy and that's the best reason of all for the temporary blip in my output.
But, time flies... and too much time has passed since I last committed my thoughts to writing.
So what has happened since in the last 6 months? Well, the IBM Tivoli re-branding exercise is in full swing with IBM Security Identity Manager and IBM Security Access Manager products having been released.
And what has changed in those products?
ISAM has a brand new deployment process which is greatly simplified. However, for TAMeb users who have deployed their software on Windows, beware? The upgrade process might not behave as you expect? Why? The move to a 64-bit architecture, that's why? Think seriously about any attempt to perform an in-situ upgrade!
You might like to also check compression settings on your WebSEALs - a respected colleague of mine has already encountered some fun and games with those!
And ISIM? Is it just a pure re-branding exercise? Not at all. Some functional additions are definitely welcome like the controls added to the services offering retry operations on failed resources. Account ownership and role attributes look interesting (despite how they have been implemented). Privileged Identity Management is a great addition as is the inclusion of supported web services API.
But core processing that ITIM administrators will know and love is still there!
And what of my work recently? Well, it's a matter of spending a lot of time concentrating on federated security, and environmental upgrades. Working on pre-sales; sprucing up designs; sizing projects; and helping those around me get best use out of their IBM Tivoli/Security solutions.
So much has happened in recent months, though, that I hardly know where to start in documenting it all. There has been fun with SAML v2. Flirtations with FESI extension re-writes. Dalliances with web services and APIs. Encounters with business process re-engineering.
My next article, however, will likely be an IBM Tivoli Directory Integrator article centred on best practice for collaborative development. That sounds like a tricky one!
Showing posts with label Tivoli Access Manager. Show all posts
Showing posts with label Tivoli Access Manager. Show all posts
Tuesday, April 16, 2013
Wednesday, October 10, 2012
Internet Explorer Is A Very Naughty Boy
It has been three months since I last felt the urge to post anything on my blog. There isn't any real particular reason why there should've been a hiatus with the possible exception that the sun was shining (sometimes) and I was out and about rather than being tied to my desk.
But the days are shorter than the nights now. There is definitely a nip in the air. Being "out and about" isn't quite as enjoyable as it was just a few weeks ago.
And so here I am... ready and willing to commit some more of my findings to this blog.
So what shall I tell you? Well, what about the fact that Internet Explorer is a very naughty boy! Hardly a startling revelation. Those of us working in the web world already understand how often we come across situations whereby Firefox, Chrome, Safari and Opera can all render a page correctly, but Internet Explorer seems to fail to do so! It gets rather tedious after while, right?
This week, I had the joys of diagnosing why a page protected by WebSEAL wouldn't render in Internet Explorer. Capturing the HTTP Headers whizzing back and forth in Internet Explorer and Firefox provided the answer quite quickly: Internet Explorer would sometimes not bother to send the session cookie back to WebSEAL.
Why would it "sometimes" just not bother to do this? Well, there is some well documented evidence that Internet Explorer (up to version 8) treats cookies in a rather unexpected fashion. Internet Explorer can start dropping in-memory cookies as it has a finite limit on the number of in-memory cookies it can handle!
Those clever people in the development labs of IBM, however, have come across this before and the problem can be alleviated by setting the resend-webseal-cookies parameter to yes in the WebSEAL configuration file. This ensures that the cookie gets set with every request!
For many of you, you will have come across this quirk before. Many times, potentially. For those just getting started out with your WebSEAL deployment, though, make sure you have the ability to take a grab of the HTTP Headers from within your browser. It's amazing what you can see inside them!
Useful Header Inspection Tools
I promise to blog more... now that that winter is almost upon us!
But the days are shorter than the nights now. There is definitely a nip in the air. Being "out and about" isn't quite as enjoyable as it was just a few weeks ago.
And so here I am... ready and willing to commit some more of my findings to this blog.
So what shall I tell you? Well, what about the fact that Internet Explorer is a very naughty boy! Hardly a startling revelation. Those of us working in the web world already understand how often we come across situations whereby Firefox, Chrome, Safari and Opera can all render a page correctly, but Internet Explorer seems to fail to do so! It gets rather tedious after while, right?
This week, I had the joys of diagnosing why a page protected by WebSEAL wouldn't render in Internet Explorer. Capturing the HTTP Headers whizzing back and forth in Internet Explorer and Firefox provided the answer quite quickly: Internet Explorer would sometimes not bother to send the session cookie back to WebSEAL.
Why would it "sometimes" just not bother to do this? Well, there is some well documented evidence that Internet Explorer (up to version 8) treats cookies in a rather unexpected fashion. Internet Explorer can start dropping in-memory cookies as it has a finite limit on the number of in-memory cookies it can handle!
Those clever people in the development labs of IBM, however, have come across this before and the problem can be alleviated by setting the resend-webseal-cookies parameter to yes in the WebSEAL configuration file. This ensures that the cookie gets set with every request!
For many of you, you will have come across this quirk before. Many times, potentially. For those just getting started out with your WebSEAL deployment, though, make sure you have the ability to take a grab of the HTTP Headers from within your browser. It's amazing what you can see inside them!
Useful Header Inspection Tools
- ieHTTPHeaders for Internet Explorer, by Jonas Blunck
- Live HTTP Headers for Firefox, by Daniel Savard & Nikolas Coukouma
- Fiddler2, by Telerik
I promise to blog more... now that that winter is almost upon us!
Monday, November 14, 2011
WebSEAL and WebSphere Portal - An Integration Pattern
Thanks to Niall, I've been encouraged to provide my thoughts on how Single Sign On from WebSEAL to WebSphere Portal can be achieved.
In reality, the integration pattern is one of the simpler patterns to adopt. I say simple, but as Niall alluded to when asking me to provide my thoughts on the issue he quite rightly stated that there are at least two approaches to the problem - the LTPA approach and the TAI approach.
Which way is the right way? It's rather like asking why do some airplanes have wings over the fuselage and others have wings under. Surely one of them is better than the other and I really don't want to find myself in a plane that has its wings in a sub-optimal position, right? (Thanks to Mr. Gunning for the analogy!)
To re-use a well-worn phrase... it's more a matter of "horses for courses"... but here is my view.
WebSphere Portal cries out for its own WebSphere instance. I wouldn't host other applications alongside Portal. Not, mind you, because you can't! But because future upgrades paths may make it more prudent to ensure that off-the-shelf applications are isolated from one another.
Given this isolation, the decision as to whether you adopt LTPA or TAI becomes a lot more simplified. Here, the path of least resistance would suggest that LTPA is the way forward. It is a well-trodden path that is well documented and requires virtually no effort on the part of the system administrators.
To give an example, a recent engagement with a client on a separate issue was enlightened when they declared an interest in SSO to their Portal. "Have you got a test environment with TAM and Portal in it?" was met with a "Yes". "Walk this way my dear friends!"
In just under 10 minutes, SSO from WebSEAL to Portal had been achieved. Jaws thumped tables! The approach? LTPA.
So, the approach:
Firstly, ensure that the Realm Name in the Federated Repositories section of the WebSphere Application Server console uses the same value as the LDAP name (including port number).
Step 1: Generate the LTPA key on the Application Server. Navigate to Security/Secure Administration/Applications & Infrastructure/Authentication Mechanisms & Expiration/Cross Cell Single Sign On!
Step 2: Enable "Use Available Authentication Data When An Unprotected URI Is Accessed" after navigating to Security/Secure Administration/Applications & Infrastructure/Web Security/General Settings. (Copy the resulting file as you need it on the WebSEAL server!)
Step 3: Copy the file generated in Step 2 to the WebSEAL server and generate some WebSEAL junctions:
The command for generating the junctions should include the following directives:
Gotchas
When integrating WebSEAL and IBM Portal, it is necessary to understand the implications of the individual session caches that each component uses.
Portal, by default, has a 30-minute idle time-out and 2-hour session time-out on its user sessions. These values must be changed to accommodate the session times configured for WebSEAL (in that they should be slightly longer than the WebSEAL session). This recommendation helps to ensure that a consistent user experience is provided for a user. If a back-end HTTP application timed-out session data before the WebSEAL session for example, the user might experience errors from the back-end application.
In addition, a timeout.resume.session parameter can be added to automatically resume a session.
Login to the WebSphere admin console Select Resources -> Resources Environment providers -> WP ConfigService -> Custom properties. Add a new parameter as "timeout.resume.session" with value "true" as type "Boolean". Restart WebSphere Application Server.
Determine how you want the system to behave when users log out of portal. By default, when users click the Log out button in the SSO environment, they are not fully logged out of portal. Similarly, clicking the Log out button in the Portal environment does not mean that their SSO session has ended.
To accommodate a clean logout of Portal followed by a clean logout from the SSO environment, the IBM HTTP Server can be configured to perform a redirect to the WebSEAL logout page after the Portal Logout function has been requested. To achieve this, you need to edit the IBM HTTP Server configuration file to implement the post-log out behaviour. The IBM HTTP Server configuration file is called httpd.conf.
To capture requests to /ibm_security_logout and redirect them to /pkmslogout, add the following rewrite rules to the httpd.conf file:
RewriteEngine On
RewriteCond %{REQUEST_URI} /(.*)/ibm_security_logout(.*)
RewriteRule ^/(.*) /pkmslogout [noescape,L,R]
Note: You must add these rules to both the HTTP and HTTPS entries.
Ensure that the line that enables mod_rewrite is not commented out by removing the preceding # symbol. For example:
After all of that, you should have a perfectly operational WebSEAL/Portal integration.
In reality, the integration pattern is one of the simpler patterns to adopt. I say simple, but as Niall alluded to when asking me to provide my thoughts on the issue he quite rightly stated that there are at least two approaches to the problem - the LTPA approach and the TAI approach.
Which way is the right way? It's rather like asking why do some airplanes have wings over the fuselage and others have wings under. Surely one of them is better than the other and I really don't want to find myself in a plane that has its wings in a sub-optimal position, right? (Thanks to Mr. Gunning for the analogy!)
To re-use a well-worn phrase... it's more a matter of "horses for courses"... but here is my view.
WebSphere Portal cries out for its own WebSphere instance. I wouldn't host other applications alongside Portal. Not, mind you, because you can't! But because future upgrades paths may make it more prudent to ensure that off-the-shelf applications are isolated from one another.
Given this isolation, the decision as to whether you adopt LTPA or TAI becomes a lot more simplified. Here, the path of least resistance would suggest that LTPA is the way forward. It is a well-trodden path that is well documented and requires virtually no effort on the part of the system administrators.
To give an example, a recent engagement with a client on a separate issue was enlightened when they declared an interest in SSO to their Portal. "Have you got a test environment with TAM and Portal in it?" was met with a "Yes". "Walk this way my dear friends!"
In just under 10 minutes, SSO from WebSEAL to Portal had been achieved. Jaws thumped tables! The approach? LTPA.
So, the approach:
Firstly, ensure that the Realm Name in the Federated Repositories section of the WebSphere Application Server console uses the same value as the LDAP name (including port number).
Step 1: Generate the LTPA key on the Application Server. Navigate to Security/Secure Administration/Applications & Infrastructure/Authentication Mechanisms & Expiration/Cross Cell Single Sign On!
Step 2: Enable "Use Available Authentication Data When An Unprotected URI Is Accessed" after navigating to Security/Secure Administration/Applications & Infrastructure/Web Security/General Settings. (Copy the resulting file as you need it on the WebSEAL server!)
Step 3: Copy the file generated in Step 2 to the WebSEAL server and generate some WebSEAL junctions:
/wps
/searchfeed
/ibmjsfres
/wps_semanticTag
The command for generating the junctions should include the following directives:
-A -2 -F (file generated above) -Z (password used in Step 2)
-x
-j
Gotchas
When integrating WebSEAL and IBM Portal, it is necessary to understand the implications of the individual session caches that each component uses.
Portal, by default, has a 30-minute idle time-out and 2-hour session time-out on its user sessions. These values must be changed to accommodate the session times configured for WebSEAL (in that they should be slightly longer than the WebSEAL session). This recommendation helps to ensure that a consistent user experience is provided for a user. If a back-end HTTP application timed-out session data before the WebSEAL session for example, the user might experience errors from the back-end application.
In addition, a timeout.resume.session parameter can be added to automatically resume a session.
Login to the WebSphere admin console Select Resources -> Resources Environment providers -> WP ConfigService -> Custom properties. Add a new parameter as "timeout.resume.session" with value "true" as type "Boolean". Restart WebSphere Application Server.
Determine how you want the system to behave when users log out of portal. By default, when users click the Log out button in the SSO environment, they are not fully logged out of portal. Similarly, clicking the Log out button in the Portal environment does not mean that their SSO session has ended.
To accommodate a clean logout of Portal followed by a clean logout from the SSO environment, the IBM HTTP Server can be configured to perform a redirect to the WebSEAL logout page after the Portal Logout function has been requested. To achieve this, you need to edit the IBM HTTP Server configuration file to implement the post-log out behaviour. The IBM HTTP Server configuration file is called httpd.conf.
To capture requests to /ibm_security_logout and redirect them to /pkmslogout, add the following rewrite rules to the httpd.conf file:
RewriteEngine On
RewriteCond %{REQUEST_URI} /(.*)/ibm_security_logout(.*)
RewriteRule ^/(.*) /pkmslogout [noescape,L,R]
Note: You must add these rules to both the HTTP and HTTPS entries.
Ensure that the line that enables mod_rewrite is not commented out by removing the preceding # symbol. For example:
LoadModule rewrite_module modules/mod_rewrite.so
After all of that, you should have a perfectly operational WebSEAL/Portal integration.
Thursday, June 30, 2011
WebSEAL Virtual Host
Tivoli Access Manager for e-business' WebSEAL supports the concept of virtual hosting but the documentation surrounding the setup of virtual hosting can sometimes be a little unclear. The diagrams available on Infocenter only help to muddy the waters from what I can tell.
Yet it doesn't have to be so. The concept is actually very simple indeed and can be encapsulated quite easily within a single diagram.
So without over-using words... here's a pretty picture:
All explained I hope? Of course it is!
Yet it doesn't have to be so. The concept is actually very simple indeed and can be encapsulated quite easily within a single diagram.
So without over-using words... here's a pretty picture:
All explained I hope? Of course it is!
Tuesday, March 29, 2011
TAMeb Naughty Installer - SMS Part 2
Previously, I described the pain and heartache that is the Tivoli Access Manager for e-business SMS Server installer routine when another administrator has installed the WebSphere component [see http://blog.stephen-swann.co.uk/2011/03/tameb-naughty-installer-sms-part-1.html].
The title of that blog post claimed that it was merely Part 1 of the saga. Here's part 2.
It's not unusual for customers to want to install software somewhere other than the suggested location. In a Windows environment, it seems quite normal for the base operating system to occupy the C: drive and for additional components to be deployed on the D: drive. When an installer gives you the option to change the destination for your application, it's reasonable to assume that it is safe to do so.
With the TAMeb SMS installer, however, this assumption would be incorrect. While the PDSMS package can be deployed on to the D: drive, running the smscfg utility to configure the SMS product will fail claiming that c:\Program Files\Tivoli\PDSMS cannot be found on the system!
The simple way to resolve this issue is as you would expect. Temporarily copy the contents of your PDSMS directory from wherever you deployed it to the location above and smscfg will get you further. In fact, you should now be in a state where you can successfully deploy and configure the SMS Server and associated components.
For a comprehensive set of instructions on how to do that, follow the guide at IBM Tivoli Access Manager Session Management Server Deployment Architectures.
The title of that blog post claimed that it was merely Part 1 of the saga. Here's part 2.
It's not unusual for customers to want to install software somewhere other than the suggested location. In a Windows environment, it seems quite normal for the base operating system to occupy the C: drive and for additional components to be deployed on the D: drive. When an installer gives you the option to change the destination for your application, it's reasonable to assume that it is safe to do so.
With the TAMeb SMS installer, however, this assumption would be incorrect. While the PDSMS package can be deployed on to the D: drive, running the smscfg utility to configure the SMS product will fail claiming that c:\Program Files\Tivoli\PDSMS cannot be found on the system!
The simple way to resolve this issue is as you would expect. Temporarily copy the contents of your PDSMS directory from wherever you deployed it to the location above and smscfg will get you further. In fact, you should now be in a state where you can successfully deploy and configure the SMS Server and associated components.
For a comprehensive set of instructions on how to do that, follow the guide at IBM Tivoli Access Manager Session Management Server Deployment Architectures.
Sunday, March 27, 2011
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:
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!
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!
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:
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.
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.
Friday, October 08, 2010
Securing Lotus Connections With WebSEAL
There are a few documents on the web that try to explain how to integrate Lotus Connections with WebSEAL and they do actually work to a certain extent. However, there are holes in their explanations that prevent the full rich experience of a Lotus Connections environment when fronted with a WebSEAL.
Here's how to "plug" those holes for a Lotus Connections v2.5 and Tivoli Access Manager v6.1 infrastructure.
Firstly... I should point out that the integration guide written by En Hui Chen is excellent and was used as the basis for this guide. His guide can be found at http://www-10.lotus.com/ldd/lcwiki.nsf/page.xsp?documentId=65A226C20BEC2302852576B100410A04&action=openDocument
Lotus Connections Data Flow
To understand why WebSEAL and Connections should be configured the way they are, it is important to understand how the components communicate with and through each other. Fundamentally, a user's experience with Connections is not constrained to the HTTP traffic bouncing between a browser and (ultimately) the Connections applications. Instead, we need to be mindful of Ajax components being rather chatty with the back end as well as inter-service communications across Connections applications. When we introduce WebSEAL, we need to ensure that the traffic is being routed appropriately as such:
The Holes
Hole 1
The connectionsAdmin account must be an account known to TAM. The following pdadmin commands should therefore be called to ensure that the account is imported correctly and valid:
pdadmin> user import connectionsAdmin {connectionsAdmin dn}
pdadmin> user modify connectionsAdmin account-valid yes
Hole 2
This might not necessarily be called a hole, but rather an amalgamation of information on the Lotus Wiki and the information on the IBM Infocenter sites. However, the following objects required the Connections ACL to be applied to them:
Hole 3
This probably isn't a hole either, to be honest. Instead, it's best to see it as a re-iteration or re-clarification.
The LotusConnections-config.xml file should be updated to contain the following:
Also, ensure that the static href, static ssl_href and interService URLs for all services are pointing at the WebSEAL cluster:
Note, the fully-qualified-host-name MUST be set to the host name where the WebSEAL is to be found.
Hole 4
Lotus Connections applications will attempt to open server to server communications with other Lotus Connections applications via Tivoli Access Manager. If forms-auth has been set to https in the webseald-.conf file, then the signer certificate for WebSEAL client-side SSL communications should be added to the WebSphere trust stores. In addition, the LotusConnections-config.xml file should be updated to contain the following:
Following En Hui Chen's guide and applying the "plugs" above should get you a perfectly working TAM-Lotus Connections environment. If not, drop me a line... I may be able to help. Failing that, have a chat with @dilftechnical who provided some invaluable Lotus Connections insight while diagnosing the issues we faced during integration.
Here's how to "plug" those holes for a Lotus Connections v2.5 and Tivoli Access Manager v6.1 infrastructure.
Firstly... I should point out that the integration guide written by En Hui Chen is excellent and was used as the basis for this guide. His guide can be found at http://www-10.lotus.com/ldd/lcwiki.nsf/page.xsp?documentId=65A226C20BEC2302852576B100410A04&action=openDocument
Lotus Connections Data Flow
To understand why WebSEAL and Connections should be configured the way they are, it is important to understand how the components communicate with and through each other. Fundamentally, a user's experience with Connections is not constrained to the HTTP traffic bouncing between a browser and (ultimately) the Connections applications. Instead, we need to be mindful of Ajax components being rather chatty with the back end as well as inter-service communications across Connections applications. When we introduce WebSEAL, we need to ensure that the traffic is being routed appropriately as such:
The Holes
Hole 1
The connectionsAdmin account must be an account known to TAM. The following pdadmin commands should therefore be called to ensure that the account is imported correctly and valid:
pdadmin> user import connectionsAdmin {connectionsAdmin dn}
pdadmin> user modify
Hole 2
This might not necessarily be called a hole, but rather an amalgamation of information on the Lotus Wiki and the information on the IBM Infocenter sites. However, the following objects required the Connections ACL to be applied to them:
acl attach /WebSEAL/{webseal}/profiles/dsx {connections_acl}
acl attach /WebSEAL/{webseal}/communities/dsx {connections_acl}
acl attach /WebSEAL/{webseal}/blogs/blogsapi {connections_acl}
acl attach /WebSEAL/{webseal}/blogs/blogsfeed {connections_acl}
acl attach /WebSEAL/{webseal}/files/basic/anonymous/atom {connections_acl}
acl attach /WebSEAL/{webseal}/files/form/anonymous/atom {connections_acl}
acl attach /WebSEAL/{webseal}/files/wl {connections_acl}
acl attach /WebSEAL/{webseal}/activities/images {connections_acl}
acl attach /WebSEAL/{webseal}/communities/dsx {connections_acl}
acl attach /WebSEAL/{webseal}/blogs/blogsapi {connections_acl}
acl attach /WebSEAL/{webseal}/blogs/blogsfeed {connections_acl}
acl attach /WebSEAL/{webseal}/files/basic/anonymous/atom {connections_acl}
acl attach /WebSEAL/{webseal}/files/form/anonymous/atom {connections_acl}
acl attach /WebSEAL/{webseal}/files/wl {connections_acl}
acl attach /WebSEAL/{webseal}/activities/images {connections_acl}
Hole 3
This probably isn't a hole either, to be honest. Instead, it's best to see it as a re-iteration or re-clarification.
The LotusConnections-config.xml file should be updated to contain the following:
<dynamichosts enabled="true">
<host href="http://fully-qualified-host-name" ssl_href="https://fully-qualified-host-name">
</dynamichosts>
Also, ensure that the static href, static ssl_href and interService URLs for all services are pointing at the WebSEAL cluster:
<sloc:static href="http://fully-qualified-host-name" ssl_href="https://fully-qualified-host-name" />
<sloc:interservice href="https://fully-qualified-host-name" />Note, the fully-qualified-host-name MUST be set to the host name where the WebSEAL is to be found.
Hole 4
Lotus Connections applications will attempt to open server to server communications with other Lotus Connections applications via Tivoli Access Manager. If forms-auth has been set to https in the webseald-
<forceconfidentialcommunications enabled="true"></forceconfidentialcommunications>
Following En Hui Chen's guide and applying the "plugs" above should get you a perfectly working TAM-Lotus Connections environment. If not, drop me a line... I may be able to help. Failing that, have a chat with @dilftechnical who provided some invaluable Lotus Connections insight while diagnosing the issues we faced during integration.
Tuesday, October 05, 2010
WebSEAL Javascript Toolkit
Every good systems integrator needs to have ready access to their essential toolkits. You know the ones I mean? Those little snippets of code that absolutely, must be dropped into every deployment you ever complete.
In the WebSEAL world, I find that the following get my vote over and over again.
Frame Busting
Isn't it horrible when a WebSEAL login form appears in a frame? Aren't frames horrible in the first place? Anyway, I like the brutal approach in destroying those frames by dropping this piece of code into the login page:
And, if you want to swap from http to https?
The Cookie Crumbler
This is another favourite of mine. Upon logout, let's be brutal in trashing all cookies for the domain. Of course, the key word here is brutal. You may not want to do this. In fact, there are any number of reasons why this might be an incredibly bad idea for your environment. But if this is the case, then the code can be tailored to leave those "special" cookies intact. The rest? Crumble away.
Cache Handling
Amazingly, the vanilla/default pages for login and logout pages will get cached by browsers which can cause confusion to users. Am I authenticated? Am I not? Maybe it would be best to instruct the browser to not cache these pages (and probably others). So we can drop the following meta-tags into our pages:
Why so many statements? Well, as we all know, not all browsers behave in accordance with agreed standards. Enough said?
Conclusion
This isn't an exhaustive list of must-do tasks for a vanilla WebSEAL installation and it certainly isn't even accurate for all installations. But they are certainly a good starting point for putting good navigational structure around your WebSEAL protected environment.
In the WebSEAL world, I find that the following get my vote over and over again.
Frame Busting
Isn't it horrible when a WebSEAL login form appears in a frame? Aren't frames horrible in the first place? Anyway, I like the brutal approach in destroying those frames by dropping this piece of code into the login page:
if (self.location != top.location) {
top.location = self.location;
}
And, if you want to swap from http to https?
if (window.location.href.indexOf("https") == -1) {
var uri = window.location.href.substring(4);
window.location = "https" + uri;
}
The Cookie Crumbler
This is another favourite of mine. Upon logout, let's be brutal in trashing all cookies for the domain. Of course, the key word here is brutal. You may not want to do this. In fact, there are any number of reasons why this might be an incredibly bad idea for your environment. But if this is the case, then the code can be tailored to leave those "special" cookies intact. The rest? Crumble away.
var warningString = "WARNING: To maintain your login session, make sure that your browser is configured to accept Cookies.";
document.cookie = 'acceptsCookies=yes';
if(document.cookie == '') {
document.write(warningString);
} else {
// Cookie Crumbler
var strSeparator1 = " ";
var strSeparator2 = "=";
var strCookie = document.cookie;
var strCookieName = null;
var intCount;
var intStart = 0;
var intEnd = 0;
for (intCount = 1; intCount < strCookie.length; intCount++) {
if (strCookie.charAt(intCount) == strSeparator2) {
intEnd = intCount;
strCookieName = strCookie.substring(intStart, intEnd);
document.cookie = strCookieName + "=yes; expire=Fri, 13-Apr-1970 00:00:00 GMT";
strCookieName = null;
}
if (strCookie.charAt(intCount) == strSeparator1) {
intStart = intCount + 1;
}
}
}
Cache Handling
Amazingly, the vanilla/default pages for login and logout pages will get cached by browsers which can cause confusion to users. Am I authenticated? Am I not? Maybe it would be best to instruct the browser to not cache these pages (and probably others). So we can drop the following meta-tags into our pages:
content="No-Cache" http-equiv="Pragma"
content="No-Store" http-equiv="Cache-Control"
content="No-Cache" http-equiv="Cache-Control"
http-equiv="Cache-Control", "private"
content="0" http-equiv="Expires"
Why so many statements? Well, as we all know, not all browsers behave in accordance with agreed standards. Enough said?
Conclusion
This isn't an exhaustive list of must-do tasks for a vanilla WebSEAL installation and it certainly isn't even accurate for all installations. But they are certainly a good starting point for putting good navigational structure around your WebSEAL protected environment.
Monday, July 05, 2010
How To Provision TAM GSO Credentials
Most of the time, getting IBM Tivoli Identity Manager to provision accounts successfully in target systems is a breeze. And you could be forgiven for thinking that provisioning to IBM Tivoli Access Manager (another stalwart of the IBM Tivoli portfolio) would be the simplest of the lot.
You would, of course, be wrong. At least, if you want to make use of GSO credentials, you would be wrong. Maybe. Possibly.
You see, the provisioning of GSO credentials just doesn't seem to be that easy!
This article assumes the following:
For an explanation of the problem, let us assume that a resource has been created within the TAM domain called backed. In pdadmin, we can create this resource as such:
In ITIM, we have a provisioning policy created with all the standard default TAM attributes being populated (such as cn, sn, our TAM groups, etc.). We check the box for Single Sign On Capability which leaves us with the Resource Credentials to populate.
In our environment, we have password synchronisation enabled across all systems and the GSO credentials will be no different. In other words, should a user change their password in ITIM, their TAM password and their GSO resource credential passwords will also be updated.
The "Constant Value" option for the Resource Credentials on our Provisioning Policy form is of no help for a User ID and Password that will be different for each user:
Which leaves us with the option of scripting the credentials. The documentation provided with the TAM Combo Adapter at least tells us that the TAM Resource Credentials must be provided in the following format:
In our case, that means that our javascript will look something like this:
We have a problem. We've always known that we can use parameters.eruid[0] for our User ID but what do we use for our password? A little bit of crawling around the documentation tells us that when password synchronisation is enabled, the ersynchpassword can be used to retrieve the password. So our {something} becomes ersynchpassword, right?
Wrong!
In fact, when we do this and provision an account (with a password of auiTNG85) our secAuthData attribute in LDAP contains the following:
How do I know that this is wrong? I know because I manually created the Resource Credential via the pdadmin command prompt and know that the result I'm looking for is:
Indeed, if I hardcode my Provisioning Policy to set {something} to my password (auiTNG85), I get the same incorrect result. Odd? Not really. If you dig further into the documentation you will see that there is some funny business going on with the TAM Combo Adapter and the password in the Resource Credential attribute on the Provisioning Policy MUST be prefixed with {clear}. In our hardcoded entitlement, we would therefore have:
Now, when we create our account, the secAuthnData is set correctly! Of course, I'm hardcoding the password still so I need to do something about that! We need to re-introduce our ersynchpassword attribute but ensure we are prefixing is with {clear}. And the reason we do that is because ITIM is just too clever by half and has already Base64 Decoded the attribute on our behalf!
The resulting secAuthnData is now set to:
Perfection. I'm sure the documentation contains all the information required to get this result but it isn't instantly clear that this is how you should be going about the GSO Credential Password Synchronisation problem.
You would, of course, be wrong. At least, if you want to make use of GSO credentials, you would be wrong. Maybe. Possibly.
You see, the provisioning of GSO credentials just doesn't seem to be that easy!
This article assumes the following:
- the reader has a basic understanding of IBM Tivoli Identity Manager
- the reader has a basic understanding of IBM Tivoli Access Manager
- the reader understands GSO credentials within TAM
- the version of ITIM being used is v5.0 (or higher)
- the version of TAM being used is v6.0 (or higher)
- the TAM Combo Adapter is being used (v5.0.9)
For an explanation of the problem, let us assume that a resource has been created within the TAM domain called backed. In pdadmin, we can create this resource as such:
rsrc create backend
In ITIM, we have a provisioning policy created with all the standard default TAM attributes being populated (such as cn, sn, our TAM groups, etc.). We check the box for Single Sign On Capability which leaves us with the Resource Credentials to populate.
In our environment, we have password synchronisation enabled across all systems and the GSO credentials will be no different. In other words, should a user change their password in ITIM, their TAM password and their GSO resource credential passwords will also be updated.
The "Constant Value" option for the Resource Credentials on our Provisioning Policy form is of no help for a User ID and Password that will be different for each user:
Which leaves us with the option of scripting the credentials. The documentation provided with the TAM Combo Adapter at least tells us that the TAM Resource Credentials must be provided in the following format:
RESOURCE NAME|USER ID|PASSWORD
In our case, that means that our javascript will look something like this:
"backend (Web Resource)" + "|" + parameters.eruid[0] + "|" + {something}
We have a problem. We've always known that we can use parameters.eruid[0] for our User ID but what do we use for our password? A little bit of crawling around the documentation tells us that when password synchronisation is enabled, the ersynchpassword can be used to retrieve the password. So our {something} becomes ersynchpassword, right?
Wrong!
In fact, when we do this and provision an account (with a password of auiTNG85) our secAuthData attribute in LDAP contains the following:
secAuthnData:: IUAja0BAQEBAQEDJKioqKioqKqgh5CMjIyMjIyMjIyMjgiMjIyMjIyMjIyMjniMjIyMjIyMjIyMjNyQk
How do I know that this is wrong? I know because I manually created the Resource Credential via the pdadmin command prompt and know that the result I'm looking for is:
secAuthnData:: IUAjZyoqKioqKip6JiYmJiYmJiYmJiZpIVQhT0BAQEBAQEBIQEBAQEBAQDghOSUlJSUlJSUlJSUlJSUA
Indeed, if I hardcode my Provisioning Policy to set {something} to my password (auiTNG85), I get the same incorrect result. Odd? Not really. If you dig further into the documentation you will see that there is some funny business going on with the TAM Combo Adapter and the password in the Resource Credential attribute on the Provisioning Policy MUST be prefixed with {clear}. In our hardcoded entitlement, we would therefore have:
"backend (Web Resource)" + "|" + parameters.eruid[0] + "|" + "{clear}auiTNG85"
Now, when we create our account, the secAuthnData is set correctly! Of course, I'm hardcoding the password still so I need to do something about that! We need to re-introduce our ersynchpassword attribute but ensure we are prefixing is with {clear}. And the reason we do that is because ITIM is just too clever by half and has already Base64 Decoded the attribute on our behalf!
The resulting secAuthnData is now set to:
secAuthnData:: IUAjZyoqKioqKip6JiYmJiYmJiYmJiZpIVQhT0BAQEBAQEBIQEBAQEBAQDghOSUlJSUlJSUlJSUlJSUA
Perfection. I'm sure the documentation contains all the information required to get this result but it isn't instantly clear that this is how you should be going about the GSO Credential Password Synchronisation problem.
Subscribe to:
Posts (Atom)