What on Earth is This?
I was intrigued by this fact when I first heard of this idea a long time ago. I was wondering how is it possible to have one application (can be your custom first-party application or a SAAS solution which you might be onboarding) doing SSO (Single Sign-On) with one Identity Provider but having the best of the two worlds: SAML and OIDC. Turns out, it is very much possible if you really get creative. By creative, I mean not really doing anything on purpose for the sake of being creative but rather being creative to meet the technical or business requirement or to address a problem that you may have in your hand because why not, who doesn’t have problems? Alright, bringing you back from your problems to this fascinating thought that how is it possible to have both SAML and OIDC working in an integration for a single application’s SSO with an IdP? This is what we are here for and we will get to know-how; if you already have some understanding of SSO, SAML, and OIDC. We will look into a beautiful architecture of this on how it would look like and how that will be functioning in harmony, we will also learn when you can make use of this silver bullet from your arsenal given a chance or a problem you may have to solve being innovative.
Terms Used
- SAML (Security Assertion Markup Language)
- OIDC (Open ID Connect)
- IdP (Identity Provider)
- AD (Active Directory)
Can We Talk Architecture?
Alright, OK, we have that moment of 21 guns salute and some trumpets. Here is the architecture below, if you understand it just by looking at it, great, hang in tight here as I am sure you will get to know a few things more about it by the end of this verbiage. And if you are someone looking at the architecture and have no idea what is going on, stay with me just breathe in and out, and you will be acclimatized.
image 1
Let’s Break it Down…Please!
Let us apply the rule which most greats of this world apply when they see an issue, Divide and Conquer! We will do the same here, we break down the individual components OIDC and SAML respectively see how and where they are integrated and then, towards the end, we see how they both work collectively.
OIDC
image 2
OIDC is basically a standard which is otherwise known as Open ID (Identity) Connect which is built on the OAuth 2.0 standard. The image (2) above, is representing a very standard OIDC integration of an application (left) with the Identity Provider (right).
- Application The application here on the left, can be any application which is used by an end-user, it can be a Mobile Application, or it can be a Web Application that supports OIDC integration with an Identity Provider.
- Identity Provider – 1 Again, a very standard Identity Provider which can support both OIDC and SAML integration in a number of applications and the ability to connect with other Identity Providers. – We have the client created for the application on the left in the Identity Provider on the right to do OIDC based ‘user auth’ with this IdP. – The IdP also has a user database of course which has a pool of the users who authenticate with this IdP who wants to access the application. The point to note here is, the user pool or database can be either native to the IdP if it supports one, else you can also of course have your own database of users and their identities externally connected to this IdP.
- Authorization Code Flow All the communications 1 through step 4 happening between the application and the IdP here is called Authorization Code flow (part of OIDC) using which, the users of the application do authenticate themselves with this identity provider and thus getting the tokens to access the application. We will not go deep into each of the steps, but rather, if you follow the image (2) itself, you will surely get to know about this authorization code flow.
SAML
image 3
Now let’s investigate the other piece of this architecture which is SAML. On the Image (3) above the basic integration is between our Original Identity Provider – 1 is now integrated/connected with another Identity Provider – 2 using a SAML connection. SAML otherwise known as Security Assertion Markup Language is another protocol created and maintained by the Oasis group and currently has a version 2.0, also known as SAML 2.0.
- Identity Provider – 1
- This is the IdP to which our application was integrated, and thus this IdP has that application as Client and the data pool of users who authenticate to this IdP while using the application.
- The catch here is that this IdP also has a SAML connector using which this IdP is connected to another IdP which is IdP – 2.
- Identity Provider – 2
- This is another Identity Provider or IdP – 2 which has IdP-1 as a client in it and doing a SAML based ‘auth’ with this IdP-2.
- This IdP-2 as you can see is connected to an external source of user pool in this case which is using Active Directory. The IdP-2 and the Active Directory connection is via. LDAP (Lightweight Directory Access Protocol).
- SAML Authentication Flow
- This SAML leg of this architecture which is in between IdP-1 and IdP-2 is following very standard SAML Request and SAML Response based authentication which is initiated by the IdP-1 (which is client to IdP-2) and fulfilled with IdP-2 with user pool being in AD (Active Directory). We are not getting into the details of the SAML communication between the two but rather; again if you closely follow the Image – 3 above, you will have a good understanding of the flow.
Ok, Let’s Sum It Up!
image 4
Now finally, since you know how independently does SAML and OIDC work we can now investigate the whole picture and see how things work collectively. You can use the above architecture when:
1. One IdP integration supported by your application
- There are real-world scenarios where in your application might only support integration with one Identity Provider, which in a sense is a good practice as you don’t have multiple endpoints on your app where a bad actor can exploit identities.
- In this scenario, you can have your application onboarded with IdP-1 either with a SAML or OIDC connection. And IdP-1 is then “connected” either by SAML or OIDC connector to IdP-2.
- In the above scenario, when the IdP-1 user is logging in from your application, the request will be served by IdP-1 using OIDC. While say, if there is a user logging into the application who has their identity in IdP-2 (AD in this case), in that case, the user will still see IdP-1 as login interface but, that request will then be forwarded by IdP-1 to IdP-2, therefore IdP-1 is the “client” of IdP-2. The request is then fulfilled by IdP-2 doing a LDAP with Active-Directory of the user logging in and giving a SAML response back to the client or IdP-1 in this case. IdP-1 then taking the SAML response creates OIDC tokens (Access Token, ID Token, Refresh Token) and then responds back to the application and logs the user in.
- Trust me, all the above can happen as fast as logging in with a single IdP, its just about how you are designing it and doing your due diligence.
2. You Might Want to Keep a “Set” of Users Separate
- Where IdP-1 might hold identities of the specific set of your business users’ example: B2B or B2C user identities which your business might interact with.
- While, your in-house or your own employees can be in the IdP-2 which does LDAP with your enterprise Active Directory. And, your IdP-2 is a ‘connection’ to your IdP-1, again this connection is up to you, it can either be SAML or it can also be OIDC.
- In this way, you are not worried about mixing the two sets of different users or identities.
- And once you have such kind of setting, it is very easy to control the RBAC of the different set of users. Because your customers using the application might have different Roles/Scopes/Permissions/APIs from your employees using the app. 3.
3. Protecting your IdP-2 o
- Say, if we continue with the thought that your IdP-2 doing LDAP with Active Directory comprises of identities of your internal users or employees.
- You might have your own private/secure corporate network where of course you might not want to put your IdP-2, to be public-facing for the application which is used by your customers but also requires access by your internal employees.
- In this architecture that is absolutely possible, wherein, your IdP-2 will continue to be protected in your internal corporate network besides, you just have to whitelist the endpoints of IdP-1 in your firewall or protected network for any communications between the two.
- Thus, your IdP-2 will only respond to the requests made by IdP-1 and no other request can reach to IdP-2, thus securing your internal IdP and Directory of our corporate users.
There are myriad other scenarios where you can leverage such kind of an alluring architecture to meet any technical or business requirements that you may have in hand. Let us know where you can fit this in to meet your requirements? We will be keen to hear from you. Yes, we are also and always open to questions that you may have, and we can certainly help you to tailor such architectures to meet your requirements.