Three Legged Architecture of Access Management
Kari Laalo
IAM Architect | Developer | Follow instead of connecting | Accepting only contacts I've met | Book meeting below | ?? 044 911 9957
As discussed in our previous podcast (in Finnish), authentication is little known subject among consumer users. It is also little known and not too well understood topic either in IT management.
I got an opportunity to discuss with our friends about Gate product. Gate is interesting new product that SlashId just featured. It can act as a Policy Enforcement Point (PEP) component in Access Management architecture. While discussing PEP’s role in the component architecture, I realised that the role of a PEP is not very well understood.
Typical Application Development Project Initiation
Quite often when application developers start building new application for a customer, they don’t think of access management at all. They plan on writing authentication and access management directly to the application because they can.
In slightly better scenario customer has an Identity Provider (IdP) in place already making developer able to forget about authentication. Developer can concentrate only to access management and application business logic. Also, the framework the developer uses probably has ready libraries to connect to IdP e.g. with OpenId Connect (OIDC). Access management will be straight forward task for the developer.
But, this approach is straight forward only for a single developer using a framework and who works on a single project.
When things are being done in an larger enterprise or when businesses grow, maintaining multiple separate applications and especially multiple different authentication and access management solutions becomes cumbersome.
This is the reason why component architecture of authentication and access management should be discussed more.
To prevent pain of migrating from old legacy architecture while companies grow, developers should understand that authentication and access management are separate tasks in IT management and from application development.
Authentication and Access Management are repetitive tasks that should not be written again for each application, but they need to be planned ahead of application project initiation.
Traditional Components in IAM
Identity Provider (IdP) is beginning to be commonly understood component. IdP’s responsibility is to authenticate users with authentication methods that are made available. IdP passes on the details of authentication transaction to an application via an authentication protocol (nowadays commonly OIDC or SAML2).
Authentication can be based on one or multiple factors (MFA - Multi Factor Authentication). Authentication method can be or based e.g. to (I have deliberately left poor methods unmentioned):
Policy Enforcement Point (PEP) is a component protecting the application. In tratitional view, PEP is a Relying Party (RP). Relying Party is a term used in connection to authentication protocols (OIDC/SAML). RP is the entity relying on the authentication transaction that was processed on the IdP.
In plain terms, one should think that while accessing the application (backend), users bring something based on the authentication completed on the IdP with them to get pass of the PEP. Usually it is a token.
PEP Should Be Seen As a Product
Quite often when developing a single application as a software project, the PEP/RP functionality is written as a code or based on a software library included in the application.
Another traditional approach to protect application with authentication has been to use web agent based approach. Web agents are more product based approach than using a library or writing code from scratch, but they still are code based. Usually they are filters in code project or plugins in application server.
As said, this is fine in single software project. However, this is bad pattern given that companies grow and architectures escalate.
When building for more mature architecture, PEP is included as a separate component. In modern web application world PEP is a reverse HTTP proxy. It takes the requests from the user and translates and relays them to the actual backend API if access is granted.
As the name implies, PEP enforces the access management policy by allowing only entitled users to access the application backend. This is done based on the information that is received in the token that user passes to the PEP component
PEP can be compared to a firewall. It makes access decisions based on predefined access control rules. In traditional model PEP can also manage user’s session so that user doesn’t need to visit the IdP during each page refresh or backend query.
PEP is a component that can be separate product. You wouldn’t write your firewall functionality in to your application each time new application is created in an enterprise, would you? It is not efficient to write PEP functionality as a code to each application separately. It’s better to have reusable component that can be separated from application logic.
As mentioned, the Gate product is one example of a PEP product. I have quite often pointed also to another favorite of mine: mod_auth_openidc. There are many others in the market as well.
领英推荐
Three Legged Access Management
Related to Access Management, “Three Legged” is my term for Backend for Frontend pattern (BFF) initially from Sam Newman. BFF pattern is becoming more popular in modern application development in cloud environments. I call this pattern Three Legged because in traditional IAM (Identity and Authentication Management) setup, there are two major components, the IdP and the PEP.
However currently developers like to build applications where User Experience (UX) is happening in userspace. It can be a mobile application or web application built based on SPA (Single Page Application) approach using e.g. React or Angular or similar framework. The frontend application is its own component running on user's device. This brings new component to the architecture: Backend For Frontend (BFF).
BFF is often publicly available to the internet. It manages (ideally) no user data (Personally Identifiable Information - PII), but only the frontend application logic. In its simplest form it’s nothing else than public Storage Bucket in the cloud only hosting the application’s UI code that the user loads while opening the application.
Because of practical reasons and for security implications, this Three Legged architecture changes the component roles a bit from traditional Two Legged architecture.
User Interface Is the Client
Authentication has many pitfalls regarding to privacy of personal data, information security in general and nowadays most importantly resistance to phishing. There is a complete RFC describing Threat Models in OAuth: RFC 6819.
Another RFC has been written for implementing OAuth 2.0 for Native Applications: RFC 8252. To turn it to simple terms, the frontend UI application is a public OAuth 2.0 client (OIDC is based on OAuth 2.0). OAuth Client Types are described in chapter 2.1 of RFC 6749 (the actual OAuth 2.0 spec).
When dealing with OIDC, one should nowadays remember that Implicit Grant flow has been practically deprecated. I say practically, because there is no authoritative documentation saying it should not be used, but many documents implicate so.
This means that OIDC Authorisation Code Flow is only viable modern way to connect to IdP. To add protection while using public clients an amendment to the flow has been published: Proof Key Code Exchange (PKCE), which is defined in RFC 7636.
As client_id and client_secret are public in Three Legged scenario, attacker could intercept the code exchange for token and get unauthorised access through the PEP. PKCE adds security in the flow by ensuring that only the initiating client can receive the token that is used to get access through the PEP on behalf of the user.
To summarise; what changes in Three Legged authentication architecture is that the UI client handles the exchange of the code in authorisation code flow for the token that can penetrate the PEP. This is very often a neglected issue while writing the PEP implementation from scratch.
Consolidated Policies
An excellent question remains. Does one apply one PEP that protects all applications or is there single PEP in front of each application?
Answer is: you deploy at least one PEP for each application. In modern application (usually containerised) component architecture PEP need to be small and efficient. It sits very close to the application maybe as a sidecar. Where one can centralise an IdP, PEPs need to be scattered. Each application has its own rules and have need for separate configurations. Maintaining all these in one centralised place would render the benefits of a PEP useless.
Now, you ask, how do we audit our access policies? If PEPs are scattered, how do we keep an inventory of them? Well, the answer is: in similar manner you gather the inventory of any components in your architecture.
But in IAM, there still is another solution to solve problem of centralising policy management: policy server. Fully functional PEP can connect to a policy server that keeps hold of access policies in centralised manner. Policy servers would be a completely separate blog article, so we don’t dig deeper in this now.
As a bonus, I’ll mention in this context that you might want to take a look at feature flags as well, but let’s not go there today.
Benefits of a Separate PEP
To conclude this article, let’s summarise the benefits in separating PEP in your component architecture.
Separation of duties: PEP has very separate role in Authentication and Access Management. One should not overload the duties of simple components to keep the solution architecture clean and easy to understand and maintain.
Simple operations procedures: single components are easier to document. DevOps tasks and processes are easier to segregate between teams or specialists as everyone don’t need to study complete big picture of the application (or even enterprise) architecture.
Avoid repetition: one should not write or duplicate the same functionalities separately to many separate applications, but deploy re-usable components.
Clear management boundaries: maintaining and measuring SLA (Service Level Agreements) becomes cumbersome or impossible in monolithic architecture.
Fast recovery from incidents: simple component architecture makes it easier to recover from incidents. Causes of an incident are easier to find when single components can be monitored separately.
Shortened time to market: new features can be implemented with less effort when only application logic need to be implemented for the new application.