Pollicove's Law of Provisioning

I find it interesting when I see a book listed on a website on the topic of Identity Management is invariably about access management or some other aspect of identity and information security. Now, I completely admit to being biased, but why is there not more thought put out there about the management of identity, a la provisioning, directory/metadirectory design, etc? I know it is possible to find some decent books on LDAP (LDAP Directories Explained is one very good one)but these mostly talk about the LDAP protocol and structural considerations.

Could it be that Identity Management is a much simpler task than we think it is? If this is the case why is the configuration of provisioning systems not a turnkey operation? Particularly since some of the biggest Provisioning vendors support application specific connectors (A topic that I thought I had covered, but I'll definitely cover in an future entry.) one would think that this should be the case.

The problem, as I have often said is this:

Show me any three companies of similar size and vertical, using basically the same set of applications and they will do it in at least three different ways.

Which is what I believe is the basis for what I will now call “Pollicove’s law of Provisioning”

Given x number of companies of the same size and vertical, provisioning (and de-provisioning) activities will occur in at least x+1 number of different ways.

Let's go into this in some detail:

The fact is Identity Management will always be more art than science, even though all companies utilize the same universal basics of Provisioning (Reconciliation, Self Service and Delegated Administration) Every company has its own unique set of processes that have been with them since well before the Information Technology revolution. This happens regardless of Compliance / Regulatory legislation, which further contributes to the uniqueness, with the uniqueness causing factors including, different auditors/methodologies, back end technologies and corporate cultures.

The last part of Pollicove’s law states “in at least x different ways” This is because many large enterprises have multiple provisioning methodologies due to M&A, independent subsidiaries, international presences and other independently evolved divisions of the company. I’m sure we can find more reasons without thinking too terribly hard.

This being said, there has to be some commonality, given some of the universal basics mentioned above. I believe the greatest “economies of scale” covering Provisioning will revolve around these topics. Furthermore specialized features such as account claiming, password management (self service and delegated), and other extensions of the universal basics are where this will come in to play. So in essence, I believe that successful provisioning implementations will come more out of established “playbooks” of how these and other activities are to be conducted. Given time and experience, the successful provisioning architect will come right to the customer with a set of basic use cases, business analysis templates and design outlines which will be quickly turned into complete design docs and implementations.

Non technical updates

I know that I've been spending a lot of time on NetWeaver Identity Center Issues.  Hope it's been of some use to everyone out there.  I'd like to take a few moments and just comment on some things I've been hearing lately.

First of all there's the whole LifeLock deal.  Honestly, most of my initial thoughts were unprintable and more eloquently stated in other parts of the blogosphere.  But I'll leave it at this:  Identity and Credit protection services are only part of the solution.  Basic steps in protecting your authoritative identity information should include not blabbing it to everyone you know on TV, Radio and especially the internet!  Keeping that information private should be nothing less than your first line of defense.  'Nuff said.  Moving on...

A big theme of this blog in its first life was the usefulness, properties and functioning of Virtual Directories.  So it's always with interest that I look to see what Clayton Donley over at Oracle has to say on the topic.  He's one of the few people I've seen who continue the discussion of this IdM tool.

That being said, I will get on to disagreeing with some issues in his latest blog posting:  Personal Fire Trucks and Overengineering Identity Solutions. While I whole-heartedly agree with him that many Identity projects are vastly overengineered, I disagree that caching is a factor in this. To paraphrase his story, Clayton likens the use of caching to a person buying their own fire truck in case there is a fire in the home.  

Caching as a whole makes data more ready for access and usage by users and enterprise systems connected to Identity Repositories.  Is caching a personal fire truck?  I don't think so. However, I can see that as a result of poor analysis, design and engineering, caching could be used inappropriately to bolster a failing solution.  

Caching, like all tools can be used for a multitude of purposes, much like a fire truck.  It all comes down to why you are using the cache.  Is it to supplement the solution or carry it?  Too little or too much caching results in poor information and longer, not shorter response times.   It is up to the Identity Architect to decide if the solution needs a fire extinguisher or a fire truck.  Criticizing the Architect for preparing for increased demand, latency and other design considerations is only appropriate if it is improperly used.

An IC Tip and a Lesson Learned

I was doing some research for a customer who had the following question:

How can I dynamically assign a role during user reconcilation from my authoritative source?

Here's the issue:

• IC has a defined Role called CHICAGO/DATA ENTRY/PRODUCTION that has an MSKEY of 100
• During reconcilation, the user entry from the authoritative source includes the name of the role.

We know that we could do a To Identity Store pass that includes the MSKEYVALUE of the user and the MSKEY of the role assigned to MXREF_MX_ROLE.

But that is hardly dynamic. I thought about doing a script but I did not want to get into the hassle of that, so I asked around and I got some good infomration. This can be easily done in IC. When doing the assignment to MXREF_MX_ROLE, pass the attribute holding the Role name, but encase it in < >. (i.e., <%ATTR_NAME%>)

What will happen is this: when the attribute is enclosed in <> IC knows that this is a potential MSKEYVALUE and will search the Identity store for this information and return its MSKEY.

Now this all seems very straight forward, but I could not get it working to save my life. After a lot of back and forth it was discovered out that I "fat-fingered" my test data.

Morals of the story:

1. Start with simple test data and build it up as needed, even if it does not 100% match the test case.
2. Always double check your typing

I had a chance to work with a gentleman who had worked on many of the LDAP RFCs and I asked him what percentage of LDAP errors are due to typos. He didn't hesitate in has answer: "85%". That was before he met me of course...

Thanks for all those out there who helped out and resisted knocking me silly!

SP2 and CONFIG.XML

So, I was updating an Identity Center instance last week to SP2 and I found that after the upgrade I could no longer access the Workflow or Monitoring Web User Interface.

After some investigation and inquiries, I was told to check out the CONFIG.XML file, which is one of the first places one should check when troubleshooting, that I might be missing some information.

Here's the relevant section of my CONFIG.XML:

<workflow>
<servertype>MSSQL</servertype>
<serveraddress>LOCALHOST</serveraddress>
<databasename>mxmc_db</databasename>
<username>mxmc_prov</username>
<password>Changeme</password>
<cryptkey>C:\IC\workflow\configs\KEY\keys.ini</cryptkey>
</workflow>

I did not see anything wrong here, and then I thought to compare it to a clean install of Identity Center. I found that the following lines were added:

<charset>UTF-8</charset>
<loglevel>0</loglevel>
<enable_cache>FALSE</enable_cache>
<sessionstore>DEFAULT</sessionstore>
<sessionstore_params>
<default_language>EN</default_language>
<default_dateformat>YYYY-MM-DD</default_dateformat>

So I cut this information out and dropped it into my Upgrade install. Fixed my Workflow and Monitoring Issues and I was able to finish my upgrade.

Moving on...

Provisioning Concepts

Something that always comes up when working out new provisioning solutions is the problem of how to deliver account information to new users. Some solutions I've seen revolve around:

• Sending logon information to the users manager or sponsor
• Calling the user down to IT or IS to deliver the information
• Setting up the user with default credentials.

In all of these cases there's the risk of having other people besides the "provisionee" who have access to login information. This also does not scale when large number of users need to be provisioned as happens in Higher Education or when bringing new systems into the enterprise.

Now this can all be made slightly more secure by requiring the user to change their password when they login for the first time.

A popular way to handle this is through the use of what is called Account Claiming or Account Activation. In this process, login information is delivered to the "provisionee" either by email or postal mail with their login ID and a temporary password. The user is directed to a specific URL where they will be asked to enter their login ID and temporary password. After this information is loaded workflows can then be executed that require the user to amongst other things:

• Enter additional required information
• Set security information such as challenge/response questions
• Confirm existing identity data
• Perform other organizational/institutional tasks as required

This can be further secured by requiring that part of the temporary password be something only the user will know, such as elements of SSN, Birthdate, graduation year, etc. This helps us to fall into the old security formula of something you know + something you have = maxium security. I think that the ultimate levels of security will occur when the something you have is biometic in nature, but that is a discussion for another time.

Thank you, Mr. Flynn!

I'd like to take a moment to thank my former colleague and Identity Management discussion partner, Matt Flynn for a great reference on his blog. Matt and I worked (and sat in adjoining cubes) at MaXware. I've enjoyed reading his blog and find that he always has something interesting to say. Please take a moment and visit his blog, trust me, it's worth it!

Most important things to ensure a successful project

As discussed earlier, a pressing concern in Identity projects concerns success and failure factors.

I believe there's a core item that both the client and the implementer can bring to the table to help ensure success.

From the Implementer, it is essential that a good business analysis effort takes place. I don't think that anyone expects that this can happen in one or even a few sessions. However, the person(s) who are doing the current/target state analysis, must ask probing questions and follow up on them. It's important that the BA has a complete and thorough understanding of what the customer has and what they want. This can be a delicate process as the BA and customer learn about each other and the processes. One of the BA's best tools in this effort is to make sure they have a good process to work with. Templates, flow charts and other tools can create efficiencies in this process.

From the client side, preparation is the key. Having documentation on current processes and flows is most helpful to make sure that the project team succeeds in delivering the correct and complete product. Now we all know that not all of this information will be available when needed, but having the SMEs on call and tracking gap items helps to remediate this. Strong client side PMs and executive sponsors are also critical in keeping this an efficient process.

Ultimately it is the synergy that is created by the client and implementation teams that brings out the best results. With both sides working together the greatest progress is made and the best results are to be had.

Working with SAP NetWeaver Identity Center 7.0 SP1

I am doing some consulting work for a company in Atlanta, Georgia for the next month. This has given me my first formal experience with IC 7.0 SP1, and my first ever experience running with Microsoft SQL Server 2005. All in all it's been a pleasant experience. The Trondheim Labs team has done some nice things to make the installation process go more smoothly and securely than ever before.

Notably good is that PHP updates go much more smoothly and do not require user intervention (do you wish to overwrite your PHP config).

Also during the SQL Server installation script, the person conducting the installation is prompted for individual passwords for mxmc_admin, mxmc_oper, mxmc_rt, and mxmc_prov. Lots of typing and verification for all the passwords, but time well spent.

What's bad about the process is that one must now download and install SMARTY separately, as it is no longer a part of the Workflow / Monitoring installers. It's pretty much a drop in installation so it's not that big a deal. I wonder if this is a bit of foreshadowing that PHP and Smarty are going away from IC?

On the down side of the installation we got a SQL error when initially logging into Worfklow which was:

PHP Warning: mssql_query() [function.mssql-query]:
message: The SELECT permission was denied on the object
'mxwv_ProvGroups', database 'mxmc_db', schema 'dbo'. (severity 14) in \dbwrapper.php on line 71 PHP Warning:
mssql_query() [function.mssql-query]: Query failed in
\dbwrapper.php on line 71

I also saw a simiar error for mxvc_idstore. The error is rather tough to spot as most of it appears behind the header graphics.

This error is specific to Microsoft SQL Server 2005 as it references the "dbo" schema. Schema level security does not exist in the SQL Server 2000.

To resolve this problem, log into the SQL Server 2005 Studio and select the Identity Center Database, then security, schemas and then DBO, permissions and then view database permissions. You will then need to grant SELECT permissions to mxmc_admin_u.

As we have a chance to do more, I will comment on it.