Virtual Directories and Persistent Cache

I got drawn into a debate lately about the pros/cons of persistent cache in a virtual directory, and the practical implications of it. (I know this is an old debate. Better late than never?) A persistent cache is basically storing a copy of data locally at the virtual directory, so it doesn't have go get the data each time.

The first question is 'why add this capability? isn't the whole point of a virtual directory provide real-time access to backend data?' In my conversations, I basically received one answer: performance. Virtualizing and transforming the data can slow things down a bit.

Clayton Donley makes a case against persistent cache in an older post. To summarize:

• Persistent cache will mean data isn't real-time, which means the 'freshness' of data will be compromised.
• There are security concerns with adding another place to keep the data.
• There is pain associated with managing yet another directory.

(i.e., if you want a metadirectory, then get a metadirectory!)

So, I've come up with a few questions, and was wondering if anyone has any thoughts about it...

1. Since performance is the main point here, does any one have numbers on the performance hit caused by virtual directories?
2. Is performance the only real justification for persistent cache?

Managed Identity Services Winner

Thanks to everyone who filled out the Managed Identity Services survey. We finally identified the winner of the giveaway....and the winner is Niall McLoughlin! Enjoy your new iTouch! Thanks Ian for all the work on the survey, and thanks Matt for aiding with the whole winner selection thing.

A Few More Snappy IdM One-Liners...

In response to my request for snappy one-liners that would be applicable for identity projects, Jeff Bohren and Mike Conklin (welcome to the blogosphere, Mike!) provided some input. Here are some of my favorites:

• The dirty little secret about provisioning is that it’s really all about deprovisioning.
• You shouldn’t start out trying to do account management by adding another account to manage.
• It doesn't matter what you do on the back-end -- if the end users (and project sponsors) can't see tangible results that affect their day-to-day activities, all the process re-engineering and data clean-up in the world is going to go unnoticed and unappreciated.
• For whatever reason, hearing the exact same thing come from an outside consultant actually sinks in with management, but this never seems to happen for internal people :)

Seems like fun so far... so, I'm tagging Matt F., Matt P., Azeem Khan, Mike Trachta, Ian Yip and Jackson Shaw (just to throw a little product in the mix) to contribute their wit to the conversation.

It's About the Business...

I just got back from another long day with a client to aid them lay out their identity management roadmap. I've noticed a few interesting recurring themes:

• Good technology can't compensate for bad processes (although it might make it less painful)
• Fixing your data without fixing your processes is like painting your house on a rainy day
• Throwing more software at an identity problem usually exacerbates it
• A dollar in an identity project doesn't take you as far as you'd expect (even though its well worth it)
• What business users think is happening is quite often vastly different than what is happening under the hood
  

Any other snappy one liners?

Repealing SOX and Identity Management

Newt Gingrich and David Kralik wrote an op-ed in today's San Francisco Chronicle about repealing SOX. I've been following the buzz around this for a few months, but it always has a bit more bite when it comes from a former Speaker of the House. Gingrich and Kralik outline a number of convincing reasons to repeal SOX, including its negative impact on the IPO market as well as its failure at "...preventing insolvencies and accounting shortfalls in companies such as Bear Sterns, Lehman Bros., American International Group (AIG) and Merrill Lynch." The last lines of the article are very action oriented,

With a new presidential administration and a Congress convening in less than three months, now is the time to begin thinking through the solutions needed to address our economic challenges. Economic growth in a sound market economy requires smart regulation, not destructive regulation that hurts economic growth. Sarbanes-Oxley fails that test. It should be repealed.

I've written previously on the need to move away from compliance as *the* driver for identity. A legislative act such as this could force our hand as an industry. Being personally involved in the process, I am acutely aware of the impact that compliance has on quickly approving budgets for projects, and the way IT has leveraged SOX in order to push projects of their liking (even if its true ability to demonstrate compliance was suspect). This hyper-compliance environment may have created complacency on our end from the perspective of demonstrating the true value of identity for the business. Anyway you slice it, if SOX gets repealed (or slimmed down, as I expect it will be), we're going to have think a little harder, and I think that's a good thing.

