Many of us have encountered the word auth while building our applications. It might have surfaced up while discussing about identity and access management, CRMs, security etc. Just to be clear, the auth I am referring to here is the whole ecosystem of authentication and authorization. If you are not familiar with it yet, relish the moment, but do buckle up. When it comes to understanding auth, it can briefly be categorized into three - don't understand auth, trying to understand auth, think they understand auth. Now, I daresay, the latter could sometimes mean skewed or sketchy understanding, which might lead to problems like- complications in the entire architecture, unsolicited expenses and in the worst case scenario - heart bleeds.
We had the former (over complicated architecture) and fortunately, it was identified on time. We realized that we had to re-look our auth flow and come up with an optimal solution. Let us now dig a bit deeper into the stumbling blocks we had our way and how we were able to resolve them.
The Cast
Lead roles: Keycloak and Salesforce Community Cloud, Supporting role: JWT, Series regular: Portal user and API user
The Plot
We are trying to build an online marketplace for our existing client, so that they can onboard new partners onto this.The marketplace has two divisions- “ Portal" and “API”. The former is used by human users while the latter by API servers.
In the existing architecture we separate the identity and access management(IAM) for the Portal from API. Salesforce community cloud(SFCC) is being used for the user management of the portal users. This is mainly because SFCC does not have support for JWT(which is how the claims are being/need to be transferred now). This is where Keycloak comes into the picture as an identity provider(IDP). Keycloak here is used to understand this JWT token and thereon send this information to SFCC.
The Conflict
Many of you might be wondering why is SFCC being used for IAM. Well the answer to that is, SFCC started off as a CRM tool for us but it happens to have IAM capabilities too. The previous system (built long time back) used these capabilities treating SFCC like a cure for all ailments. When the need for scalability emerged, this cure did not work, which led to hurried patch work of solutions giving rise to a complex architecture.
The rest of you who are wondering why Keycloak and not Auth0 or some other managed auth offering, the answer to this would be the clients already had Keycloak expertise, and the idea of introducing something new and completely different did not fly.
The existing solution suffers from a shared state between Keycloak and SFCC for user management. As mentioned earlier, the API users are managed in Keycloak and the Portal users are managed in SFCC. This introduces multiple sources of truths which in turn leads to multiple points of failure. It forbids unified role based access control across products (API and Portal). This means we have to manage roles for API users and Portal(human) users separately. Roles are imported in Keycloak as user attributes, which means it is hard to change the scope of clients in Keycloak. This exposes system to security issues.
And to top it all, with hundreds of redirects happening in between Keycloak, SFCC and the sytem, there is an unacceptable delay in response.
The Resolution
It wasn't easy. As Murphy's law states "Anything that can go wrong will go wrong"- and it did. It took almost an year for the clients to approve the new architecture. There was a strong affinity towards the existing system, but since the stakes were too high, everybody agreed in the end.
We proposed to use Keycloak as an IDP for both API and Portal, and SFCC as CRM( customer relationship management). With Keycloak as our single IDP we reduce the points of failure and enable separation of concerns. SFCC being a CRM tool would take care of customer relationships.
The Happily ever after
Well, given the fact that we were able to identify the loopholes and have a resolution in hand which is doable from both cost and skill standpoint, we have now started our journey towards development. Not sure if this is the expected happily ever after or if there is really a happily ever after in the world of tech but considering the optimist I am, we could surely hope for one.
Top comments (0)