Challenges of Future IAM (concerned with Mergers , Acquisitions, Startups)

When the companies bring in external users to work within the enterprise activities, via mergers, acquisitions, outsourcing and allowing end users come via social login, a problem is raised due to the variety of protocols each of these external parties may use for identity management. Most of the time these external parties would not agree to share their user base with sensitive information of the users, which is a major asset of them. In this case identity federation or cross domain authentication comes into provide a solution to this problem. There are identity federation protocols that have evolved with the time mainly OpenID, SAML, WS-Federation and OpenID connect to address the requirement of federated authentication. Even though these protocols have been able to cater for it, while the acquisitions and merges grows up in numbers the solutions still suffers from two major limitations, namely[1],

Federation Silos



When there is federation requirement, organizations would choose on of the protocols available as suitable for them and move ahead with it. Any new system to be integrated would be preferred to support this protocol as it will be able to co-operate with the existing system This leads to a federation anti-pattern that may be a silo of SAML federation, a silo of OpenID Connect federation or a silo of OpenID federation or some other protocol. Later this makes it so hard to bring on a system which does not support another protocol and system is within the boundary of one particular protocol.

Spaghetti identity



When large-scale federation deployments are considered, this anti pattern is observed. When one silo is considered from the above figure, within an enterprise there may be so many parties involved in any of the protocols as service providers and identity providers. Almost all of these protocols depend on a trust relationship built among these parties in order for the federation authentication to work. In a large scale this means there are many point to point trust relationships that need to be maintained as below. This added complexity makes it an anti-pattern that needs to be get rid of.

Hence an integration mechanism is required between these parties of service providers and identity providers. If this integration just focused on each single entity that the enterprise would interact, then it can end up with something similar to below, which not doing any better than above.
Collaboration.png

                                       Integration with External Parties for Identity Management

As seen in the figure, if this approach is taken, the end result is a maintenance costly, complex design. This means to write adapters for each new party that is joining the enterprise system, which leads to several complications such as,
  • Adapters needs to be written(may be from the scratch) which takes time and involves a significant cost
  • With the increase of number of adapters, complexity of maintenance goes high
  • Less re-use of available resources and efforts put on writing adapters
  • No central location which can control the identities involved in the enterprise.
    Identity Management includes several aspects such as, authentication, authorization, claims handling of users, provisioning users etc. These have common factors for all the parties which can be reused among them. Also if authorization is considered for an example enterprise usually have policies that needs to be effective across the system. With above design this is much complex and there is no single location that can cater for monitoring or managing requirements.

Comments

Popular posts from this blog

Signing SOAP Messages - Generation of Enveloped XML Signatures

How to send an HTML email in Java (Using Google SMTP Server)

Adding Custom Claims to the SAML Response - (How to Write a Custom Claim Handler for WSO2 Identity Server)