Random Thoughts on Hitachi and Construction Cranes

Looking outside of my window this morning, I noticed a construction crane with the label "Hitachi" on the side. I kind of chuckled at the notion that a company could provide Identity Management software and construction machinery at the same time. Being part of startups nearly my entire career, where focus and niche is everything, my narrow view of the world makes it difficult to comprehend that a company could do such vastly different things effectively. Then again, it's not the first time. Siemens has its foot in the Identity world, and makes hearing aids and dishwashers too.
Does laser focus in the startup world not apply to larger corporations? I'm sure there are a few dozen books on the topic...time to go find 'em.

The Answer is...On-Premise Managed Identity Services

Ian has posted his findings from his Managed Identity Services survey. My primary interest around the survey was to see if data could be collated that could identify characteristics of a managed services solution around IdM that would make customers "comfortable". (In the past, I've posted on the "comfort vs. security" notion). Anyhow, some tasty nuggets are below. Go to the real survey findings for more.

• 67% of respondents have already completed a provisioning implementation (3% as SaaS, 10% have done it in some type of managed service offering, 37% have host and manage it themselves)
• When asked what model they would prefer, 19% wanted SaaS, a whopping 36% wanted an on-premise managed service, 19% wanted an hosted managed service model (that's a total of 55% who are looking for a managed service offering!), while only 13% want to handle it all themselves.
• When asked about what was the barrier preventing them from outsourcing IdM, 22% identified security risks around data being held outside of their infrastructure, 20% said risks regarding external people access their environment, 14% said cost, 11% said loss of control.

So, it seems that although most respondents managed it themselves, over half wanted a managed service model. The risk around data being held outside of their infrastructure could be alleviated by an on-premise model, although I don't think that the significant 20% who didn't want outsiders accessing their environment will be appeased by any solution.

A Few IdM Vendors Responding to the Market

Courion put out a press release today around their Jumpstart program for Password Management deployments. Undoubtedly not a coincidence given the market conditions. It's worth a look - 4 target systems, ROI in 30 days, fixed-price delivery. Not too shabby.

Also, Symplified has a webinar coming up entitled 'Scary Economic Times Heighten The Need for SaaS Security' with Jeff Kaplan: "With the current economic downturn pressuring enterprises to freeze capital spending on software and quickly find ways to lower spending on IT, the move to SaaS has never been more compelling. This has accelerated already rapid SaaS adoption in an effort to save costs and reduce IT spending."

I'm sure more to come....

More on IdM in the Economic Downturn

Over lunch with an NYC VC, conversations inevitably turned to the economy and it's impact on startups. A telling takeaway was that cost cutting in IT budgets is going to be deeper than previously expected. Gartner and Forrester until just last week stated that IT spend will grow less than expected (Gartner placed it at at 2.3% and Forrester at 6.1%). On the other hand, the gentleman I had lunch with stated that those predictions will most likely be changed dramatically, and that the number on the street is that cuts will be in the ballpark of 20%. Now given that typically 65% of IT budgets are dedicated to maintenance and upkeep, that leaves about 15% on the table for new initiatives. Ouch is right!

In my opinion, if IdM projects are to survive these cuts, it has to be positioned around 2 areas simultaneously: 1. The project has to be linked to core business and 2. Cost cutting capabilities. If the project can't rally around both, it's probably a gonner.

A good case in point is how salesforce.com made it through the 2000-01 scenario. It provided an easier way to do CRM (critical to core business) in a more cost effective way.

So the question is...who's going to be the salesforce.com of the identity world? Or from a project perspective, which initiatives will be able to survive?

A few random thoughts: I like SSO/Context Management in healthcare. Great impact on the business (especially for clinicians) and cuts cost. Password Management is pretty good, except impact on the business in most cases is negligible. The same goes for provisioning and role projects, although a better case could be made for impact on core business. Unfortunately, I think the new kid on the block, privileged access management is in trouble because of its positioning as primarily a security play. I'm still noodling this, but I'm sure this scenario will bring about some interesting innovations in our space in the coming year. Nonetheless, the forecast is pretty cloudy from where I stand.

Selling Identity in an Economic Downturn

Rough week. And it's Tuesday. In the wake of the current financial crisis, I've received 3 phone calls in the past 3 days from potential customers (who were almost surely moving forward with an Identity Management deployment) to tell me that the project is in serious jeopardy. All three happen to be in the healthcare sector. One of them was given a mandate to cut $1m from his budget. Another simply stated that all new initiatives that haven't been inked yet are frozen indefinitely. The third stated that their organization's revenues were deeply impacted because of cuts in Medicare/Medicaid, and any and all projects not directly related to core business will be cut.

I've been able to position the projects to be possibly salvaged by quickly shifting drivers from compliance to ROI and cost avoidance opportunities. Thank God we're in an industry that supports multiple and varied drivers! I think that trying to sell Identity from a compliance and security angle in this environment is just a lost cause, which will probably impact the types of technologies that will be deployed. Any thoughts on other business/tech drivers that might be used? Which types of identity projects will live and which will die?

How to Make a Better Identity Management POC

Mike Trachta responded to my previous post about lackluster POCs by highlighting the difficulty posed to SIs to live up to the fantastic show presented by the POC folks.

"...the customer remembers more about the POC than you think. They remember how pretty the screens were. They remember how seamlessly all the pieces fit together, and how quickly each task executes. What they don’t realize is that all of the data is massaged and simplified. Of course the POC could do these things! It has 3 users with 4 roles to choose from, and doesn’t include any of the “exceptions” often found in the customer’s environment. When it comes time to actually implement this feature with 30,000 users things can (and do) get quite a bit more complex."

Jeff Bohren put together an eloquent post as well, pointing to his experience as the developer in the background helping out both the POC folk, as well as the SI who has to make this happen for real. It's a great read and provides insight from both ends of the spectrum.

I have a few suggestions that might make your IdM POCs a little better. So here they are:

1. Couch your immediate goals in the context of a larger Identity Management initiative that ties it to your business objectives. Jeff already hit on this point in his post, "Instead of doing a POC of who has 'The Most Magical Bullet', enterprise would be better suited to craft a long term IdM strategy and chose a vendor whose product best aligns with it." This approach voids the notion that phase 1 of the project has to cover everything under the sun. A fantastic way to do this is to engage an SI that understands the game, and can walk you through an Identity Management workshop that speaks to both your business and technical objectives.

2. From your workshop findings, carve out a Phase 1 of the project that is attainable - the best way to do that is to write up a handful of detailed use cases that boils the expected deliverables down to non-technical language.

3. Highlight the top X number of use cases to focus on for a POC. Keep it limited (but representative) of your expected project deliverables. Identify the vendors who might be able to respond, and request a technical architecture document outlining their approach to solving the use cases you have identified and have a Q&A session with them. Filter out the vendors who don't make the cut (yes, I know that's a loaded sentence), and identify the top 1 or 2.

4. Prepare a POC lab. (Another loaded sentence).

5. Bring the vendors in, but don't allow them to touch anything! OK, this suggestion point might be a bit much but I suggest that, as much as possible, have the vendor's experts sit on their hands, next to your techies while your techies drive. If the vendor whips out a canned script, your guys will know it (and document it in the findings). If the vendor has to make a nasty directory schema change, your techies will know it. If the vendor has an ugly hack that inserts pages of code into the presentation layer of the "ultra configurable identity app", your techies will know it.

6. Have a structured way to present the findings.


While I know that the approach above requires a lot of background knowledge and support, it just seems to be a much more valuable experience that actually tells you something that a demo can't. If help is needed, supplement the team with an SI that has strong experience in the space. Either that, or save everyone time and effort and just make your decision based on sales demos and references.

Why (most) Identity Management POCs Suck

For those unaware, POC is an acronym for "Proof of Concept", and consists of a client requesting a vendor to bring their software in to demonstrate ("prove") that their software can perform in their environment as promised ("concept"). The engagement usually lasts for a few days to a week, and typically the vendor foots the bill (if the potential deal is large enough). Most often, POCs are borne out of a conversation between a client and an industry analyst who completed a 2 hour identity management market briefing, concluding that it would be a good idea for the client to host a POC. A few vendors are selected to strut their stuff, and after reviewing which vendor did a better job, a winner is hailed and ultimately awarded the contract.
After being involved in one too many POCs, I've come to the following conclusion: IdM POCs suck. Usually. And here are a few reasons/scenarios that explain why:

1. A typical POC is just a glorified demo. So, wisdom states that if the vendor is integrating their software with your target apps, then it's not just a demo, but undeniable evidence that their software is good for you and your organization. That is both true and false. Just because software can be made to "seem" to work with your apps is not evidence that the integration is robust or production ready. Hacks are very common in POCs, and a lot of what is demo'd at the end of the POC is a lot of smoke and mirrors and doesn't prove that what was completed is production ready, or more importantly, can ever be production ready.

2. The success of the post-POC demo is highly dependent on 2 individuals on the vendor team: the Sales Engineer (the guy who duck-taped together the POC) and the POC-demo-guy. The vendor that has the best duo typically wins the deal, which may not reflect the best software solution for your environment. A good SE can make crappy software work (with his arsenal of scripts and tricks), and a good POC-demo-guy can bedazzle almost any audience. On the other hand, a bad SE can make good software break, and a bad POC-demo-guy can put a lively audience to sleep.

3. A POC is typical technology focused. Most IdM deployments are business process centric. When decisions are made based on the number of out-of-the-box connectors or the long list of supported standards without considering how it all applies to your specific set of business processes, the wrong vendor can be selected.

Well, I'm sure there are more reasons, but I'll leave it at that for now.
But the picture isn't that bleak. There are ways around the problems above, and exciting approaches that will not only make POCs not not suck, but actually make them effective and useful...a topic for another blog entry.

Managed Identity Services - OOOH, A SURVEY!

Ian's done it again. I've come to admire his style of blogging-outside-of-the-box.
Over the past months, a number of bloggers have commented on the notion of managed services in the world of identity management, and speculations around customer attitudes towards it due to security/privacy concerns, as well as from a process perspective. Ian decided to cut through all of the speculation, and put together a survey on managed identity services aimed towards clients, in order to capture a sampling of actual client feedback. Brilliant.
I immediately saw the value in this, and decided to reach out to Ian in order to see how Identropy could help out. Ultimately, we decided that a simple giveaway might spur user participation, but agreed on keeping the marketing mumbo jumbo to a minimum at the same time. This is about getting clients involved in our discussions, reporting on the findings and hopefully initiating more practical conversations around the topic in the community. I'm very excited about working with Ian, and he has turned out a very well put together survey.

A last note: This survey is geared towards actual customers rather than vendors or integrators. If you are in touch with customers who have an identity infrastructure in place, please forward them this link ( http://www.surveygizmo.com/s/68286/ian-yips-managed-identity-services-survey ) if they want to participate. They do NOT have to provide any personal information if they do not want to. Our only interest is assessing attitudes out in the marketplace towards this notion, and the wider the participation, the better the data Ian gets to report on.

Is WAM Complex?

Jeff Bohren responded to my post on Symplified yesterday, stating that although he agreed that most WAM solutions are complex, the OpenNetwork/BMC (now Symphony) solution doesn't fit that mold.
Admittedly, I don't have experience with the BMC solution, but Jeff makes a good case for its simplicity:

(it) could be deployed with nothing more than AD and access control agents on each web server. The access control agents served as both a PEP and PDP. No policy servers, APIs, or proxy servers required. The same accounts used for intranet login could be used for web access control and the policies could be expressed in terms of AD security groups.

A few questions, (pardon my ignorance). What if apps want to query policy information (for example, does this user have access to that resource)? Do they query AD directly? Might that not get complicated if there are a complex array of rules to crunch through? Some environments seek a web services based API rather than the (typical) java API. Who stands that up? What about the admin console? Who manages that? Also, doesn't agent management become a headache? Keeping up with different web server versions, and handling upgrades could cause admin overhead. I agree that the solution sounds easier, but for an admin with a mediocre skill set, it seems that it would prove challenging. I'd love to hear your thoughts/real life experiences.

My experience falls more in the cleartrust/siteminder/oam realm, and clients constantly complain about maintenance. Here is an example. Some years back, a company sought an access management solution, found one, bought it and contracted a consulting firm to implement it. They did, and left them with documentation just as any good firm would. Years later, policies required updating, certs started expiring, web services API was requested, redundancy was removed/neglected, and general failures became more frequent. I rummaged through old docs, and found a diagram from existing documentation (sanitized).
Besides the components shown, there was a BEA server that hosted the management interface, as well as a web services wrapper for the WAM API, and of course, agents on each web server. The infrastructure also included a CA used exclusively for the WAM environment (don't ask), and was therefore considered part of the same admin burden.
The client wasn't especially tech savvy, and explaining the difference between an authorization server, dispatcher, entitlements server, and how to ensure they were appropriately set up in failover mode, and how to troubleshoot when specific problems arose wasn't particularly easy. Most importantly, it wasn't the client's "fault" - they had a host of other applications they were tagged with managing (including a metadirectory, provisioning solution, security event management, directory services, etc.), and handling a WAM solution was just another component waiting to be neglected.
I don't think that this is an unusual scenario. Now even if the complexity level were cut in half, it's still quite a bit of infrastructure to handle for an admin staff that is already overburdened. Now imagine someone offers all of this in a hosted model, and a pretty appliance (or 2) in your infrastructure that you really don't have to worry about managing...

My Latest IdM Crush

At DIDW, I got a chance to sit down and chat with Eric Olden, CEO of Symplified. Symplified brings Web Access Management into the SaaS world. Their approach resonated with me immediately.
A few clients we had just been dealing with over the past weeks had "fires" that needed containing. For one client, after 48 hours of dispatching consultants, phone calls to support, and just hard core technical work, all was well...for the time being. Soon after, another client had a similar situation. Things were going down all over the place, and no one knew why. After significant investigative work, the culprits were found and dealt with. But the real culprit wasn't a person or an inopportune config change. The real underlying problem was a complex (and perhaps antiquated) IdM infrastructure put in place by a team of consultants years ago coupled with an IT team that didn't provide the identity management infrastructure the appropriate level of care and feeding. Unfortunately, this toxic combination is not uncommon in mid market enterprises.
Enter Symplified. Anyone who knows idenity knows that WAM infrastructures are rather complex. Agents, proxy servers, APIs, Policy Servers and a host of other moving parts. Eric walked me through Symplified's approach to "symplifying" (get it? i just did) this complexity. Think of a proxy based WAM architecture. Symplified provides an "identity router", which is an appliance dropped in the client's infrastructure that acts as the proxy. All traffic to protected apps get routed through the identity router, which acts as the policy decision point as well as the policy enforcement point. Identity data can be consumed from your existing identity stores. For example, you could have the router point to AD to pick up users, but policy information is stored in the router itself. So where does the SaaS component fit in? The admin interface is hosted in Symplified's SAS 70 Type II data center and allows access policies to be defined. Once completed, the policies can be pushed down to the identity router in the client environment. Symplified also provides a slick option to deliver the identity router as a virtual appliance. They call it the GTV form factor, and it can run in an existing ESX environment.

The last word: the client has less infrastructure to manage. Compare this to the number of components in your typical agent based WAM solution, and the value Symplified is providing should be pretty obvious.

The VDS Use Case

I attended Radiant Logic's workshop today at DIDW. An interesting tidbit that they shared with us was that a whopping 90% of field usage of virtual directories today are around solving authentication problems.
Given all the wonderful use cases that virtual directories solve, I'm a bit surprised the lopsided real world usage. For folks in this space, is this what you're seeing as well?

Words of Wisdom: Sell Early

Phil Windley has a fantastic post giving good startup advice. The basic idea is, don't wait to sell your product/service. Never wait until its "ready", because chances are, you'll never think its really ready. An eye opening point he makes is that selling to customers and speaking with them helped him up his pitch-game more than talking to VCs and raising capital.

As a consequence of all this, I wish we’d been positioned to start selling well before we started raising money. Unfortunately, because of various timing issues and our own understanding, things didn’t work out that way. If I do this again, I’ll start selling much earlier.

A question that pops into my head: is there a point where you are just too raw to go out there with your product. I suppose there is an inverse relationship between how ready your app is and the patience (and free-time) of your first customers. Anyhow, keep 'em coming, Phil.

The Worst IdM Product Review Article. Ever.

A product review should...umm...review the product. Talk about the features, where it shines, where it doesn't, etc. This one in specific is just really, really bad. (I'm not saying anything against the product, just the review.) Here are a few nuggets:

The P Synch package performs the single sign-on component of identity management. The ID Synch package is primarily a web-based package that uses SSL for protecting the data during transmission.

...now that is just wrong info.

The web-based configuration of the M-Tech product suites felt intuitive and easy to understand. For example, each of the major headings in the menus reflected commonly used terms in the field of identity management.

...?

The PDF files are large and a more advanced search function could also help speed the reader’s search to find the correct passage.

...are you listening adobe?

Apologies for the sarcasm this morning.

More on Virtual Directory Pervasiveness

Nishant and Clayton Donley have written some solid responses to my last post (and Jeff Bohren's post) here, here and here. (You've gotta love the responsiveness of the Oracle folks!)
I'd love to hear their thoughts regarding apps that seek to leverage some of the benefits from "advanced integration" with AD, as Jackson Shaw mentions in an old post (please don't ask me to explain them out)...

"...But I'm really interested in advanced integration with Active Directory like "serverless bind", Group Policy integration, the ability to modify permissions on resources...automatic failover in an Active Directory environment without any additional hardware or software..."

The comments section of the post is pretty interesting, given our current discussion. But putting that aside, would it be possible to leverage some of these AD specific capabilities, but benefit from abstraction using a virtual directory at the same time? Perhaps something like a virtual directory plug-in that allows an app to leverage some of the AD specific capabilities mentioned above, but still allow a COTS app that expects to see data in a specific way (e.g. shallow trees) to leverage a virtual directory to ensure that data is represented appropriately?

Pervasiveness of Virtual Directories?

Does anyone know what the actual market penetration of virtual directories is? How many mid to large sized organizations actually use a virtual directory in their infrastructure? With all the debate on virtual directory vs. metadirectory recently in the blogosphere, one of Nishant's comments caught me off guard, when he was responding to Matt's statement that there "...has been a ground swell of apps that directly support Active Directory as the user store":

"And how are more applications supporting AD anyway? A lot of that has to do with the emergence of Virtual Directory solutions. A number of applications in the Oracle stable today claim to support AD as the identity store. The mechanism for all these is moving to Virtual Directory NOT because Oracle has a Virtual Directory product, but because maintaining adapters/connectors/plugins and what have you for all LDAP variants is a colossal nightmare."

Woah...that is a a huge claim there. Is it possible that the "groundwell of apps that directory support Active Directory" is due to "emergence of Virtual Directory solutions"?
Although I usually find what Nishant has to say as thought provoking, and the fact that every organization should be running a virtual directory solution is pretty evident by now, that claim sounds pretty absurd to me. What are the actual market numbers of the virtual directory solutions in production? (I know Radicati had some numbers around this, although I haven't gotten my hands on the paper yet.) Now compare that to the number of companies running AD. Even without the numbers, I think that Nishant is way off here. App support for AD is due to its undeniable pervasiveness, not because of the emergence of virtual directory technology.

Jeff Bohren has some interesting comments on the same post. Check it out.