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.

Popular posts from this blog

Signing SOAP Messages - Generation of Enveloped XML Signatures

Image
Digital signing is a widely used mechanism to make digital contents authentic. By producing a digital signature for some content, we can let another party capable of validating that content. It can provide a guarantee that, is not altered after we signed it, with this validation. With this sample I am to share how to generate the a signature for SOAP envelope. But of course this is valid for any other content signing as well. Here, I will sign The SOAP envelope itself An attachment  Place the signature inside SOAP header  With the placement of signature inside the SOAP header which is also signed by the signature, this becomes a demonstration of enveloped signature. I am using Apache Santuario library for signing. Following is the code segment I used. I have shared the complete sample here to to be downloaded . public static void main(String unused[]) throws Exception {         String keystoreType = "JKS";         String keystoreFile = "src/main/resour
Read more

How to convert WSDL to Java

Image
Background Basically WSDL (Web Services Development Language) is an XML document used to describe or locate web services. WSDL stands for Web Services Description Language. The document describes a Web service. It specifies the location of the service and the operations that can be taken.  WSDL2Java is distributed with Axis2 package of Apache and need to set-up Axis2 to use this service. A  guide to set-up Axis2  can be found in apache organization documents .WSDL 2.0 is the currently using version. Obviously JDK should be properly installed too. Note: For the 3rd method you are not needed to set these things by yourself. The WSDL document includes server Java programs for Web services and generated classes using WSDL2Java feature includes client stubs, server skeletons and data types that can help in writing client side. The generated stub classes play a great role in distributed computing and if you are interested can read on  what are stub classes . In brief talking, 
Read more

How to Write a Custom User Store Manager - WSO2 Identity Server 4.5.0

Image
With this post I will be demonstrating writing a simple custom user store manager for WSO2 Carbon and specifically in WSO2 Identity Server 4.5.0 which is released recently. The Content is as follows, Use case Writing the custom User Store Manager Configuration in Identity Server You can download the sample here. Use Case By default WSO2 Carbon has four implementations of User Store Managers as follows. org.wso2.carbon.user.core.jdbc.JDBCUserStoreManager org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager org.wso2.carbon.user.core.ldap.ActiveDirectoryLDAPUserStoreManager Let's look at a scenario where a company has a simple user store where they have kept customer_id, customer_name and the password (For the moment let's not worry about salting etc. as purpose is to demonstrate getting a custom user store into action). So the company may want to keep this as it is, as there may be other serv
Read more