Wednesday, December 20, 2006

TAMeB 1st Timer

I'm now in the process of building TAMeB in my sandbox environment. I'm starting out basic with just a TAM Policy Server, Authorization Server, and WebSeal. I'll install these on 3 separate VMs. My TDS Servers are already built and clustered at my dc=MyOrg container. The only thing I'm not sure about is where I should install the Web Portal Manager for TAM. I guess I could just install it on the Policy server for now, but I'm not sure if in production this should be on it's own box or if I can simply install it on some existing WAS server or not. I've already got WAS running on the TIM server as well. Seems like WAS is quickly proliferating around my test environment.

I ran into an error at the end of installing the TAM Policy server. The installation completed with errors and when I reviewed the msg__ammgr_install.log I found very little telling why. This is really all I could see in the log:

(Dec 19, 2006 7:44:26 AM), Setup.product.install, com.tivoli.pd.install.ez.EZ_IsProductConfiguredCondition, dbg, EZ_IsProductConfiguredCondition.evaluateTrueCondition found .configure//opt/PolicyDirector/.configure/PDMgr-PD : false

I then began playing around with the pdconfig tool. This is a really nice tool which quickly allows you to unconfigure and reconfigure your policy server. What I found was when I tried to reconfigure the policy server this tool generated errors that were much more informative than the log. Essentially I was getting LDAP errors that indicated an object wasn't found or a suffix was not found or something to that effect. Whatever it was it led me to a developerworks posting that seemed similar. The fix was to to manually add the suffix secAuthority=Default in my TDS server. Once I took care of that the configuration of the Policy server completed successfully and it started up fine as well. Not sure why I had to add that suffix manually. I'm running TDS 6.0.

The authorization server was my next step and sure enough by the time I completed that installation, I had new errors to deal with. More on that later.

Saturday, December 16, 2006

For a good deep mental exercise...

How does an organization begin to implement role based access control (RBAC)? If your entire enterprise is based on discretionary access control and an implementation of Identity Management begins to take shape you must at some point deal with how to define roles. Apparently this is no simple matter. I ran across a good blog posting on Archie Reeds Secure Identity Management blog here. Archie talks about a panel discussion at Digital ID World this past September. Very interesting. For those looking to implement RBAC (which would likely be anyone doing an Identity Management project) the NIST site might be a place to start:

I'll be looking for all the resources I can get on RBAC over the coming months. It seems that this could be quite a science.

Tuesday, December 12, 2006

High Level Architecture TIM/TAM

This drawing shows how TIM and TAM are connected. Basically the feeds from the HR zone send the identities to ITIM. From there ITIM connects to applications as well as TAM via adapters to create accounts according to policy. The transaction database connected to the TIM (WebSphere App) is where all the audit tracking info is stored (who has access to what and who approved that access). The TIM LDAP is actually a TDS server(s) with all sorts of special objectclasses and attributes used by TIM. This should not be used as your enterprise LDAP and should be dedicated to ITIM. TAM is actually a managed resource as far as TIM is concerned so an adapter is used to connect TIM and TAM.

High Level TAM Architecture

As we have been gathering information about our applications and trying to flush out special attributes and group information that these applications require we are starting to develop our high level TAM architecture. If you click the Read More you will see what we have come up with so far. At least this is what we are trying to achieve with the access management system. As we continue on through the discovery process we will alter the drawing as need be. Using this as a guide really helps when trying to explain to application support people what it is we are trying to do.

Although not having a full understanding of TAMs capabilities is tough. I'll be learning more in the days and weeks ahead. I'm beginning to get more interested in more "down in the weeds" stuff like what does it really take for an application to be "TAM enabled". How exactly does the Access Control info get passed to the application and such. More on that later...

High Level Architecture:

Saturday, December 9, 2006

Made a new friend this week

One of the things I like about working with IBM software is you get to meet some really smart and talented people along the way. This first phase of our Identity and Access Management project is the architecture phase. Since we've never done anything like this before we commissioned Strategic Computer Solutions (SCS) to help guide our way to implementation. They in turn brought someone out from the Tivoli Software Group for the project and this guy really knows his stuff!

