If you have been reading this blog for a while you may have noticed that I have an interest in XACML and especially in using XACML in the healthcare sector.
If you have similar interests you may be want to take a look at a webinar that Axiomatics will be running on May 5 2011.
Thursday, April 21, 2011
Friday, March 25, 2011
CISSP
There are certain things in life that you plan to do for a very long time before you actually get around doing it. In my case CISSP is one of these things that I have thought about doing for more than five years but something has always interfered. In December I finally managed to attend a test and it went well so now I am a CISSP.
I actually didn't study very much for the test as the twins eats most of my spare time. I did take the time to read through Shon Harris All In One Exam Guide which I think helped quite a bit. Really good reading and actually worth taking a look at even if you are not going up for a CISSP.
The best piece of advice I got was to remember to bring some snacks and something to drink. The exam is six hours and you really need something to keep you from keeling over of exhaustion. It was many years since I have ever felt as totally knackered as I felt after the test.
I actually didn't study very much for the test as the twins eats most of my spare time. I did take the time to read through Shon Harris All In One Exam Guide which I think helped quite a bit. Really good reading and actually worth taking a look at even if you are not going up for a CISSP.
The best piece of advice I got was to remember to bring some snacks and something to drink. The exam is six hours and you really need something to keep you from keeling over of exhaustion. It was many years since I have ever felt as totally knackered as I felt after the test.
Monday, February 28, 2011
Monitoring
Most enterprise IDM systems are very complicated and complex beasts with redundancy in not only the presentation layer but in the application layer and the data persistence layer. This can make it hard to answer the simple question "Is the system working properly or not". In most cases you also want to be able to spot issues early so that you can fix them before they become a problem that may take down the entire system.
The best way to ensure that all components are healthy and all services are up is to implement a comprehensive monitoring program so what are the things that you tend to want monitor?
The most basic monitoring policy is the "wait until the end user yells" approach. In this approach you simply wait for the end user to start screaming and as long no one is screaming then things must be fine. This approach have some significant limitations so it is not the way I would recommend.
Once you start talking monitoring you usually discover that the corporation has some kind of standardized monitoring tool that you should/must use. These tools usually can provide the following functionality:
In most cases you will have some kind of network or port monitoring as part of your load balancer setup. Given that port oriented network monitoring configuration tends to get very complex I will write about this in a separate post.
Next step is to look at the application aware monitoring. This is usually accomplished by looking at the application logs and escalating entries that are following a certain pattern (i.e. whose log level is ERROR). You can also look for specific error messages that you know are thrown when a specific error condition occurs.
Once you have monitoring in place you should be able to sleep better at night. At least as long as your monitoring doesn't wake you up reporting nuisance errors.
The best way to ensure that all components are healthy and all services are up is to implement a comprehensive monitoring program so what are the things that you tend to want monitor?
The most basic monitoring policy is the "wait until the end user yells" approach. In this approach you simply wait for the end user to start screaming and as long no one is screaming then things must be fine. This approach have some significant limitations so it is not the way I would recommend.
Once you start talking monitoring you usually discover that the corporation has some kind of standardized monitoring tool that you should/must use. These tools usually can provide the following functionality:
- Host monitoring (is the server OS up)
- CPU/Memory/disk monitoring
- Process monitoring
In most cases you will have some kind of network or port monitoring as part of your load balancer setup. Given that port oriented network monitoring configuration tends to get very complex I will write about this in a separate post.
Next step is to look at the application aware monitoring. This is usually accomplished by looking at the application logs and escalating entries that are following a certain pattern (i.e. whose log level is ERROR). You can also look for specific error messages that you know are thrown when a specific error condition occurs.
Once you have monitoring in place you should be able to sleep better at night. At least as long as your monitoring doesn't wake you up reporting nuisance errors.
Wednesday, February 9, 2011
UAT and requirements gathering
In provisioning projects requirements gathering and UAT testing is always an interesting area. The general problem with UAT and system level testing is that in order for the testing to be useful you really need to know what result is the correct result and what is a failure.
When you write bespoke software you can usually find the answer to this question in the design which in turn is derived from the functional requirements which are derived from the business requirements. In a typical IAM implementation on the other hand you tend to use very feature rich platforms that provides huge amounts of functionality most of which you will never use in any given project. It is also often hard to shut down this "bonus functionality" so the functionality often is available even if it really shouldn't be used. Many times when you get to UAT the testers starts touching all kinds of buttons and levers and unless you have an experienced team that has spent substantial amount of time on actively locking things down you will have some issues with this.
Business process wise IAM implementations can fall on anywhere scale ranging from totally transformative to literal refactoring where the business process doesn't change at all. In the first case the challenge is that the UAT needs to reflect the new business process and you also need to ensure that the new business process actually supports all the functions that the business needs. In the second case things are easier because you basically just need to capture an already existing process.
No matter the strategic focus of the IAM project a proper UAT needs to be business process focused. The whole point of UAT is to ensure that all business critical processes are present and are working as expected or at least in a way that is acceptable. The irony is of course that if you discover substantial process breaks in the UAT you are usually in deep trouble as it usually is too late to fix things before the planned go live.
The best way to avoid this situation is to ensure that you do a form of dry run UAT very early in the process. In my experience one of the best ways to do this is to utilize simple Visio workflows. You start with the requirements, which usually are more or less useless, and create Visio workflows. You then show the workflows for the people that knows or should know the business process. These people can rarely tell you what is needed but they can usually tell you if you get it wrong or tell you things that you should take into considerations. After a couple of cycles you usually have a pretty good process and you have also gained the buy in from one of the stakeholders.
If your architect is experienced he or she can usually produce a pretty good set of flows that can act as a starting point. Most more sophisticated consultancy organizations will be able to provide a standard set of flows as well. If your implementation team starts coding without first establishing, vetting and communicating the business process it is time to start getting alarmed. The project may still deliver successfully but it will most likely have a very painful UAT or even worse a very painful go live in front of it.
When you write bespoke software you can usually find the answer to this question in the design which in turn is derived from the functional requirements which are derived from the business requirements. In a typical IAM implementation on the other hand you tend to use very feature rich platforms that provides huge amounts of functionality most of which you will never use in any given project. It is also often hard to shut down this "bonus functionality" so the functionality often is available even if it really shouldn't be used. Many times when you get to UAT the testers starts touching all kinds of buttons and levers and unless you have an experienced team that has spent substantial amount of time on actively locking things down you will have some issues with this.
Business process wise IAM implementations can fall on anywhere scale ranging from totally transformative to literal refactoring where the business process doesn't change at all. In the first case the challenge is that the UAT needs to reflect the new business process and you also need to ensure that the new business process actually supports all the functions that the business needs. In the second case things are easier because you basically just need to capture an already existing process.
No matter the strategic focus of the IAM project a proper UAT needs to be business process focused. The whole point of UAT is to ensure that all business critical processes are present and are working as expected or at least in a way that is acceptable. The irony is of course that if you discover substantial process breaks in the UAT you are usually in deep trouble as it usually is too late to fix things before the planned go live.
The best way to avoid this situation is to ensure that you do a form of dry run UAT very early in the process. In my experience one of the best ways to do this is to utilize simple Visio workflows. You start with the requirements, which usually are more or less useless, and create Visio workflows. You then show the workflows for the people that knows or should know the business process. These people can rarely tell you what is needed but they can usually tell you if you get it wrong or tell you things that you should take into considerations. After a couple of cycles you usually have a pretty good process and you have also gained the buy in from one of the stakeholders.
If your architect is experienced he or she can usually produce a pretty good set of flows that can act as a starting point. Most more sophisticated consultancy organizations will be able to provide a standard set of flows as well. If your implementation team starts coding without first establishing, vetting and communicating the business process it is time to start getting alarmed. The project may still deliver successfully but it will most likely have a very painful UAT or even worse a very painful go live in front of it.
Tuesday, February 8, 2011
Pulse 2011
I will be in a panel at Pulse 2011 so if you want to hear me and some very distinguished copanelists talk about IAM you can visit session 1925 Identity and Access Management 2-3 pm on Mon Feb 28 in room 123 MGM Conference Center level 1.
My talk will be about the IAM challenges that BCBS MA currently are facing in the IAM space which is largely the same thing as what I am writing about in this blog so if you like this blog you may enjoy meeting me at Pulse as well.
My talk will be about the IAM challenges that BCBS MA currently are facing in the IAM space which is largely the same thing as what I am writing about in this blog so if you like this blog you may enjoy meeting me at Pulse as well.
Thursday, January 20, 2011
[TIM] Contractor life cycle management in TIM
In IBM Tivoli Identity Manager the most common design for supporting the contractor lifecycle consists of a termination date on the user form and a "lifecycle rule" that basically disables/terminates any contractors who have termination dates in the past.
The update of the termination dates can either be handled by a helpdesk or it can be done directly by the managers as TIM has a very detailed and good user form access engine in the form of the ACL and views which means that you can actually grant access down to the individual field.
The lifecycle rule (scheduled task in OIM speak) is also very easy to implement as you can define an LDAP filter that gives you the users that are ready for termination.
Not very hard at all. At least not as long as your requirements are as simple and straightforward as this.
The update of the termination dates can either be handled by a helpdesk or it can be done directly by the managers as TIM has a very detailed and good user form access engine in the form of the ACL and views which means that you can actually grant access down to the individual field.
The lifecycle rule (scheduled task in OIM speak) is also very easy to implement as you can define an LDAP filter that gives you the users that are ready for termination.
Not very hard at all. At least not as long as your requirements are as simple and straightforward as this.
Sunday, January 9, 2011
Contractor life cycle management
Most corporations have two general types of internal users.
The first category is employees or associates. The defining criteria of an employee is that they are present in the HR system. The HR system will tell us when a person joins the company, when a persons personal data changes or when the person leaves or gets fired. This is of course especially true if the HR system also feeds payroll. In most cases the IDM system will be directly connected to the HR system which will mean that the IDM system automatically will be notified about any changes.
The second categories are people that aren't directly hired by the corporation but rather are hired by another entity or they are hired by the corporation but in a different employment form. This means that this category of people are usually not present in the HR system. The users are still working for the corporation as consultants, contractors, contingent labor or partner employees. These users still needs access to IT systems so we need to somehow include them in the IDM system so that we can control their access.
If you are lucky the corporation actually has a database or some kind of application that tracks these users. In some cases it may not be one application but anywhere from a couple to a dozen applications. In this case you can just connect to these systems and you can handle these users the same way you handle employees.
In many cases there simply isn't any system that keeps track of the contractors so they need to be entered by someone directly into your IDM system. Not only do they need to be created but the contractor information also need to be maintained. Bearing this in mind what kind of lifecycle events do we typically need to support? In my experience these are the most important:
Update of personal data is always really hard to get actually get up and running. In most cases personal information about a contractor user tends to get stale which may or may not be an actual problem for the IDM system. For example if a contractor gets married and changes their name in the name information in the IDM system should be updated but in many cases this information is never entered into the IDM system.
Change of manager is a critical use case if you are using the manager as a source of truth about the contractor. It is common that a contractor initially gets hired to work for one manager but later the contractor switches projects and ends up working for another manager. If you don't have updated and correct information about which manager each contractor reports to you will have a problem. Another problem that you will encounter is that the contractors manager may have left the company without first reassign their reports to another employee. It is often a good idea to include a check for reporting contractors in the termination process for an employee.
Terminations is of course just as critical as creations. We do need to remove the access for contractors that no longer is working for the company but there is nothing that motivates anyone to share the fact that a contractor has left with us. The contractor is gone so the contractor won't tell us. The manager is unlikely to tell us as the manager has nothing to gain.
The standard solution to this problem is to implement mandatory recertification of contractors. When a contractor joins the contractor gets a finite life span. Typically life spans is somewhere between 90 days to a year. Unless the contractor gets extended the contractor will be terminated once the end date is hit.
In most cases the extension is done by the contractor manager either directly in a self service interface or by calling the helpdesk. In order to ensure that the manager remembers to extend the user you usually implement a reminder process that sends out a number of reminder emails typically starting 30 days before the termination is supposed to happen.
If the user no longer works for the manager that the idm system has listed then you have a problem. This is especially true if the manager has left the company. In many cases it therefor a good idea to send the warning email to the user as well as the manager. The user is usually motivated to talk to their current manager who will then make sure that the IDM system is updated and that the user is extended.
Once you have these processes in place your contractors life cycles are in place the audit and corporate information security departments should be happy. Or at least happy enough to leave you in peace for a while.
The first category is employees or associates. The defining criteria of an employee is that they are present in the HR system. The HR system will tell us when a person joins the company, when a persons personal data changes or when the person leaves or gets fired. This is of course especially true if the HR system also feeds payroll. In most cases the IDM system will be directly connected to the HR system which will mean that the IDM system automatically will be notified about any changes.
The second categories are people that aren't directly hired by the corporation but rather are hired by another entity or they are hired by the corporation but in a different employment form. This means that this category of people are usually not present in the HR system. The users are still working for the corporation as consultants, contractors, contingent labor or partner employees. These users still needs access to IT systems so we need to somehow include them in the IDM system so that we can control their access.
If you are lucky the corporation actually has a database or some kind of application that tracks these users. In some cases it may not be one application but anywhere from a couple to a dozen applications. In this case you can just connect to these systems and you can handle these users the same way you handle employees.
In many cases there simply isn't any system that keeps track of the contractors so they need to be entered by someone directly into your IDM system. Not only do they need to be created but the contractor information also need to be maintained. Bearing this in mind what kind of lifecycle events do we typically need to support? In my experience these are the most important:
- Creation
- Update of personal data
- Change of manager
- Termination
Update of personal data is always really hard to get actually get up and running. In most cases personal information about a contractor user tends to get stale which may or may not be an actual problem for the IDM system. For example if a contractor gets married and changes their name in the name information in the IDM system should be updated but in many cases this information is never entered into the IDM system.
Change of manager is a critical use case if you are using the manager as a source of truth about the contractor. It is common that a contractor initially gets hired to work for one manager but later the contractor switches projects and ends up working for another manager. If you don't have updated and correct information about which manager each contractor reports to you will have a problem. Another problem that you will encounter is that the contractors manager may have left the company without first reassign their reports to another employee. It is often a good idea to include a check for reporting contractors in the termination process for an employee.
Terminations is of course just as critical as creations. We do need to remove the access for contractors that no longer is working for the company but there is nothing that motivates anyone to share the fact that a contractor has left with us. The contractor is gone so the contractor won't tell us. The manager is unlikely to tell us as the manager has nothing to gain.
The standard solution to this problem is to implement mandatory recertification of contractors. When a contractor joins the contractor gets a finite life span. Typically life spans is somewhere between 90 days to a year. Unless the contractor gets extended the contractor will be terminated once the end date is hit.
In most cases the extension is done by the contractor manager either directly in a self service interface or by calling the helpdesk. In order to ensure that the manager remembers to extend the user you usually implement a reminder process that sends out a number of reminder emails typically starting 30 days before the termination is supposed to happen.
If the user no longer works for the manager that the idm system has listed then you have a problem. This is especially true if the manager has left the company. In many cases it therefor a good idea to send the warning email to the user as well as the manager. The user is usually motivated to talk to their current manager who will then make sure that the IDM system is updated and that the user is extended.
Once you have these processes in place your contractors life cycles are in place the audit and corporate information security departments should be happy. Or at least happy enough to leave you in peace for a while.
Monday, December 27, 2010
Names
The names of persons is a subject that will impact a provisioning roll out in many ways. Some very upfront and other more convoluted. If you ignore the subject you may regret this once your system is live and the problems starts showing up. Names are not only used to populate the basic name fields but also as generators for things like logins and email addresses so by solving some of the problems up front in the feeds you can avoid a lot of issues in the target systems.
In this posting I will talk about static names while a later posting will discuss name changes.
If you are US based and you are rolling out an employee only system the name seeding is quite straightforward. The HR system usually uses the name that is featured on the social security card so that is the name that gets feed to you. For the last name this is usually straightforward but many people go by a different first name. Their real first name may be "Joseph" but everyone calls them Joe so they want their email to be joe.smith instead of joseph.smith. The solution to this problem is to have a preferred first name field and use that in case it exists.
Next problem comes in form of names that contains weird characters such as O'Malley. Normal solution is to just filter out any non a-z and A-Z characters from the feed. Hyphens are also usually allowed.
Outside of the US problems get worse. You have all kinds of strange characters in names and just filtering away all "strange" characters may not work very well. The happy Swede "Åke Öhlund" would not be so happy with the email "ke.hlund". What I have found is that you can actually support most languages by a simple translation table with about thirty entries that simply drops the umlauts and accent characters and turn them into the corresponding ASCII character. Our friend "Åke Öhlund" would usually like to get the email "ake.ohlund". Or at least he won't complain too loudly.
There a number of national or regional issues that I have run into over the years. If your system will cover these regions it is worth investigating if you will run into this specific issue or not.
In some parts of the world people have more than one last as well as first name. For example among expat Chinese in Singpore it is common that you have an official Chinese name and in addition a western name. A preferred last name as well as preferred first name solves this problem.
In Holland a lot of people tend to start their last name with van as in "van Fleet". There may be a request to generate email addresses with the van removed.
Germans like their formal titles and sometimes the Herr Doctors wants their Doctor degrees to be an integral part of their last name. Don't be surprised if you find "Schmitt, Dr" in the last name field in the HR feed. In severe cases you may even find "Schmitt, Dr, Dr" or "Schmitt. Professor Dr".
In Latin America people usually have two last names as your inherit one last name from your mother and one from your father.
In this posting I will talk about static names while a later posting will discuss name changes.
If you are US based and you are rolling out an employee only system the name seeding is quite straightforward. The HR system usually uses the name that is featured on the social security card so that is the name that gets feed to you. For the last name this is usually straightforward but many people go by a different first name. Their real first name may be "Joseph" but everyone calls them Joe so they want their email to be joe.smith instead of joseph.smith. The solution to this problem is to have a preferred first name field and use that in case it exists.
Next problem comes in form of names that contains weird characters such as O'Malley. Normal solution is to just filter out any non a-z and A-Z characters from the feed. Hyphens are also usually allowed.
Outside of the US problems get worse. You have all kinds of strange characters in names and just filtering away all "strange" characters may not work very well. The happy Swede "Åke Öhlund" would not be so happy with the email "ke.hlund". What I have found is that you can actually support most languages by a simple translation table with about thirty entries that simply drops the umlauts and accent characters and turn them into the corresponding ASCII character. Our friend "Åke Öhlund" would usually like to get the email "ake.ohlund". Or at least he won't complain too loudly.
There a number of national or regional issues that I have run into over the years. If your system will cover these regions it is worth investigating if you will run into this specific issue or not.
In some parts of the world people have more than one last as well as first name. For example among expat Chinese in Singpore it is common that you have an official Chinese name and in addition a western name. A preferred last name as well as preferred first name solves this problem.
In Holland a lot of people tend to start their last name with van as in "van Fleet". There may be a request to generate email addresses with the van removed.
Germans like their formal titles and sometimes the Herr Doctors wants their Doctor degrees to be an integral part of their last name. Don't be surprised if you find "Schmitt, Dr" in the last name field in the HR feed. In severe cases you may even find "Schmitt, Dr, Dr" or "Schmitt. Professor Dr".
In Latin America people usually have two last names as your inherit one last name from your mother and one from your father.
Thursday, December 23, 2010
Gartner Magic Quadrants
Gartner has published a new provisioning magic quadrant. In my opinion it is a quite interesting read.
One of the main points is that there has been a shift away from provisioning towards auditing, access recertification (attestation in OIM speak) and governance. Gartner uses the term IAI (Identity and Access Intelligence). The main driver here is the fact that provisioning projects are long, complex and painful while IAI projects are easier and quicker.
In my experience this is a correct observation. The real challenge in provisioning projects is that the provisioning process in an enterprise tends to be quite complex. In many cases the process isn't properly documented or there may be multiple different processes in different parts of the enterprise. The business analyzes work that is needed to document the process can be very time consuming and in many cases important points are missed.
An alternative is of course to simply adopt a "best practice" provisioning process but this requires a lot of political will and in many cases the complexities of the enterprise process is present for a reason.
On the other hand few companies have an established IAI process so adopting the "best practice" is relatively painless. This means that the time consuming step of documenting and implementing the current corporate business process can be almost completely skipped in an IAI project. The integrator can basically use whatever canned approach they happen to have handy which means that results can show up in weeks rather than months (or sometimes even years) which is the time scale you need for a custom provisioning implementation.
IAI projects are usually run to improve security and reach compliance but they can actually result in substantial operational efficiencies as well. In one IAI project we found 100+ user accounts for a quite expensive (1000+ USD per year license fee) application that really weren't needed. The lower license cost was a quite nice bonus for the customer but they actually were even more happy about the fact that we found 600 active remote access accounts that no one could explain who they belonged to.
One of the main points is that there has been a shift away from provisioning towards auditing, access recertification (attestation in OIM speak) and governance. Gartner uses the term IAI (Identity and Access Intelligence). The main driver here is the fact that provisioning projects are long, complex and painful while IAI projects are easier and quicker.
In my experience this is a correct observation. The real challenge in provisioning projects is that the provisioning process in an enterprise tends to be quite complex. In many cases the process isn't properly documented or there may be multiple different processes in different parts of the enterprise. The business analyzes work that is needed to document the process can be very time consuming and in many cases important points are missed.
An alternative is of course to simply adopt a "best practice" provisioning process but this requires a lot of political will and in many cases the complexities of the enterprise process is present for a reason.
On the other hand few companies have an established IAI process so adopting the "best practice" is relatively painless. This means that the time consuming step of documenting and implementing the current corporate business process can be almost completely skipped in an IAI project. The integrator can basically use whatever canned approach they happen to have handy which means that results can show up in weeks rather than months (or sometimes even years) which is the time scale you need for a custom provisioning implementation.
IAI projects are usually run to improve security and reach compliance but they can actually result in substantial operational efficiencies as well. In one IAI project we found 100+ user accounts for a quite expensive (1000+ USD per year license fee) application that really weren't needed. The lower license cost was a quite nice bonus for the customer but they actually were even more happy about the fact that we found 600 active remote access accounts that no one could explain who they belonged to.
Monday, December 13, 2010
OIM Howto: Interacting with Tivoli Directory Server
OIM has a quite large list of of connectors but sometimes you need to interact with a target system that lacks a standard connector. One such example is TDS (Tivoli Directory Server).
TDS is used as the internal directory server in TIM and can also be used as a standard corporate directory or as the user directory for the IBM Tivoli Access Manager. It is a standard LDAP v3 compliant directory so in theory you should be able to use any of the LDAP connectors (AD, eDirectory and Sun JDS). I would generally not recommend trying to use the AD connector as it includes a lot of functionality that addresses peculiarities in AD but either the eDirectory or Sun JDS will work fine.
The problems that may force you to write a custom connector will often have more to do with the lack of functionality of the standard connectors than incompabilities between TDS and the connectors. The eDirectory and the JDS connectors have basically gotten minimal updating during the last four years so compared with the AD connector their functional depth is quite limited. One area where you may see compability issues is in the handling of roles and groups.
You may end up writing some custom logic in JNDI to complement the functionality of the standard connector which really isn't very complicated if you have some basic Java programming skills. An example implementation of a JNDI based connector can be found in the JNDI demo tool
TDS is used as the internal directory server in TIM and can also be used as a standard corporate directory or as the user directory for the IBM Tivoli Access Manager. It is a standard LDAP v3 compliant directory so in theory you should be able to use any of the LDAP connectors (AD, eDirectory and Sun JDS). I would generally not recommend trying to use the AD connector as it includes a lot of functionality that addresses peculiarities in AD but either the eDirectory or Sun JDS will work fine.
The problems that may force you to write a custom connector will often have more to do with the lack of functionality of the standard connectors than incompabilities between TDS and the connectors. The eDirectory and the JDS connectors have basically gotten minimal updating during the last four years so compared with the AD connector their functional depth is quite limited. One area where you may see compability issues is in the handling of roles and groups.
You may end up writing some custom logic in JNDI to complement the functionality of the standard connector which really isn't very complicated if you have some basic Java programming skills. An example implementation of a JNDI based connector can be found in the JNDI demo tool
Monday, November 29, 2010
Initial load
When you plan a typical internal focused provisioning system roll out one of the problems that you have to solve is how to get the information about the already existing users and accounts loaded into your new and shiny IDM system. Lets talk a little bit about design patterns for solving this problem.
In most cases you start out with one or more sources of basic user identities. These are the canonical truths about who actually works for your company. In most cases it includes a human resources system of some kind. If this system is connected to payroll it tends to contain very good data as the employees tends to complain if they don't get payed and the company don't like to continue paying people that no longer works for the company. In some cases you will discover that the HR system is only linked to payroll in some parts of the world while other, i.e. the UK office, uses another system to feed payroll. This usually results in the data in the HR system being less well maintained which can cause serious issues.
In many cases there are entities that needs to go into the IDM system that aren't present in the HR system i.e. contractors. Getting hold of data about these users is often not easy but there may be a contractor database somewhere. Worst case you may have to settle with data from the security badging system or from the corporate active directory. Even when you find basic information about the contractors you will often discover that the data quality can be very bad. Information such as manager id, current status or end date may not necessarily be well maintained. If you for example are planning to send warning emails to the manager of the contractor it will not be good if all 200 contractors in the manufacturing division reports to the division VP.
Assuming that you managed to discover your base identities the next step is to identify what target system accounts belongs to the base identities. In a perfect world there should be a unique identifier in each target system account such as an employeeid that can be traced back to one and only one account in the trusted source (i.e. the HR system). In practice this is rarely true. In most cases some target system accounts contains the unique identifier while a large percentage will need to be linked using less exact methods such as email addresses or in worst case names. Name based linking can be very time consuming and there is also a substantial risk that you will end up with false matches.
There are many tools available that will make the linkage process and if your account volume is decently high you want to start by doing automated matching using some form of script or program. Once you have cleared out the obvious matches you may want to switch over to a manual process that utilizes a simple Excel sheet to match between trusted source accounts and target system accounts.
If you can use a divide and conquer approach and divide the trusted source accounts and the target system accounts into distinct buckets things gets much easier. Lets say you have 3000 unmatched trusted source accounts and 5000 unmatched target system accounts you want to investigate if you can divide the accounts into ten country buckets based on the country attribute in both the trusted source account and the target account. This will reduce the problem to ten instances of matching 200-400 trusted accounts to 300-700 target accounts which is a much easier problem to solve. This approach of course assumes that there is a suitable "bucketing" attribute available in the target system as well as in the trusted source.
To sum things up preparing for the initial load essentially consists of the following steps:
If the data is in good shape this can be a quick process but if the data is bad it is not that uncommon that you need to spend 3-6 months on the data cleanup. It is therefor a good idea to include a data clean up and correlation thread in your IDM program that starts at the same time as you kick off the provisioning implementation project.
In most cases you start out with one or more sources of basic user identities. These are the canonical truths about who actually works for your company. In most cases it includes a human resources system of some kind. If this system is connected to payroll it tends to contain very good data as the employees tends to complain if they don't get payed and the company don't like to continue paying people that no longer works for the company. In some cases you will discover that the HR system is only linked to payroll in some parts of the world while other, i.e. the UK office, uses another system to feed payroll. This usually results in the data in the HR system being less well maintained which can cause serious issues.
In many cases there are entities that needs to go into the IDM system that aren't present in the HR system i.e. contractors. Getting hold of data about these users is often not easy but there may be a contractor database somewhere. Worst case you may have to settle with data from the security badging system or from the corporate active directory. Even when you find basic information about the contractors you will often discover that the data quality can be very bad. Information such as manager id, current status or end date may not necessarily be well maintained. If you for example are planning to send warning emails to the manager of the contractor it will not be good if all 200 contractors in the manufacturing division reports to the division VP.
Assuming that you managed to discover your base identities the next step is to identify what target system accounts belongs to the base identities. In a perfect world there should be a unique identifier in each target system account such as an employeeid that can be traced back to one and only one account in the trusted source (i.e. the HR system). In practice this is rarely true. In most cases some target system accounts contains the unique identifier while a large percentage will need to be linked using less exact methods such as email addresses or in worst case names. Name based linking can be very time consuming and there is also a substantial risk that you will end up with false matches.
There are many tools available that will make the linkage process and if your account volume is decently high you want to start by doing automated matching using some form of script or program. Once you have cleared out the obvious matches you may want to switch over to a manual process that utilizes a simple Excel sheet to match between trusted source accounts and target system accounts.
If you can use a divide and conquer approach and divide the trusted source accounts and the target system accounts into distinct buckets things gets much easier. Lets say you have 3000 unmatched trusted source accounts and 5000 unmatched target system accounts you want to investigate if you can divide the accounts into ten country buckets based on the country attribute in both the trusted source account and the target account. This will reduce the problem to ten instances of matching 200-400 trusted accounts to 300-700 target accounts which is a much easier problem to solve. This approach of course assumes that there is a suitable "bucketing" attribute available in the target system as well as in the trusted source.
To sum things up preparing for the initial load essentially consists of the following steps:
- Discovering the trusted sources that will provide the base identities
- Extracting the user data from the trusted sources
- Cleaning or at least evaluating the quality of the data contained in the trusted sources
- Discovering the target system accounts
- Linking the trusted identities to the target system accounts
If the data is in good shape this can be a quick process but if the data is bad it is not that uncommon that you need to spend 3-6 months on the data cleanup. It is therefor a good idea to include a data clean up and correlation thread in your IDM program that starts at the same time as you kick off the provisioning implementation project.
Thursday, November 18, 2010
Polyarchies in pratice
In A bridge(stream) too far I talked a little bit about using polyarchies to implement role mining. Lets take a closer look at this concept including a simple example.
Lets say you have a 1000 AD groups and 2000 users in your system and you would like to do some role mining in order to figure out if you could apply a role based approach to automatically grant the correct entitlements (AD groups) to the right user.
First you look at the information you have available about your users. You may find that you are able to place them in a number of different hierarchies. Lets start by looking at the location based hierarchy.
The company has ten locations and the locations can be organized in a country -> city -> building pattern. So for example the US has offices in two cities: Boston and LA. In LA there is a single location while Boston contains two locations.
Now sort the users according to their location. You may end up with something like:
->LA downtown: 130 users
Next step is to associate AD group membership with each site and sort them according to how many members that has that specific location exists in each group. The Boston Federal Square location may have the following groups:
Boston Distribution List 143 members
Boston FS Distribution List 140 members
Sales Distribution List 138 Members
Boston FS printers and fileshare 132 Members
Out of these it looks like Boston FS Distribution List and Boston FS printers and fileshares should be given to any users that have a Boston FS location. The Boston Distribution list could be checked against the parent node to see if it is also given to the Boston Haymarket users. If not then perhaps it is an additional group used for Boston FS.
The Sales Distribution List may be assigned through location but it looks more likely that it is tied to the functional hierarchy. It just happens that many sales people are based out of the Boston Federal Square office.
Doing this work by hand using Excel or a small database is very time consuming but it is fairly easy to automate this using Java or whatever is your favorite programming language.
You basically need:
If you prefer the COTS approach there are lots of different options. In my opinion the Oracle Identity Analytics (ex Sun Role Manager, ex Vauu RBACx) is a quite nice implementation. IBM has also included some capability in TIM 5.1 that is worth taking a closer look at if you are an IBM shop.
For further reading Oracle published a whitepaper on this subject this summer that is well worth reading.
Happy mining!
Lets say you have a 1000 AD groups and 2000 users in your system and you would like to do some role mining in order to figure out if you could apply a role based approach to automatically grant the correct entitlements (AD groups) to the right user.
First you look at the information you have available about your users. You may find that you are able to place them in a number of different hierarchies. Lets start by looking at the location based hierarchy.
The company has ten locations and the locations can be organized in a country -> city -> building pattern. So for example the US has offices in two cities: Boston and LA. In LA there is a single location while Boston contains two locations.
Now sort the users according to their location. You may end up with something like:
USA total: 380 users
-> Boston total: 250 users
---> Boston FS (Federal Square): 150 users
---> Boston Haymarket: 100 users
->LA downtown: 130 users
Next step is to associate AD group membership with each site and sort them according to how many members that has that specific location exists in each group. The Boston Federal Square location may have the following groups:
Boston Distribution List 143 members
Boston FS Distribution List 140 members
Sales Distribution List 138 Members
Boston FS printers and fileshare 132 Members
Out of these it looks like Boston FS Distribution List and Boston FS printers and fileshares should be given to any users that have a Boston FS location. The Boston Distribution list could be checked against the parent node to see if it is also given to the Boston Haymarket users. If not then perhaps it is an additional group used for Boston FS.
The Sales Distribution List may be assigned through location but it looks more likely that it is tied to the functional hierarchy. It just happens that many sales people are based out of the Boston Federal Square office.
Doing this work by hand using Excel or a small database is very time consuming but it is fairly easy to automate this using Java or whatever is your favorite programming language.
You basically need:
- Extract your base user data out of the trusted source (often an HR csv file feed)
- Enumerate the unique values of suitable attributes (i.e. list all unique locations) that is present in the trusted source
- Extract the group memberships (JNDI is my favorite) as well as user identities from the target system
- Correlate the users form the trusted source and the target system
- Calculate the user population in each unique attribute value
- Get the group memberships of the user population in 5
- Sort the groups according to the number of members
- Output the result in a user friendly format (Excel sheets works great)
- Attach some kind of cut off value i.e. only list groups where at least 75% of the users in a particular location is a member
- Look at the results and pick the likely candidates
If you prefer the COTS approach there are lots of different options. In my opinion the Oracle Identity Analytics (ex Sun Role Manager, ex Vauu RBACx) is a quite nice implementation. IBM has also included some capability in TIM 5.1 that is worth taking a closer look at if you are an IBM shop.
For further reading Oracle published a whitepaper on this subject this summer that is well worth reading.
Happy mining!
Thursday, November 11, 2010
New to OIM
Back in the bad old days when you started with Thor Xellerate (or a little bit later OIM) you usually got the three day Thor training workshop and then you basically had to figure out things on your own. There was some documentation but most things in the central OIM platform you had to basically reverse engineer and good decompiler and sniffer were your best friends.
Oracle has made great steps forward on the documentation side over the last few years and a lot of the material is available to anyone.
If you are new to OIM I would suggest starting with downloading the OIM install and taking a look at the documentation folder (9.1 release). I would start by reading through the concepts document as this will give you a good overview of what the OIM tool actually can do.
Next step is to implement a couple of the exercises in Oracle by Example. I would suggest the following:
This will give you an overview of the basic function of OIM, Once you are done with the basics you can continue to explore how to customize the user interface and creating your own connectors.
The Oracle IDM forum is another great resource and if you have a metalink account there is also a lot of good information in the support knowledge DB.
On a slightly more humorous note I suggest So You Want to be a Game Designer. The skill set that makes a good Game Designer is actually quite similar to the skill set you need as an access and identity designer although knowledge of world myths and world religions may be slightly more useful to the game designer (although both can benefit from knowing what Kerberos is).
Welcome and best of luck!
Oracle has made great steps forward on the documentation side over the last few years and a lot of the material is available to anyone.
If you are new to OIM I would suggest starting with downloading the OIM install and taking a look at the documentation folder (9.1 release). I would start by reading through the concepts document as this will give you a good overview of what the OIM tool actually can do.
Next step is to implement a couple of the exercises in Oracle by Example. I would suggest the following:
This will give you an overview of the basic function of OIM, Once you are done with the basics you can continue to explore how to customize the user interface and creating your own connectors.
The Oracle IDM forum is another great resource and if you have a metalink account there is also a lot of good information in the support knowledge DB.
On a slightly more humorous note I suggest So You Want to be a Game Designer. The skill set that makes a good Game Designer is actually quite similar to the skill set you need as an access and identity designer although knowledge of world myths and world religions may be slightly more useful to the game designer (although both can benefit from knowing what Kerberos is).
Welcome and best of luck!
OIM Howto: Add process form child
There is a number of posts on this blog that talks about managing target system groups by manipulating child form contents. In a recent OTN IDM discussion thread Deepika posted some useful example code so in order to make the previous posts on this subject more useful I thought it would be a good idea to link in the example.
public voidAddProcessChildData(long pKey){
try {
tcFormInstanceOperationsIntf f = (tcFormInstanceOperationsIntf)
getUtility("Thor.API.Operations.tcFormInstanceOperationsIntf ");
tcResultSet childFormDef = f.getChildFormDefinition(f.getProcessFormDefinitionKey(pKey),f.getProcessFormVersion(pKey));
long childKey = childFormDef.getLongValue("Structure Utility.Child Tables.Child Key");
//if there is only 1 child table fo rthe parent form else you need to iterate through result set
Map attrChildData = new HashMap();
String groupDN = "someValue";
attrChildData .put("UD_ADUSRC_GROUPNAME",groupDN);
f.addProcessFormChildData(childKey,pKey,attrChildData);
}catch (Exception e){
e.printStackTrace();
}
}
Monday, November 8, 2010
A bridge(stream) too far
Over the years I have run into a number of products that had lots of good ideas but perhaps simply didn't have enough resources to implement them properly. One of these is Bridgestream Smartroles (aka Oracle Role Manager). This product is no longer with us having been trumped by Sun Role Manager (aka Vauu RBACx) but I really think that the product came with some good concepts that you can use in your IDM implementation no matter what product you are using.
Business roles vs IT roles
Roles are basically a tool to group entitlements together into manageable packets. If you ask an IT person and a business person what manageable packets are and how they should be named the two groups tend to disagree a lot.
One approach to solve this problem is to let the business have their business roles (teller level two) and let the IT guys build their own roles (two AD groups, logins to two applications configured with specific application roles). Then you just combine the IT roles into business roles and the business can then be asked to certify that Emma Smith the teller should have this business role. The fact that the business role actually results in three IT roles which in turn results in a bucket load of entitlements (AD groups etc) is not really relevant to the certification decision.
In reality things rarely works out this smoothly but I have found the approach useful.
Everything is temporal
One of the nifty features in Bridgestream was the temporal engine which made the eternal problem of the ever changing nature of everything.
In many role related IDM projects it is very easy to forget that everything including the roles and the entitlement has a lifecycle and will need to change as some point. Manging this without support in the base framework can get very complex so building in proper support for temporality is key to making maintenance cheap and easy.
Polyarchy
Hierarchies are really useful when you want to organize users. One problem that you often run into is the fact that a specific user may be in a number of different hierarchies. One may be the geographical location, another may be the reporting chain and a third may be the kind of position you are in (i.e. embedded HR or IT departments that report into the business unit with dotted lines to the corporate HR or IT). It is literally impossible to capture all these relationships in a single hierarchy.
Bridgestream introduced, at least to me, the concept of polyarchy. Instead of trying to wrestle all these relationships into a single hierarchy you simply create multiple hierarchies where each hierarchy reflects one aspect of the users relationship with surrounding nodes. If you also are able to divide up the entitlements into buckets where each specific bucket is likely to be assigned due the users position in this specific hierarchy (a role called "Cambridge campus" or "Floor 3 - building 6 - Cambridge campus" are likely location based) you have a good tool that can reduce the complexity of the role discovery substantially.
There is a more expanded example of Polyarchys in action in the post Polyarchies in pratice
Business roles vs IT roles
Roles are basically a tool to group entitlements together into manageable packets. If you ask an IT person and a business person what manageable packets are and how they should be named the two groups tend to disagree a lot.
One approach to solve this problem is to let the business have their business roles (teller level two) and let the IT guys build their own roles (two AD groups, logins to two applications configured with specific application roles). Then you just combine the IT roles into business roles and the business can then be asked to certify that Emma Smith the teller should have this business role. The fact that the business role actually results in three IT roles which in turn results in a bucket load of entitlements (AD groups etc) is not really relevant to the certification decision.
In reality things rarely works out this smoothly but I have found the approach useful.
Everything is temporal
One of the nifty features in Bridgestream was the temporal engine which made the eternal problem of the ever changing nature of everything.
In many role related IDM projects it is very easy to forget that everything including the roles and the entitlement has a lifecycle and will need to change as some point. Manging this without support in the base framework can get very complex so building in proper support for temporality is key to making maintenance cheap and easy.
Polyarchy
Hierarchies are really useful when you want to organize users. One problem that you often run into is the fact that a specific user may be in a number of different hierarchies. One may be the geographical location, another may be the reporting chain and a third may be the kind of position you are in (i.e. embedded HR or IT departments that report into the business unit with dotted lines to the corporate HR or IT). It is literally impossible to capture all these relationships in a single hierarchy.
Bridgestream introduced, at least to me, the concept of polyarchy. Instead of trying to wrestle all these relationships into a single hierarchy you simply create multiple hierarchies where each hierarchy reflects one aspect of the users relationship with surrounding nodes. If you also are able to divide up the entitlements into buckets where each specific bucket is likely to be assigned due the users position in this specific hierarchy (a role called "Cambridge campus" or "Floor 3 - building 6 - Cambridge campus" are likely location based) you have a good tool that can reduce the complexity of the role discovery substantially.
There is a more expanded example of Polyarchys in action in the post Polyarchies in pratice
Subscribe to:
Posts (Atom)