In this post, I am going to share how you can use Apache Mod_Mellon in conjunction with any SAML 2.0 vendor such as OneLogin, Ping Identity, WSO2 and MS Azure to create federation based Single Sign On for multiple applications. We will first identify each component and their role and create a quick set up of our problem context.
PROBLEM STATEMENT
We have many custom applications running where many different users from different organization can login to view and act on these applications. Our goal is to make sure that these applications do not handle authentication (even authorization) themselves and end users use their enterprise login information to gain access to these systems. Our goal is to say we never store client credentials for end users in any of our systems.
APPROACH to SOLUTION
Our basic goal is to eliminate single application integration with end client identity providers as we may add or remove applications from our portfolio without having to add/remove integrations with our client organizations. We would want to make sure external integration with our client organizations are at a minimum since its expensive to handle such integrations. Therefore, let's assume we are going to use an Identity Server Bus that would allow us to easily create federation with end client organization identity providers. Identity Server Bus can be described as an Identity Hub that allows us to easily connect to end client organizations and to our own applications.
In order to achieve this we will protect all of our applications with this Identity Server Bus that can act as a Service Provider to client Identity Providers. The terms Service Provider and Identity Provider are common concepts in SAML 2.0 protocol. Service Provider is an application that needs protecting and Identity Provider is an application that provides identities and handles authentication requests from such identities.
Let's assume our organization has two applications named Application_A and Application_B. Both of these applications can be protected by our own Identity Server Bus called IS_1. In this scenario, Application_A and Application_B are Service Provides where IS_1 is our Identity Provider. Let's also assumed that we have C_IP_1 as our client 1 identity provider and C_IP_2 as our client 2 identity provider.
In order to set up SAML 2.0 federation between our IS_1 and C_IP_1 and C_IP_2, we would have to first register our Application_A and Application_B with our IS_1.
Using any of the following systems (OneLogin, WSO2, Azure etc),
PROBLEM STATEMENT
We have many custom applications running where many different users from different organization can login to view and act on these applications. Our goal is to make sure that these applications do not handle authentication (even authorization) themselves and end users use their enterprise login information to gain access to these systems. Our goal is to say we never store client credentials for end users in any of our systems.
APPROACH to SOLUTION
Our basic goal is to eliminate single application integration with end client identity providers as we may add or remove applications from our portfolio without having to add/remove integrations with our client organizations. We would want to make sure external integration with our client organizations are at a minimum since its expensive to handle such integrations. Therefore, let's assume we are going to use an Identity Server Bus that would allow us to easily create federation with end client organization identity providers. Identity Server Bus can be described as an Identity Hub that allows us to easily connect to end client organizations and to our own applications.
In order to achieve this we will protect all of our applications with this Identity Server Bus that can act as a Service Provider to client Identity Providers. The terms Service Provider and Identity Provider are common concepts in SAML 2.0 protocol. Service Provider is an application that needs protecting and Identity Provider is an application that provides identities and handles authentication requests from such identities.
Let's assume our organization has two applications named Application_A and Application_B. Both of these applications can be protected by our own Identity Server Bus called IS_1. In this scenario, Application_A and Application_B are Service Provides where IS_1 is our Identity Provider. Let's also assumed that we have C_IP_1 as our client 1 identity provider and C_IP_2 as our client 2 identity provider.
In order to set up SAML 2.0 federation between our IS_1 and C_IP_1 and C_IP_2, we would have to first register our Application_A and Application_B with our IS_1.
Using any of the following systems (OneLogin, WSO2, Azure etc),
- Create a Service Provider entry for Application_A
- Create a Service Provider entry for Application_B
Creating a Service Provider entry steps will be different depending on the chosen platform. I will be creating further blog entries to explain these steps soon.
By indicating these applications are Service Providers for a SAML 2.0 compliant Identity Provider, you are indicating that these applications can create and respond to SAML 2.0 requests. Depending on the chosen strategy, SP-initiated vs IDP-initiated, these applications need to be able to understand SAML.
This is where Apache mod_auth_mellon component might help you. Instead of teaching each application to learn and speak SAML 2.0 protocol, you can rely on Apache mod_auth_mellon to handle all SAML Requests and Responses with our IS_1.
You can follow the installation steps in their documentation and get this installed on your web server (Apache Web Server). You can then easily proxy your applications (Application_A) and (Application_B). This Apache component basically will handle all SAML requests, responses and handle authentication for your applications. It's able to validate all SAML assertions. Once assertions are validated SAML claims attributes are made available in Apache and can easily be passed down to applications through Response Headers.
Applications will look for particular response header values such as REMOTE_USER and create internal user security contexts and sessions.
From a bird's eye view here are the steps (let's assume we are doing SP-initiated scenario).
- A client user wants to access Application_A, so they open their browser and type https://appplication_a.com.
- This request goes through our Web Server Apache which is configured with our mod_mellon component. Mod_mellon checks to see if user is already logged in. If the user is nog logged in.
- Mod_mellon will create a SAML 2.0 authentication request and send it to our IS_1.
- IS_1 will check to see if you have already logged in previously, assuming you have not logged in yet, IS_1 will look at the SMAL 2.0 authentication request, validate it and ask you to login (this is for local access). If IS_1 was federated with C_IP_1 or C_IP_2, IS_1 would create a SAML 2.0 authentication request and submit it to C_IP_1 or C_IP_2.
- Let s say IS_1 has no session and user is in the C_IP_1 client organization. As mentioned above, IS_1 would create a SAML 2.0 authentication request and submit it to C_IP_1.
- C_IP_1 would then check to see if the user has previously logged in, if the user has not previously logged in, user would be asked to provide their credentials.
- Once the user enters, their enterprise client credentials and they are validated, C_IP_1 would send a SAML 2.0 response back to IS_1.
- IS_1 would validate this response and internally would create a SAML 2.0 response back to mod_mellon.
- Mod_mellon would receive this SAML 2.0 response validate it and parse all of the incoming SAML 2.0 claims from the SAML 2.0 assertion.
- These claim attributes would then be made available to Application_A through response headers.
- Application_A then would look at these header values and create a security context for the user.
As you can see this is a multi-step process and requires many components to trust each other. In the coming posts, I will create code and configuration that will tie all this together. Please feel free to comment and mention what you'd like to see in the next posts.
PART 2
PART 2
Comments