Regarding a Potential Way Forward for SPML

Some of you might have followed the conversation in the blogosphere regarding SPML a few months back. If interested, get up to speed by reading the posts below:

- Mark Diodati, Burton Group: SPML Is On Life Support
- Ingrid Melve, Feide: Provisioning, Will SPML emerge?
- Nishant Kaushik: Oracle: SPML Under The Spotlight Again?
- Jeff Bohren, Identity guru: Whither SPML or Wither SPML?

- Jackson Shaw, Quest: SPML - Not Dead Yet!

Last month, I had the opportunity to join a discussion with some really smart folks regarding the future of the SPML standard at the SPML SIG (Special Interest Group) at the Burton Group in San Diego. Anyhow, Mark Diodati led the session and recently published some of the conversation points discussed at the SIG. Take a look here.

IAM Failures...Product or Services?

Jackson Shaw put up a few interesting posts last week regarding IAM Project Failures. The first was a company that sank $7M into an IAM Initiative that never took off. The second was an informal survey of 9 IAM projects (6 used Sun, 3 used Novell). Jackson concludes:

This was a great illustration to me of how far our little industry segment needs to improve. None of these customers were trying to do anything fancy. They had fancy plans originally but they were failing on basic provisioning or password management and were never able to progress further. It also further reinforced my view that there’s a great opportunity for a solution that doesn’t require a couple of busloads of consultants to get it (and keep it) running. A solution that delivers immediate value. A solution that customers are happy to have. A solution that is my dream

The question that I'd like to pose is, where does the cause of the failure lie? Is it a lack of IAM product capabilities or IAM services?

In my take, IAM products have evolved (and continue to evolve) quite rapidly. Due to my profession, I am present when customers are shown IAM products from vendors and even when they get to test-drive them. Some of the stuff out there now is downright impressive...from visual drag-n-drop workflow capabilities to wizard-like setup of connectors, all in all, the innovation I've seen on the product side is impressive. Furthermore, most IAM project failures that I've seen occur are rarely due to the lack of a product feature.

I think the problem lies in the services side of the IAM house. I suppose that statement is a confession of sorts, since that's the industry I've lived in for the past however long. Anyhow, the IAM services game is anything but impressive. To pull from one of Brad Feld's quotes, IAM services companies typically win deals because 'they suck less' than the next guy. Definitely nothing to be proud of! The services models are pretty much stagnant with limited innovation over the past decade. Every consulting firm has roughly the same implementation model (discovery, design, implement, test, blah blah blah). Replace those words using a thesaurus and you have the next System Integrator's methodology. That's why I believe there needs to be a shift in the IAM services paradigm.

What's your take? What's the culprit? IAM Product or Services?

On Developing a Deprovisioning Policy

An interesting discussion emerged out of a blog entry over at the Identropy blog on developing a Deprovisioning Policy.

I've reproduced both the contents of the blog and the comments section (which is probably more interesting than the article) below. Enjoy!

----

Identity Management technology can be tricky. But in most instances, it's not the technology that trips up an implementation. It's the policy development (or lack thereof) that causes the heartache.

Deprovisioning Policy is typically more complex than a simple policy that states that when HR says a person is terminated, the identity system terminates the user's access to all systems. Here are a few things to consider when developing your Deprovisioning Policy.

1. Deprovisioning Policy (Technical View)

The technical view of a deprovisioning policy is concerned with what the identity system should do once we know that the user should be deprovisioned for each target system.

• Should the user's account be hard deleted or just disabled?
• If disabled, how is that done? (Move the AD account to a disabled users OU, place the row into an archive table, etc.)
• How long should disabled users be kept in the system?
• What should happen to the person's shares, mailbox, etc.?
  

2. Deprovisioning Policy (Business Process View)

The business process view of a deprovisioning policy addresses the states that should trigger a deprovisioning action. Here are a few questions to ask your policy team:

• How do we calculate the actual last day a person should have access? Is there an effective date that can be used? Is HR using that field properly?
  
• How should 'leaves of absence' be handled?
• What should happen if a person wants to use his/her vacation days directly before retirement? What if the person may still provide off-site help during this time period and therefore needs access?
• How should sabbaticals be handled?
• Should a user's current access be terminated in a department transfer? What if they still need their old access for some time?
  
• How should unused sick days be taken into consideration?

3. Take Compliance Policy into Consideration

