Blog

Approaches to IDaaS for Enterprise Identity Management

Happy New Year 2010 to all. Best wishes in the year that just starts.

I will start this year's first posting by acknowledging Burton Group's (just acquired by Gartner) Bob Blakley September 30^th, 2009 vantage point titled: "2010 Identity and Privacy Strategies Planning Guide: A Market in Transformation", which has been an excellent reference in helping me shape some of my thoughts for this article. I think it is a great document with great insights on current trends in identity management.

My prior blog posting introduced a definition for Identity as a Service (IDaaS), setting the stage for this posting, which discusses models for deploying IDaaS, from the perspective of the entity that consumes the Identity service, in this case an organization (as opposed to an individual). The assumption will be that the entity and the service provider are two separate organizations, and moreover, two separate legal entities. In a way, this perspective is no other than the Enterprise identity management.

In addition, for this discussion, we will try not differentiating the kind of Identity services being provided (provisioning, registration, authentication, etc.), or which user population within the entity it is intended (i.e. employees, contractors, suppliers, customers or business partners). The idea is that the approaches should be applicable to all of them.

Defining Managed IDaaS

In this article's context, Managed IDaaS is an approach to IDaaS in which the entity employs one or more separate legal entities as service providers. The service provider is contractually bound to specific terms that define how the service is performed, and it governs its adherence to these terms through mutually agreed and measurable service level agreements (SLAs). In other words, Managed IDaaS, is the scenario in which an organization consumes Identity services from an external service provider. These services can range from operating a provisioning infrastructure, to verifying the identity of a person, to providing strong authentication or federated authentication credentials, to managing passwords;  and they can be provided both internally (i.e. within the organizations Intranet) or externally (i.e. through an extranet portal), and can physically reside on-premise or in the cloud, or a combination thereof.

Two main variants of Managed IDaaS are common today, and as Gartner forecasted, they should trend upwards in adoption within the next two years. They are mainly determined by who is responsible for and who owns what part of the Identity service infrastructure, which in many cases correlates directly to where the infrastructure component actually resides:

• Cloud IDaaS - where the service provider owns and operates the entire Identity service infrastructure, and provides it to the entity in a pure SaaS manner, without any sort of footprint or backend integration with the entity's IT infrastructure. Identity information is exchanged in an offline (manual or batched) manner.
• Co-sourced IDaaS - using Wikipedia's definition of co-sourcing, this is an approach in which the Identity service interacts directly or through some technical footprint with the entity's IT backend infrastructure (directories, repositories and other target systems). The entity and the service provider have a shared responsibility for building and operating the Identity service, the balance of this responsibility determines distinct scenarios, which we will focus in more detail in this article.

To better understand Managed IDaaS, it is useful to decompose it into building blocks. The diagram on the left provides a high-level structure for an Identity service, made up by three main functional areas:

Consumable Identity Service - this is the end point of the service, which interacts and integrates with the consuming entity, whether an end user interacting through a web UI or an application or repository that exchanges information with the service. This is the area in which the specific logic and functionality provided by the service is actually "wired".

Identity Management Stack - this is the middleware of the service; the software modules that provide the basic functionality to manage and process identity information.  The diagram shows an arbitrary sample of the software components that make up the identity management stack. It is not mean to be an exhaustive list, but rather a representative sample. Nishant Kaushik has done a great job explaining the identity services framework, which instantiate the identity management stack.

IT Platform - this is the technical backbone of the service. The basic IT computing infrastructure that is not specific to identity management, but generic to any IT service.

These three basic functional areas are useful in explaining how variants of a Managed IDaaS come to life, particularly co-sourced IDaaS.

Co-Sourced IDaaS

It is a Managed IDaaS variant in which the Identity service's consumable service interacts directly with backend (or back office) IT infrastructure managed and operated by the entity. And more importantly, one in which the entity and service provider enter into a partnership in which they share some of the responsibility in building, hosting or operating the Identity service.

The diagram below illustrates four common co-sourced IDaaS scenarios, which we'll discuss next. I admit that while I have spent time thinking about these scenarios, I do not think I have articulated them in a way that clearly delineates their boundaries (if any), so I am hopeful that by venting them out, I will get very good thoughts from you.

