Identity mediation for enterprise identity bus

Embed Size (px)

Text of Identity mediation for enterprise identity bus

  • 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.


  • 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


    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 (


  • 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,


    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.)


  • ESB Domain ESBs 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.


    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


    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) identit