Identity Mediation for Enterprise Identity Bus

By - Pushpalanka JayawardhanaSupervisors - Mr. Prabath Siriwardena & Prof. Gihan Dias

Project Area Background● WhatsApp been acquired by Facebook, Skype been acquired by Microsoft

● Wall Street Journal “2015 the biggest year ever for mergers and acquisitions”. enterprise identity management → rapid merge of external users to current enterprise system.

● Quocirca - “many businesses now have more external users than internal ones. Many organisations are putting in place advanced identity and access management tools to facilitate the administration and security issues raised by this.”

● Gartner - “By 2020, 60% of digital identities interacting with the enterprise will come from external identity providers through a competitive marketplace – up from less than 10% today.”

● BYOID

Project Area BackgroundMultiple protocols used to authenticate and authorize users.

● Googlea. OpenId Connect basedb. OpenID2 protocol was deprecated-

Shutted down OpenID2.0 API on April 20, 2015 )

c. SAML

● Facebook○ OpenId Connect (a modified version)

● Yahoo○ OpenId2○ OpenId Connect

● Salesforce○ OpenId Connect based○ SAML

● Twitter○ OAuth2.0 for delegated authorization

● LinkedIn○ OAuth2.0 for delegated authorization

Project Area BackgroundEvolving of protocols.

➢ 1997– Hotmail - Using WindowsLiveID and password➢ 1997– Yahoo - Using YahooID and password

➢ 2001 – Microsoft Windows Live

➢ 1999– Microsoft Passport

➢ 2001 – Microsoft HailStorm

➢ 2001 – Liberty Alliance - leads to SAML 1.0 protocol with

Shibboleth implementation coming in 2003

➢ 2004 – Facebook with username and password login

➢ 2004 – GMail with username and password login

➢ 2005 – Seven Laws of Identity - By Kim Cameron of Microsoft

➢ 2005/February – XACML introduced by OASIS

➢ SAML2 Web SSO 2005/March– SAML specification

➢ 2005 – Microsoft InfoCard

➢ 2005 - OpenID➢ 2006/April - Google Calendar

➢ 2006/June - Google Calendar introduces a token based

authorization\

➢ 2007/Dec - OAuth 1.0➢ 2008/Jan - Yahoo adapts OpenID , Blogspot adapts OpenID

➢ 2008/May - Facebook connect is introduced➢ 2008/June - Google adapts OAuth1.0

➢ 2008/Oct - Gmail adapts OpenID➢ 2008 - SAML2 Web SSO is introduced

➢ 2009/Sept - Yahoo adapts OpenID and OAuth1.0

➢ 2009/December - OAuth 2.0 specification introduced➢ 2010/March - Google Apps marketplace adapts OpenID

➢ 2010/May - OpenID Connect specification introduced➢ 2010/July - Twitter adapts OAuth2.0

➢ 2010/Aug - Facebook adapts OAuth 2.0

➢ 2011/March - Google apps adapts OAuth 2.0

➢ 2011/May - SCIM specification is introduced

➢ 2014/Nov - SAML bearer grant for OAuth 2.0

➢ 2015 April - Google discontinue support for OpenID

UMA (User Managed Access) is currently getting wider attention (https://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protoc

ol)

Problem StatementWhen multiple systems get added or removed from enterprise systems, identity and access management

on these systems needs to be addressed eagerly. This require changes to identity flows such as authentication, authorization and provisioning, that may involve different policies. These raise the need of a mechanism to comprehensively handle identity flows.

Proposing SolutionInspired from ESBs, introduce a domain specific language that is powerful enough to define the identity message flow, along with an

engine that will mediate the identity messages according to the configuration done by this language.

Expected Outcomes- Define the IML Language

- Overcome the issues when coming from ESB space to Identity Bus space - maintaining state information- Identity vault to serve as a storage (might store lot of sensitive data than an ESB)- EIB should address focused transformations on Identity domain in contrast to raw level

transformation(eg. SOAP to REST) done by ESB which can be applied to any domain. - Identity mediation engine that will process messages as per the IML definition- Define the transformation for at least from SAML to OpenID Connect and vice versa

Scope of ProjectA federation flow can consist of multiple combinations of below aspects, which can grow in the future.

- Authentication, Authorization, Claim mgt/mapping, Provisioning users with details, Access delegation,

Workflows

Scope MSc project will be on authentication and authorization aspects, while keeping freedom to add other aspects later.

At the completion of project, it will have below outputs,

- A DSL powerful enough to define a federation flow, involving authentication and authorization and extendable

to support other aspects mentioned above.

- The identity mediation engine that will handle the identity message flow, honoring the configurations done by

the DSL→ IML.

- Demonstrate an identity message flow between two systems that use SAML and OpenIDConnect.

Existing Solutions