1. All on-premise, provider operated - when the entity owns the identity management stack used to build the service, as well as the actual IT platform; and the Identity service is hosted on the entity's premise where it integrates directly with the entity's backend IT systems in the Intranet. The service provider is responsible for configuring and operating the consumable Identity service. This model is a more "traditional" Enterprise identity management deployment approach, where an organization procures the entire IT stack, and hires an external integrator to build, and possibly operate the Identity service, according to defined requirements. The organization and the integrator establish service agreements which govern roles, responsibilities, response times, escalation procedures and son on.
2. Provider hosted and operated - where the service provider hosts and runs the entire Identity service, and integrates directly with the entity's consuming backend IT systems. This scenario is seen often at organizations that outsource their IT infrastructure and operations to an IT outsourcing service provider, and the Identity services are collocated and dedicated to the organization. From a connectivity perspective, the Identity services are typically accessed via dedicated lines (private clouds, private VPN). In this scenario, the service provider is often responsible for procuring and operating the consumable Identity service, the identity management stack and the IT platform. The outsourcing service provider and the organization establish service level agreements as well as licensing agreements which ensure that the organization is entitled to use the technology infrastructure require for the Identity service. This scenario is typically single tenant for both the consumable Identity service and the identity management stack functional areas.
3. Hybrid: on-premise and in the cloud - where the service provider hosts and runs the entire Identity service in an environment hosted in the cloud, and requires some technology footprint to be deployed on-premise at the entity's IT environment to effect the integration with its backend IT systems. The scenario is one where the organization "leases" the Identity service from the service provider, which includes the use of the on-premise footprint - say a virtual or physical appliance, and access to the actual Identity service which is hosted in the cloud. From a connectivity standpoint, the appliance provides secure communication through the public Internet, and it may also provide caching and queuing to increase the reliability and responsiveness of the service. The service provider owns and runs the Identity service backbone and may adopt a multi-tenant model. The organization and provider agree to service SLAs, which will also govern how the on-premise footprint is operated.
4. All in the cloud - where the service provider hosts and runs the entire Identity service in an environment hosted in the cloud and it integrates with the entity's backend IT systems without requiring additional technical footprint, leverage secure, open standards-based interfaces over the public Internet. In this case, the organization "leases" the Identity service from the service provider, and configures its backend IT systems to communicate directly with the service. The provider owns and runs the Identity service backbone and will most likely adopt a multi-tenant model. The organization and service provider agree to SLAs under an Application Service Provider model.

In future postings, we will discuss considerations and advantages of the co-sourced IDaaS model. In the meantime, I look forward to your comments.

SaaS Provisioning: It's About the Connectors!

Last week, Identropy launched IC2, our Identity Management gateway for the cloud.  We also blogged about the product and how it empowers current User Provisioning Systems to seamlessly connect into IC2 to manage the onboarding, offboarding and orphan account reporting for SaaS applications.

The rationale for Identropy developing IC2 centers around one simple question: What is the easiest way for a corporation to manage the digital identities of users for the multiple hosted applications that are not within their enterprise control? 

Although the move towards SaaS applications is a fundamental paradigm shift from managing enterprise applications, the core identity management problem surrounding user provisioning remains the same.  After conversations with our clients, it was apparent that the same business processes that govern the onboarding and offboarding processes for enterprise applications quite readily map to the same processes for SaaS applications. Similarly, the same role management infrastructure that is utilized for internal applications could easily serve up roles for SaaS applications.  Couple this with the following statistic from Gartner's Magic Quadrant for User Provisioning):

"...as of mid 2008, approximately 20% to 25% of midsize to large enterprises worldwide, across all industries and sectors, have implemented some form of user provisioning. An additional 20% to 25% are evaluating potential solutions..."

Conclusion? SaaS Provisioning for most organizations is all about the "connectors", or the little pieces of software that connect the provisioning workflow engine to enterprise systems like Active Directory, Oracle databases, and all the other applications in your environment.  That's where IC2 (Identity Connector to the Cloud) comes in.  It's a connector gateway that speaks an industry standard known as SPML.  By using SPML, we could connect your existing provisioning server to IC2.  On the backend, IC2 connects to your SaaS applications in the cloud.  The net result is the easiest way (think days, not months) for your organization's existing provisioning server to extend out user management to cloud applications.

More Thoughts on Identity Management Cloud Vendors

Matt Flynn has put together a list of vendors in the Identity & Access Management space who have a "cloud offering," and Identropy was included on the list for our IC2 offering.  Matt described IC2 as:

Identropy IC2 - Identity and Access Management solution for SaaS applications. Leverages existing Identity infrastructure and work flow to provision accounts to cloud applications.

Here are my 2 cents: IC2 has less to do with Access Management (or traditional WAM) and more to do with Provisioning.  In simple terms, it's a way for companies that already have a provisioning system in place that manages users for internal applications, to just plug into IC2 to extend management to SaaS applications (or technically speaking, any web application).  So basically - as of today, IC2 is geared towards customers that already have Identity Management software in place.

Other vendors, such as Conformity (from what I know, Conformity, please keep me honest) have taken a different approach. They have a complete provisioning system in the cloud, including workflow, connectors, policy engine, roles, etc.   So this approach puts them in the position of going head to head with existing IdM vendors, or target SMB clients who are searching for a provisioning system, but don't want the administrative overhead.

Identropy has take a different approach to the problem.  By speaking to our existing customers (who all have provisioning systems in place, so our market research is biased! :), we saw a need for extending out user management (onboarding, offboarding, etc.) to SaaS applications.  These customers would much rather leverage the infrastructure they spent a million dollars building rather than rip and replace the solution for a total cloud offering for Saas Provisioning and User Management.

An SPML gateway to the cloud seemed like the natural solution.  It abstracts the technical details of creating custom connectors from customers.   They also don't have to manage the connector, and it gets them up and running in no time, given that we already have a connector in place for the SaaS application in question.

