Blog

What's Your Identity Management Consulting Firm Hiding?

Based on my experience, most Identity and Access Management (IAM) consultancies - even the "Big 4" - tend to keep clients in the dark.  Due to the complexity of IAM projects and multiple stakeholders, it's easier to hide the gory details of a project gone wrong until its too late.  Unfortunately, this approach has given the IAM services industry a black eye. 

As an organization, we are big believers in transparency for our clients. Transparency not only aids teams to work through project curve balls, but it also empowers the teams to spot risks collectively in order to prevent them from ocurring in the first place. 

As I write this post, Identropy is now in its' fourth month of everyday usage of our Project Management Information System (PMIS). When I initially joined the team, we were using a mix of disparate tools: SharePoint for document management, a Time Tracking application, MS Project and Excel files for resource and expense management. Individually considered, our disparate parts did what they were supposed to, although none of these tools really talked to eachother.

In our quest for increasing transparency for both ourselves and our clients, the lack of integration of our various systems caused significant overhead for our PMs.  They had to spend time to create the level of transparency we wanted our clients to have.  In order to address this inefficiency, we decided to look for a better solution: a single place for our customers to have total visibility into our IAM project progress, cost, risks, documents, etc.

Simply stated, Identity & Access Management projects require strong and active project management. And while technology is never a good substitute for solid processes, our experience is that an effective Project Management Information System (PMIS) can put your IAM project on steroids by increasing transparency into the state of the project.

Since I had experience using an Enterprise wide PMIS tool, I led the effort of defining our requirements and identifying likely candidate solutions. In one of my earlier blog postings, I wrote about the importance of a good Requirements Traceability Matrix. So, the first thing I did was begin working with my team to start evaluating just what requirements we really had for a PMIS. I constructed an RTM and began consolidating requirements into various components such as "Financial Tracking" "Scheduling", "Calendars", etc...

Our key criterion boiled down to 3 major points:

1. Proper Task Sequencing: In a typical IDM project, one task must drive another. Without this, you simply have a glorified to-do list, which any IDM PM knows is the kiss-of-death for the project.
2. SaaS Based Solution: Identropy is a zero IT footprint company. That means, unless absolutely necessary, we don't have anything on our premises.
3. Integrated Time Tracking, Doc and Expense Management: By integrating all of these components, we would have greater insight into projects, resource utilization, and how much we were spending.

The fun part in performing requirements assessments is discerning marketing hype from reality. (We have a lot of experience doing this for our clients when selecting an IAM platform!). The finalists demonstrated complete packages in terms of polish, solution feature sets and, to some degree, cost flexibility. Ultimately, Identropy chose Clarizen to partner with to provide our PMIS solution, for pretty much the same reason most organizations select Identropy as a partner. While the Clarizen solution is top-notch, the overriding-factor was and still is the people and their philosophy. From our account rep (Jacqueline, call her if you need a PMIS!) to our product support folks (Gil and Josh), it would be almost impossible to find people who truly care as much about honesty and earning a client's business as they do.

The impact of the overall solution has been great. Our clients have welcomed the increased visibility, which has allowed us to forge a closer partnership with them. It has increased communication between consultants, resulting in fantastic conversations regarding our implementation methodology. Lastly, it has served as a differentiator for us in front of potential clients that shows the practical angle of our corporate philosophy regarding transparency.

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.

Defining Identity as a Service

In the midst of the holiday season, and with the anticipation and emotion that comes with the end of the year approaching, I have decided to write my first blog - an early new year's resolution perhaps. I must state that I have resisted the urge to blog for the last three years of my career for two reasons: on one end, I feared starting to blog and then dropping off and being inconsistent (just like I have been every time I started at the gym), on the other end, I dreaded becoming addicted to blogging and seeing it impact other priorities. But let's just say that I am resolved to give this a good try by sticking to some basic rules: keep the content lean but meaty, keep a constant blogging frequency, and try to be as interactive as feasible - sounds simple. Let's see how I fare (maybe I will also get in shape in the process)...

What is Identity as a Service (IDaaS)?

2009 has seen an increased interest and focus in a relatively new topic in identity management "Identity as a Service (IDaaS)", but just like any upcoming trend, it tends to be understood differently, explained differently and used differently depending on context. Burton Group provides a very concrete definition that focuses on the outsourcing of identity management, such as authentication, provisioning and attributes services. Dave Kearns has covered this topic extensively as well, under the context of "Externalizing Identity into the Cloud". My friend Nishant Kaushik defined the term in 2007 as "the notion of making identity management capabilities available as an infrastructure service to all applications in a SOA environment".

In a way, this reminds of the late 90's when the term identity management was making its foray in the world (yes I admit that I was an identity guy back then - lucky me!), and everyone had its own definition and everybody from Dun & Bradstreet to Access360 to Oblix provided identity management. And I think that the term is still misinterpreted today, though not entirely misunderstood, just like any normal teenager at this age.

So, one would wonder: why propose yet another definition for IDaaS? Well, I encourage you to keep on reading, as I think I will make my point clear, and hope to ignite good comments and discussion along the way.

With that: what is IDaaS? It is an approach to digital identity management in which an entity (organization or individual) relies on a service provider to make use of a specific functionality that allows the entity to perform an electronic transaction which requires identity data managed by the service provider. In this context, functionality includes but is not limited to registration, identity verification, authentication, attributes and their lifecycle management, federation, risk and activity monitoring, roles and entitlement management, provisioning and reporting. 

The relevance, or perhaps novelty, of this definition, is that it focuses on the interaction of four elements: the entity, the service provider (which could be the entity in some cases), the specific functionality and the electronic transaction.

