Moving Away from a Push Model for Enterprise Identity Architecture

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.

Safe Harbour, Data Privacy and Scottish Independence

The Data Protection Directive (officially Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data is a European Union directive which regulates the processing of personal data within the European Union.

The Criteria for Safe Harbour privacy are incorporated into the Directive and subsequently companies operating in the European Union are not allowed to send personal data to countries outside the European Economic Area unless there is a guarantee that it will receive adequate levels of protection.

Various news reports from Manuel Barroso, President of the European Commission, have suggested that Scotland may find it difficult to join the EU. This may by corollary make it difficult for Scotland to immediately remain as part of the European Economic Area.

What does this mean for private data hosted in Scotland?

It is highly likely that hosting providers with physical infrastructure in Scotland will need to determine which customers are EU customers and migrate all of these users to an EU safe harbour before the independence referendum. If Directive 95/46/EC were enforced with strict liability then this preparatory migration (before the independence vote) would be the only sensible risk mitigation.

It would be impossible to move all data from Scottish physical hosting infrastructure before the 18th September 2014. Therefore organisations should consider what data they have hosted in Scotland and which data is most critical for migration following the seven principles of Safe Harbour law.

Guidance on this subject from the UK Information Commissioner’s Office has so far been missing.

Statutory & Contract

You may have a customer with multiple different statutory legal compliance criteria and you may also have a customer with highly specific contractual hosting & data sovereignty NFRs. The latter often comes from the sales guy abandoning the normal contract template on any fear of losing their commission and promising any physical hosting model that the customer could imagine. The sales guy has not brushed up on his data sovereignty & EU safe harbour law and the customer is nervous about externalising any data. So it’s no surprise that you the architect are left to figure out this mess while maintaining some sanity by not spawning stovepipe after stovepipe in any customer territory.

If this keeps happening in your company then no TOGAF enterprise continuum will help you find and train a sales team led organisation on the variances of data sovereignty & safe harbour regulation.

OAuth Terminology in SAML2

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

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?

API Crazy

I am a UK based TOGAF certified enterprise & solutions architect (specialising in Identity Mgmt, integration, payments, security and M2M) with experience primarily in Telco with Vodafone, Nokia, UPC, Qwest, AOL, o2, BT, H3G Australia & Colt. Plus banking experience with Deutsche Bank, insurance experience with Bupa & Chubb, utilities experience with Centrica & Nuon NL and retail experience with Nokia & Kingfisher. I started my career as a developer with BEA Systemsw working on the Weblogic Application Server product line and have since progressed through various architecture roles but still like to keep up my coding skills in Java, Scala & C++. I have worked in 20+ countries across 4 continents. I generally play off 15 but 19 for competitions.

http://lincolnparkgolfcourse.com

Over time I have found it hard to keep up with all the various web, cloud and M2M services available as part of my job. It is hard to sift through to find what is useful. Different propositions require considerable effort to even shift down from a long list to a short list of available services. As the number of services increases I find that so much useful time is taken up with vendor selection. This should not be the case for cutting edge services. The only way to maintain control is to focus on the core enablers for all of these services. Therefore the purpose of this blog is for me to share my experiences in core enablers. I will focus on what I know now, such as identity management and what I think will be important in the future such as M2M provisioning services.

If I can’t find a way to stop going apicrazy how will I ever find time to play golf?