Oracle Has Tough Decisions, Good Options

I promised myself that I wouldn't write about the acquisition of SUN by Oracle but after reading all of the different blog posts that I read including Matt Pollicove's IdM Thoughtplace and Jackson Shaw's blogs...amongst others and what I read is that it could take months before this even affects the identity management product but here's my take on Oracle and where things could end up.

1.The best companies become even greater by the decisions that they make. Kind of reminds me of teams like the Raiders and Lions on NFL Draft Day...they draft pretty high every year but they just can't make those amazing picks turn into anything substantial and teams like New England give up early picks and just make good decisions. Talk about getting a deal...oops...I mean a steal. For the average person $7.4 Billion sounds like a ton of money but thinking that Larry Ellison feels he will squeeze $1.5 Billion in profit out of that acquisition this year and $2 Billion out of it next year shows that this was not just a knee jerk reaction to IBM wanting to make this same purchase.

 

2. 2008 Gartner Magic Quadrant for Provisioning

 

Gartner's 2008 Magic Quadrant showed that SUN and Oracle were tops in the provisioning space. This acquisition would leave Oracle firmly placed at the top with IBM Tivoli.

3. According the 2008 Gartner Magic Quadrant Report, Oracle had 11.9% of the market share and SUN had 11.8%. The closest competitor, CA, had 14.6% market share which was also down 6.3% from 2006. Viewing this simplistically, we can say that Oracle now has almost 24% of the Provisioning market.

4. Can the many new advancements in the SUN product such as tying their identity software to Google Apps Premier and Amazon's Cloud platform save them? Actually I feel that Oracle instantly becomes a leader in the cloud computing space. It may take the need to make SUN/Oracle's Cloud Computing Platform less open source and back it up with Oracle's Database versus MySQL to take it to the Enterprise level.

There are many more reasons that this acquisition could make Oracle a winner such as OID/LDAP, JAVA and others.

 

Whats your take?

Identity Management Solutions 101: IaaS (Integration as a Service)

You know that something is new when it is listed in Wikipedia but still is not clearly defined.

 

Wikipedia says, “The origin of the terminology "Integration as a Service" is not clearly defined. However "IaaS" is becoming widely used in reference to Software as a Service.”

 

Companies like Bluewolf and Identropy are paving the way towards defining and implementing IaaS.

 

"Integration software has become a commodity," said Lou Fox, CTO of Bluewolf.  "We focus on making sure you are successful with integration by wrapping in monitoring, maintenance, enhancements and consulting into our Integration-as-a-Service offering so that clients can get a complete solution, not just a tool."

 

Ash Motiwala, CTO of Identropy has said, “Identity Management lends itself perfectly for Integration as a Service since the true goal of bringing these products in to any environment is reducing costs. The next way to continue reducing those operating costs is by providing support on those integrated systems.”

 

In my opinion, technology has progressed from the normal implementations, to the much lesser known Identity as a Service (which was popular about a year ago but really never caught on because it is what all implementers were already doing) to Integration as a Service (which provides the greatest value and return on investment for an organization).

 

So if I were to define IaaS, I would define it as a solution that combines consulting services and implementation of identity solutions coupled with a proactively managed and integrated support service.

 

In future posts we will dive further into Identropy’s IaaS solution iMIS (Identropy Managed Identity Service) http://www.Identropy.com/Products_iMIS/.

 

Identity Management Solutions 101: User Provisioning

So, you're an IT Manager and need the low down on a new buzzword in the realm of Identity Management, and you need it quick...You've come to the right place! This series is designed especially for you. 

This entry is about User Provisioning. Enjoy!

 If you need more details on this and other disciplines in the world of Identity Management, or you'd like to get some other folks from your staff to join in on the fun, you might be interested in an on-site Identity Management Workshop.

 

Alias:	Automated Provisioning, Account Provisioning, Provisioning
Function:	Simply put, it's a fancy term for creating accounts in various systems. Typically, it's for creating user accounts, but can also be used to create any digital account, including computer accounts, badge accounts, etc.
Misc.Facts:	User Provisioning is by far the most popular component of the Identity Management stack. According to Gartner, almost 2/3rds of Identity Management projects are in fact User Provisioning projects.
Business Benefits:	Huge cost-avoidance opportunities Great tool to replicate/optimize business processes Out of the box connectors to target systems Flexible framework for targets without OOB connectors
Use Cases:	Employee onboarding/offboarding to all targets Contractor onboarding Employee self-service capabilities to update their own profile Bulk offboarding/deprovisioning Emergency offboarding/deprovisioning Approvals based onboarding per target system
High Level Architecture:	Typically, there is a server that stores the business logic, and connectors to various target systems that typically reside on the same box. Some legacy systems may require an agent to be stored on the target systems themselves. Also, there is a datastore (some vendors provide their own, others utilize AD or an existing data store).
Caveats:	Don't understate the business process analysis part of this project. It takes longer than you expect, but can make all the difference in the world for the success of your project!