The Context of IDaaS

I believe that IDaaS as a concept has seen increased interest and coverage this year, in big part due to the impact of the global economic challenges which are forcing organizations to revisit its models for adopting and implementing IT initiatives that require identity management, as well as an increased emphasis in regulatory compliance and privacy awareness.

In any case, there are some important considerations regarding the definition of IDaaS that I would like to point out:

• It is not meant to be just a technical definition. And while the definition does not conflict (I would hope) with a technical definition or architectural approaches, it is important to think about IDaaS from a legal and jurisdictional standpoint as well. In this context, the definition of ownership, responsibilities and liabilities is significant to all parties involved in IDaaS. Tom Smedinghoff, a well-known contributor to the identity management industry, has created great content and led several initiatives that are bringing the legal aspect of digital identity management at par with its technical evolution, all of which is relevant to adopting IDaaS.
• The strength, rigorousness and thoroughness by which IDaaS is provided, should be measurable in an objective and demonstrable way, such that they can convey a specific level of confidence or assurance to the parties. This in turn will translate to a risk mitigation level that the parties can agree to be sufficient for a specific type of transaction. The Identity Assurance Certification Program run by the Kantara Initiative provides a very concrete vehicle to achieving this measurement.
• IDaaS should not be restricted or misconstrued as only applying to "cloud" based models. While IDaaS is particularly relevant for cloud-based services, IDaaS could also apply to on-premise models. In fact, I argue that it is in this area where the definition is most beneficial, as organizations can view its internally-facing (and possibly internally deployed) identity management infrastructure as identity services, allowing the demarcation of service scope and boundaries that will make outsourced, on-premise, cloud-based models or any combination therein more concrete, and easier valuate in business terms. The intention is not to confuse IDaaS with "Cloud Identity" or with "outsourced identity management", since the term could apply to all these cases.
• The concept should also not be restricted to enterprise IDaaS vs. consumer IDaaS, since the notion is basically the same. Evidently, the actors, the types of transactions, the levels of sensitivity in them, and other elements will vary greatly from enterprise to consumer environments, but the notion of how digital identity management applies to each could be thought of in the context of IDaaS.

Why is this even relevant?

My motivation to introduce this definition at this point is to attempt to set a common understanding of terms, allowing us to better understand the new trends, services and paradigms in identity management that are unraveling before our eyes. As I believe that a significant shift in identity management from a monolithic model to a true services-based infrastructure, has been at play for the past 2 years, with noticeable effects only in the past 6 months.

With this shift has come some degree of confusion in the industry among identity management in the context of cloud-based services (i.e. SaaS, Infrastructure as a service), identity federation (claims or assertion based) and the more traditional enterprise deployment models, to a point where they are at times seen as independent or separate; causing people to think of IDaaS as not relevant to the enterprise facing environment or mystifying it as another "cloud" term. And in some unfortunate instances this confusion has impacted the way an organization looks at implementing an identity management solution (either by limiting the range of options that it could look at or by widening it to include the wrong set of options).

I intend to demystify this concept a bit more in subsequent blogs, and attempt to bring more pragmatism around it by explaining how it applies to concrete scenarios. In the meantime, I appreciate your comments and reactions.

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.

Identropy Launches an Identity Gateway for SaaS Provisioning

After countless hours of working with a few of our beta customers, I am proud to announce Identropy's launch of IC2 (or IC squared), which stands for Identity Connector for the Cloud.

You can read more about it here, but the basic idea is that it's an SPML gateway (offered in both a hosted and on-premise model) that your existing Provisioning solution can plug into in order to extend provisioning out to your SaaS applications.

The coolest part of it is that as our SaaS connector library grows to cover more and more SaaS applications, all of our clients can leverage the same code base. Service offerings are great that way!

In the following weeks, we'll make sure to continue posting to give you some of the rationale for developing the solution, and a bit of a behind the scenes look into what we are doing here at Identropy. In the meantime, we'd love to hear your feedback.

Identropy's Identity Management Solutions 101 Series

Our goal is to keep you informed and highly educated on identity management solutions, trends and business.

 

Identity Management Solutions 101: User Provisioning 

 

Identity Management Solutions 101: Password Management 

 

Identity Management Solutions 101: Enterprise Single Sign-On 

 

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

 

Stay tuned for more sessions about topics such as Deprovisioning, Cloud Computing, SOA and others.

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?

Doing It First in Identity Management

I am so amazed when I ask myself "how did that guy do it first?". If you think about it aren't you shocked when you think about the first guy that said to himself I am going to eat that octopus or that oyster...I mean if you have ever seen an octopus or oyster you would say how do you eat that? It really doesn’t look like one of the more edible things out there but guess what it’s a delicacy (of course not for me because I’m allergic…so if you ever take me out to dinner skip the seafood).

 

That brings me to the thought of how many firsts do you get in this day and age and I must say that the list of firsts is getting shorter and shorter. Only the really smart guys are producing those firsts. I guess that Innovators will do things first. SAAS "software as a Service" and Cloud Computing seem to be the last couple of firsts that I have seen and I must say they are exciting and innovative but what’s next and who is going to do it.

 

I don’t think that I will have to go too far to find out who will be the next top innovator. Identropy was mentioned in Gartner’s Magic Quadrant as an Innovator and has consistently produced technology to improve the identity space.

 

What have we done recently to get on this list? IAAS “Integration as a Service” which has been achieved through the inception of iMIS “Identropy Managed Identity Service”.

 

Stays tuned for more briefs or take a look at it on http://www.Identropy.com/Products_iMIS/