Ram Sreerangam pronounced "Rom Shri-rung-gum" flew into Buffalo from Boulder this past week to give us a hand architecting the ITIM and ITAM solution. Even though we've only just begun, it feels like we've made great progress already after talking to a number of application people and network people. At this stage of the game we're just getting the "lay of the land" really. So it sounds like we may have some capacity on our load balancing switches to help with clustering although we may still choose to purchase a separate device depending on how many ports we need and where in the network we need to locate the device. We were able to temper our expectations down to a smaller number of applications to start with as well which is really important for making the project manageable. When you protect an application with TAM it's important to remember that all users who use that application will be affected so trying to pilot this sort of thing with only a few users will require choosing an application that is only used by a few people. At first our thinking was we could get a whole bunch of applications and test with only a few people, but instead we must choose a few applications to start with and then add more applications as we go.

It looks like we will have to implement ITIM and ITAM together. Here's why:

Our production Portal is already using an existing LDAP (running Domino). There's about 30,000 users in that LDAP, but we intend to use TDS as the enterprise LDAP which will also be the TAM user store. Right now, all the users in the Domino LDAP use their Notes Internet Password for authentication into Portal. In the new enterprise directory we may not be storing this password (although maybe we will just to get people started). The main issue is that users will not have a way to administer their passwords without ITIM.

During some of our discussions with application people, we discovered that some of our applications are used by people outside of our usual security domain. Where it was thought that all the users of these applications were from our customers within our regional boundaries (and therefore our network) some applications are used by people outside of our normal boundaries (Internet). So these are candidates for Federation (FIM). We really did not want to deal with a FIM deployment at this time because it involves issues like the asserting party also having a federation product that we could work with. This really gets out of the scope of this project so we will either place those applications lower on the priority list for securing behind TAM and TIM or we may have to decide on a process for storing those Identities from the outside customers in our Enterprise Directory (TAM user store) which means we will have to maintain them.

Next week, Ram will be doing some documentation from Boulder and then he goes on vacation for 2 weeks. When he returns in January I hope to have already setup TAM in a test environment and hopefully documented some more applications for our data modeling effort.

It's also getting close to the time we will need to attend some classroom training for this stuff. Ram helped develop some of the IBM courses and he says the Labs are fantastic. I look forward to checking that out. For your reference:

Recommended roadmap for ITIM v4.6:

Classroom Training: Extending IBM Tivoli Identity Manager 4.6

Recommended roadmap for ITAM v6.0:

Classroom Training: IBM Tivoli Access Manager for e-business 6.0 Deployment and Administration

Classroom Training (optional): IBM Tivoli Access Manager for e-business 6.0 Customization

Been a while...

I've been waist deep in this Identity Management project for the past couple weeks so I haven't posted in a while. So here's what's been happening on that front:

The hardest part about a project like this is the analysis of your applications and network so that you can do proper data modeling and architecture of the solution. We have many different applications scattered all over the WAN and somewhere around 300,000 potential users not including the people outside our network boundaries that might touch an application. While there are many factors leading to how the ITIM organization tree should be defined there are a couple of key questions:

Who will be administering the system? Will you delegate administration to lower levels in the tree? How deep might you do whith that?
Where will roles be defined? Some roles can apply to objects in the subtree where the role exists so depending on how you design the tree could make assigning roles either more or less flexible it seems.

Analyzing applications is enough to give anyone a headache by lunch time...

For the identity and access management system we need to understand a few things about each application:

Who are the users that access your application?
How do they request access to that application and who approves of that access?
Are there different levels of access to the application?
How does that application determine who is in what access level? Groups? Attributes about the user?
Are there any special attributes about a user that the application requires?

Once we start to flesh out and document this information we can beging to do the data modeling - list the attributes and objectclasses we may need to include in the enterprise directory.

For the access management component we will also need to understand what type of application it is. .Net? Java? Mainframe? Is it known to work with Tivoli Access Manager? Is there a Tivoli Identity Manager adapter for it already or will we likely have to develop one? Does the application expose an api so that an adapter can be created for it.

Next week I plan to setup TAM in our sandbox environment so I'm sure to have something to say about how that goes.