Beyond PSD2 for a Better Open Banking Expereince

PSD2 is acting as a catalyst in the digital transformation happening in the Banking industry. While meeting the compliance requirements of PSD2, financial institutes are excited to make use of the new business models and opportunities opened by this laid foundation. More the customers and partners we can reach, more the business activities and more the revenue. Making the banking functions more accessible and reactive will be a key enabler to provide a seamless experience to these parties, including internal banking staff whom directly affects the business efficiency.
IAM plays a critical role in improving business accessibility without compromising the system boundaries. PSD2 mandates strong customer authentication(SCA), setting the bar high for user authenticity, while keeping few exemptions, not to bother payment services user(PSU) with SCA for every little transactions. While adhering to this policy will make an institute PSD2 complaint, if they can react fast to the fraud rates…

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)