Atricore Identity Bus- This is a very similar implementation.

- Done as a MSc thesis in 2012 and is an Identity Bus currently present in the market, named as JOSSO.

1. The federation flow is not very intuitive in the diagram. The message flow is not visible

2. The user is forced to use the UI, even for a minor modification. (The configuration is in binary format)

3. No direct option is seen to add a minor conditional effects on the flow (policy based authentication).

a. Eg. if the second authentication factor should be decided, based on the role of the user.

WSO2 Application Authentication FrameworkLimitations

- Have to write a custom component even for a simple conditional policy editing. (if not supported by default)

- No single view of the configurations for authentication flow. (UI based configs and file system based configs are possible, but not synced together.)

Ref: https://docs.wso2.com/display/IS510/Architecture

ESB Domain● ESB’s also use DSLs for mediation.

○ Synapse Language for Apache Synapse lightweight ESB○ Mule Expression Language (MEL) for Mule ESB

■ These have been used in configuration files, while been managed through configuration management tools such

as Chef, Puppet etc. across the deployments.

■ Has proven to cater for dynamic configuration requirement for message flows in ESB, but not identity flows.

Literature Survey Summary

Prominent Identity ProtocolsAuthentication Protocols

● LDAP(Lightweight Directory Access Protocol)● SAML - Security Assertion Markup Language● OIDC - OpenID Connect, OpenID● WS-Trust/WS-Federation● FIDO - Fast Identity Online

Authorization Protocols ● OAuth 2.0● XACML - (eXtensible Access Control Markup Language)

Provisioning Protocols● SCIM (System for Cross-domain Identity Management)● SPML (Service Provisioning Markup Language)

Auditing Support Protocols ● XDAS (Distributed Audit Service)

ESB as EIB● ESB is serving mediation between transport protocols and data formats● ESB can support use cases such as provisioning users to multiple systems.

Limitations

● Keeping Identity Key Mapping - Identity known to Google as ‘User1’ might have an identifier in HRM system called ‘Em22’. Need a storage to keep the mapping.

● ESB is stateless● Generation of user reports has limitations - Need to talk to all the systems at requesting time as no persistence layer.● User interaction - In an ESB the end user is not provided with an UI interact

“An Identity Manager can be seen as a highly specialized ESB, improved with persistence of identity information and identity management functionality through a GUI.”

EIB Implementation Efforts● Data Virtualization:

○ Leaving the data at residing site (HR, CRM databases, LDAP stores, etc) and retrieves on demand.○ Combining the information from various stores to present a rationalized, unified view to the consumer.

● Cloud Identity Providers: ○ Not be limited to physically direct connected data stores, but also support cloud identity providers.

● Simple API: ○ Eliminate the need for application developers to become experts in LDAP, SAML like standards-based

protocol.

○ A developer-friendly API that exposes the identity profile using a rich schema.

● Principle of Least Knowledge: ○ Make the identity data available to consumers on on-demand basis.

○ Support both definitive (date of birth) and derived (over 21) identity claims.

● Pub/Sub Models: The IDP should provide a way for the consumers to listen to identity related events.

● Schema Mapping: Allowing identity claim mapping between IDP and application.

Domain Specific LanguagesKey Elements

1. Computer programming language: easy for humans to understand, but remains executable by a computer.

2. Language nature: sense of fluency where the expressiveness comes not just from individual expressions but also from the way they can be composed together.

3. Limited expressiveness: DSL should focus on a bare minimum of features needed to support its domain only. Using a DSL for one particular aspect of a system is recommended.

4. Domain focus: have a clear focus on a small domain.

Benefits of using an DSL1. Improving development productivity :

a. Provides the abstract layer for the model b. Provides a clear communication mechanism

removing ambiguity. c. Avoids duplication by gathering together

common code.

2. Domain experts can easily point out mistakes in the model - (Once the DSL is understood and what it tries to do)

3. Change in execution context : A DSL allows definition be evaluated at run time rather than compile time.

Future of IAMFederation

● Forrester○ Seamlessly authenticate customers without sacrificing experience.○ Provide partners with access to sensitive resources without affecting business agility.○ Give employees access to cloud services from any device securely.

IoT

● CloudSecurityAlliance

“The security industry is seeing a paradigm shift whereby IAM is no longer solely concerned with managing people but also

managing the hundreds of thousands of “things” that may be connected to a network”

Conclusion● Adapting a ESB as it is for the identity domain is not a good option.

● Use of DSL seems to have both benefits and drawbacks. Introducing tooling to write DSL will help avoid drawbacks.

● The project will have importance for the future based on the analyst reports as ‘Federation’ is expected to be of greater need.

● IME should be flexible enough to adapt life cycles of identity specification and dynamic to handle the identity flows defined by IML.

THANK YOU!