Besides the business process view of the policy, sometimes existing regulatory compliance rules may have an adverse impact on an otherwise sensible policy. For example, definitions of 'termination', 'employee job role change' and 'leave of absence' will directly impact the overall policy and should be taken into consideration.

By thinking through these issues, an effective Deprovisioning Policy can be put together prior to implementing an IAM solution.

----

Comments:

Hi Ash, my suggestion (as always with IAM related decisions) is to start from the business view and try to stay out from the temptation to start analyzing the event from a technical standpoint.

Using business as starting point can be very helpful for example in fragmented, complex or very dynamic environments where could be very hard to find a common agreement on the right behavior to follow and where, probably, it can give you also a longer-term solution.

What do you think?

Posted @ Tuesday, April 13, 2010 7:10 AM by Luca

Hi Luca,

Interesting point.

From a policy standpoint, both sides (biz process view and tech view) have to be defined. And although the business process view (i.e. defining the states of the user should trigger a decommissioning of the user's access) is critical, the policy would simply be incomplete without the tech view.

From a dependency standpoint, I really don't see that one piece of this is dependent on the other...(although I'm still thinking through it). It's almost as if both sides of the policy can be developed independently.

Thoughts?

Posted @ Tuesday, April 13, 2010 11:13 AM by Ash Motiwala

Ash, for sure both sides (biz process view and tech view) have to be defined. My suggestion is to avoid developing them independently and where possible to start from the business view and requirements and understand how those requirements can be fulfilled from the technical standpoint.

My idea is based on two main assumptions:

1) Technology should support business and so we should start from it and try to define the best suitable tech solution. So, is it possible to keep them independent?

2) Deriving technical view from business view allows to have more stable policies because in my (very very short) experience I’ve saw more stability on the business requirement than that on the technical one. Technical side of policies could be more fragmented, detailed and sometimes system dependent and for this reason more subject to modifications when changes happen in the technical infrastructure (mergers, new systems, etc.). In my opinion, this approach allows to keep unchanged business view and most of the decisions related to the tech view.

Are, in your opinion, my assumptions valid?

Posted @ Wednesday, April 14, 2010 2:47 AM by Luca

Hi Luca,

I'd agree in general that business process development should happen before technical analysis, (as I've mentioned in other articles here).

In order to think through this, I posed myself the following: should the following 2 questions (1 business process oriented, the other technically oriented - as defined in the article) be answered in a specific order?

1. Should a leave of absence translate to termination of access?
2. What should happen to a person's shared folder contents once terminated?

Thinking through this, the 1st question should be posed to the business process owner - whose answer will provide context to the technical owner to answer his part of the question...since a leave of absence (as a state) will probably have a direct impact on how long to hold on to a person's mailbox or shares. And will probably have a different impact on a person who was terminated for cause.

So yes...I agree. Thanks for the insight, Luca!

Posted @ Wednesday, April 14, 2010 5:42 AM by Ash Motiwala

Sorry MIIS, It's Not You, It's Me

Here's some geek humor. A buddy of mine sent me an old email correspondence I had with him back in 2006 (back when ILM, I mean FIM, was MIIS). I was doing my best to get him going on the training path on the product, and this is what he wrote me after doing MIIS dirty:

Now if you'll excuse me I have to go speak to MIIS. I think it's mad at me cuz I haven't touched it for so long (it's starting to feel that I think it's ugly). It's my fault actually, I met someone named Tivoli at a party and we really hit it off. You know when you have that connection instantly? Anyway, since then MIIS and I haven't been speaking much outside of the daily niceties a couple stuck in a rut routinely exchange. Both of us know it's a facade, but we maintain it, almost mockingly, for the sake of the little Management Agents we have running around. To make them Disconnectors now, would be devastating to business continuity.

As a side note, he still doesn't know MIIS/ILM/FIM. "If-you-don't-know-me-by-now..." :)

Series on Developing an Identity Management Roadmap

I've recently been involved in putting together a blog series on developing an Identity Management roadmap. It's a 3 part series over at the Identropy blog. Part 3 is a bit long for my taste, but has a lot of great content I'm sure you'll benefit from if you are involved in identity management strategy development for an organization.

Part 1 is an intro to what an identity management roadmap is, who needs one, who doesn't and why.
Part 2 is about the prerequisites to developing a roadmap.
Part 3 is the meat & potatoes of how to develop one.

We've left some room for input and discussion. Chime in!