Category: Identity Management

Identity Management Business Case Drivers for both Customer and Workforce

mustnotgrumble1 Comment

Developing a business case for identity management is often a challenge because there are not always immediate tangible benefits. Furthermore the legal or security need to maintain separation between customer and workforce will create overlap between architecture that may necessitate separate business cases. It is therefore important to explicitly align the business case with the enterprise architecture for identity management.

There are three main drivers of an identity management business case:
1. Risk and/or regulatory requirement business case
2. Operational improvement and/or cost savings business case
3. Business enablement business case (e.g. cloud or deperimiterisation)

Different categories of identity management system:
1. Customer identity management
2. Workforce identity management

Risk and/or regulatory requirement business case can include international regulatory requirements (e.g. International Safe Harbour Privacy Principles) or industry specific regulations (e.g. healthcare HIPAA/HITECH) or specific risks determined by a security audit. These drivers effect both customer and workforce identity management implementations.

Operational improvement and/or cost savings business case drivers include aggregation and simplification of existing identity management solutions, including identity through merger & acquisition. It is very hard to quantify the immediate FTE saving from simplification of identity management systems but a business case can easily be made from the aggregation of multiple workforce identity management systems.

In an organisation with multiple customer identity management systems (often from M&A) a business case can be made from both a cost savings perspective and from a business enablement perspective (e.g. cross-sell opportunities).

A business enablement business case can also include a workforce identity management solution where the employee is granted access to external systems through trust based deperimiterisation. For example securing data on business devices may come under a business enablement business case while supporting secure and encrypted BYOD may come under all three business cases.

Moving Away from a Push Model for Enterprise Identity Architecture

mustnotgrumbleLeave a comment

The discipline of Enterprise Architecture and an architecture for identity management do not currently have a best practice. The TOGAF discipline of Enterprise Architecture promotes a holistic and systemic view for interoperable systems; these may be supply chains, business processes or identity repositories. The Emerging Architecture of Identity Management argues that identity management is based on a push model with provisioning from an authoritative source as its locus. This push model exists because as enterprise systems proliferated the only viable HR approach was to provision identity to each subsequent enterprise system.

The Open Group white paper on Identity Management (W041) presents an architecture based on Delegated Authority and a master Authoritative Source. This model is firstly a push model with trust provisioned down to enterprise systems.

It is time for a review of this architecture because from an Enterprise Architecture discipline a systemic best-practice must be aware of growing trends and technology driven best practice. This author believes that authorisation needs to be contextualised and separated from joiners and leavers processing. Authorisation requires more intelligence and the proliferation of OAuth and Facebook APIs into enterprise systems (e.g. Social Authentication) will require enterprise’s to have a better approach to Attribute Based Access Control. This will provide the further benefit of not requiring enterprise’s to invest on enterprise system provisioning connectors which require regular updating and often manual intervention for everyday tasks such as promotions, demotions, joiners & leavers.

OAuth Terminology in SAML2

mustnotgrumbleLeave a comment

A Resource Server in OAuth is a Service Provider in SAML2

An Authorization Server in OAuth is an Identity Provider in SAML2

Thankfully a Client is a User

I still often say SPIL (SAML2.0 Service Provider Initiated Login) and IDIL (SAML2.0 Identity Provider Initiated Login) on a regular basis.  I find RSIL and ASIL harder.

Identity Modelling in a Global Enterprise

mustnotgrumbleLeave a comment

How do you define a single identity model for a global enterprise?

Arguing for a generised identity model that connects to a Master Data Management system for a golden record of userIds and roles reminds me of the joke answer to the barber paradox realisation of Russell’s Paradox.

The barber paradox is:

“The barber is a man in town who shaves all those, and only those, men in town who do not shave themselves.”

From this, asking the question “Who shaves the barber?” results in a paradox because according to the statement above, he can either shave himself, or go to the barber (which happens to be himself).

Just for myself and other who prefer Z-Notation to “proper English” the paradox can be explained as:

(\exists x ) (\text{man}(x) \wedge (\forall y) (\text{man}(y) \rightarrow (\text{shaves}(x, y) \leftrightarrow \neg \text{shaves}(y, y))))

The paradox breaking answer is “what if the barber is a woman?”. For the global enterprise the problem is that the introspection on the data model is an equal block.  We will all end up with massive beards if we don’t make a decision.  Similarly would philosophers eating spaghetti still get locked if you just let them eat with their hands?