At Cardo AI we recently built and implemented our own IDP (Identity Provider) system. Read more to find out what it is, how it benefits our platform and the work behind it!

What is the IDP

The IDP refers to ‘Identity Provider’. It is a service that handles user Authentication & Authorization for applications – it creates and manages identity information, access privileges while guaranteeing a high level of security.

Cardo AI’s IDP

In order to explain how our IDP system works, we need to take a step back and talk a bit about our infrastructure, which consists of multiple macro and micro services which are deployed in a Kubernetes Cluster.  This means that we have several applications/services running at the same time that can be, however, accessed by different users and that may require different levels of permissions. 

How we faced the authentication and authorization problem before implementing IDP

Initially, every service in our cluster handled the authentication & authorization separately. This type of setup however had several disadvantages:

• Each service had extra code that handled authentication & authorization
• Each service had its own user base
• The same user had to use different credentials when accessing different services

In addition, some of the services inside our cluster needed an authorization mechanism that was a bit more complex than the solutions offered by third parties. The standard, out-of-the-box solutions were not able to meet our needs, as the permissions were assigned based on the group the users belonged to. This means that if a user is assigned to two permission groups, their permissions are joined (an additive mechanism). Therefore, the user can perform an operation if any of the groups he is assigned in has permission to do so. At CARDO AI, we needed a mechanism that could work with “exclusive groups”. We wanted a given user to have specific permissions in one role, but not in another. This type of setup would work as follows:

• A user can operate in different roles inside the system while having different permissions for each role.
• If there are two roles, Role A and Role B, and a specific user has the right to perform operation X when acting as Role A, he should not be able to perform that same operation when acting as Role B
• Previously, to handle this type of scenario, we had to create two accounts for the same user: one with the permissions of Role A and another with the permissions of role B.

We searched the web a lot, and we did not manage to find an existing solution that could solve this issue. So we decided to build it ourselves.

A Cardo AI’s solution for a common problem

We needed to build an IDP system that could work in a centralized fashion, allowing us to have a single User Base, and allowing the applications/services inside the cluster to focus only on providing features and functionalities. With Cardo AI’s IDP, a user, using the same account, with the same credentials, can: 

• Access different services in the cluster
• Operate in different roles inside a service

How the IDP works now

There is a central Ingress that is accessed before any request is forwarded to the respective service. This Ingress performs a request to our IDP service, to make sure that the provided JWT token is valid. Once this is verified, the username of the user is included as a request header. On the other hand, we have used OPA (Open Policy Agent) for authorization purposes, to implement permissions and security groups for different services. The user information and rights are declared in the IDP application, which automatically updates OPA. When one of the services receives a request, it contacts OPA to make sure that the user (who is now authenticated) has the permission to perform the operation that he is requesting. The logic behind this interaction is generalized and written in a library that all the applications use. In this manner, each service contains almost no code related to authorization & authentication purposes. 

Benefits of the IDP

We think that we have provided a new solution for the problem of Authentication & Authorization in a cluster. Some of the main benefits that the solution offers are:

Single Sign-on

This feature improves the end users’ experience, as it allows them to access multiple applications in the cluster with the same set of credentials. This means they don’t have to remember several passwords to access our services (‘password fatigue’) and reduces the chance that they will have account-related issues. The Single Sign-On also drastically increases the security of our platform and mitigates the risk of attacks, as it allows much more visibility and control over the environment compared to standard solutions.

Granular permissions structures

Roles, Functionalities, Permission. For every endpoint accessible in the cluster, there is a permission controlling the access to it.

Temporary user access

This feature allows the creation of temporary tokens, which offer the possibility to give someone access to the cluster, without a set of username and password, for a limited amount of time. This can become very useful in cases where temporary access is needed. Nowadays, when microservice architectures and the use of clusters, such as Kubernetes, are becoming more and more popular, we believe that many software companies have similar needs to us, with regards to the process Authorization & Authentication. 

More efficiency and security with Cardo AI’s IDP

Cardo AI’s is a full-fledged solution that has a lot of potential advantages for organizations.  On one hand, it can solve problems related to security risks while enhancing overall efficiency. On the other hand, it allows saving time that developers can spend on focusing on the development of features for their products. Do you want to know more about how our platform works? Contact us for a Demo today!