Part 2: OAuth Scopes Work Magic
In part 1, I painted the ambition for an enterprise-wide system of managing access. In many cases, connections to digital resources use something called an application programming interface (API). In this final part, I unveil how to map and build such an access management system. It requires a close cooperation between your Identity Provider and your API Gateway. It also requires an API-First mindset. Both are pretty straightforward, nowadays. And pretty powerful too. And, best of all, they are easy to scale – even across hybrid clouds and across a range of different technologies. Finally, I take you on a dream tour. Enjoy the read!
Making it happen
To be in full control of access to your digital assets, at any scale, without breaking the bank, and without losing your agility, a clean separation of concerns is your best bet. Conceptually, there are just a few types of components to manage – Identity providers and API Gateways.
There are also a couple of types of stakeholders – Information Managers, Personnel Managers, Line Managers and Auditors. Should you align those throughout your information landscape, you would be well on your way towards your full access control future.
I want to start where your digital assets are managed. Let’s first agree that all your data is somehow processed by software, be it a word processor, a website, a workflow management system, or an ERP system. So, if you want to manage access to these assets, you have to make sure that access is only possible through the software you control. This may require a number of measures already. On the network level (remember Solarwinds?), on the database level (don’t forget to encrypt your backups), and on the physical level (store those tapes behind securely closed doors). After all, what use is it to invest in securing access to data in the database when the backups are freely accessible. All pretty standard cybersecurity stuff. In cloud computing especially, the well-known cloud native principles will guide you into encapsulating your digital assets inside your services.
Next, you want to make sure that access to these services is only possible over well-defined interfaces by using industry standard protocols. Yes, I’m talking APIs here. Never mind the style you implement, REST, AsyncAPI, GraphQL, or some other flavour, the importance is that you can manage access to your digital resources outside the service that implements it. This is obviously important, because that’s the best way to
- create a consistent behaviour,
- maintain an overview, and
- avoid the proliferation of management and governance efforts.
Consequently, user accounts, applications and permissions are all digital assets that you should manage on the enterprise level. Allow your people the luxury of having one identity with one set of credentials, serving all their digital needs. I know, perhaps better than most people, that this is easier said than done. At the same time, I know the authentication and authorization standards have matured a lot, and a cleverly used Identity Integration Hub is a powerful tool to fuse all your identity and access management pieces together.
Effectively tackling the management burden
Once you access your digital assets over APIs, you have the option to use an API gateway for controlling access to your APIs and thereby to your digital assets. That’s right, an API gateway is a valuable tool to control access. How? Well, access control builds on authorization, authorization builds on authentication, and authentication builds on identification. An API specification can be used to define the required authentication mechanism. Have a look at this snippet:
securitySchemes:
JWT:
description: OAuth2 JWT bearer token assertion
type: OAuth2
scheme: bearer
bearerFormat: JWT
This snippet effectively defines you can only access the API with an ID token [iii] as authentication. Now this is great, because you can validate the signature of the JWT (to establish it is an original token), and thus trust the content of the JWT. Moreover, you can easily use the content for an authorization purpose. That’s where the OAuth scopes come in. Although this is not widely practised yet, OAuth scopes can really work magic in controlling access to your digital assets.
security:
- ApiKeyAuth: ["account.read", "finance.supervise"]This formal definition states that only users having at least one of the scopes “account.read” or “finance.supervise” in the “scopes” section of their JWT are allowed to access the API resource. It’s also a simple statement for the API gateway to enforce. And it actually works great from a management perspective too.
You can compare a software token with the plastic key card that you get to enter your hotel room. Both of them give access to a resource, both can be invalidated, and both are examples of authorization – you having the token or card gives you access to the resource as long as your token or card is still valid. One key card may give access to multiple rooms. Similarly, a software token may include any number of scopes. You can add other properties to enhance the security. For instance, you can print a photo on a key card, you can divide a hotel into separate zones. With a JWT too, you can conveniently add information. For instance, the Authentication Context Class Reference indicates the reliability of authentication. You can use this to make sure that basic authentication only grants you access to basic information.
By defining these scopes (you’re free to define your own scopes as you see fit), the owner of the API explicitly defines the permission level that’s required for accessing the resource. Subsequently, you can bind the scope to one or more user groups or user roles. This is the responsibility of an access manager. Someone with the overview to logically group low-level permissions into higher-level entitlements that make sense in an organization. Finally, a line manager must assign the role to someone in his line doing the actual work. This brings separation of duties at the appropriate level. At the same time, it is very scalable, and easy to organize. It fits well in microservice architectures and an agile way of working. It’s straightforward to audit. What’s not to like?
Helping you to select an IAM solution
Download nowRecently, I designed a quite complex system exchanging information between government entities and citizens. Understandably, security was an important driver for the design. Citizens can only have access to the information sent to them, the government entities can only send information to citizens who have given prior consent. Moreover, citizens are enabled to give other citizens delegated access to specific parts of their information. Similarly, government entities can appoint organizations to represent them.
I designed the entire system ‘API-First’, opening the opportunity to front every ‘resource’ by an API Gateway. This has become our main point of access control. Next to that, we created a management portal where government entities can manage and authorize their own users, as well as their representations. In another portal, citizens are managing their delegations. Alternatively, they can opt to use a mobile app.
Our Identity Provider generates an OpenID Connect token containing all the information the API Gateway uses to control access to all resources, including the APIs to manage users and their authorizations (OpenID Connect Scopes). Now the system is in place, the security almost seems facile. The management burden is low, performance is high, while the enforcement is rock solid and fully transparent. It’s also based on industry standards, ensuring future maintainability, amongst others.
Office applications
By now, you may be wondering how to protect your office applications and the like? After all, they don’t use any API you can manage to access files on your network. They are an integrated user interface and backend application. A mere monolith. And users can access those files using software you cannot control.
Although I don’t think these older architectures are going away anytime soon, I do see some hopeful signs. Particularly in cloud-native applications, where there is an elegant solution to this problem. A simple storage solution that is designed as a networked API. There’s so much to love about the AWS S3 service that alternative implementations such as Minio and S3Proxy are used throughout cyberspace. S3 is not exactly a file service, but a distributed object store. It’s robust, resilient, hyper scalable, and most of all, it’s an API. Conceptually, it is a small step for Office tools to add object storage as a feature. Heck, even the Sharepoint API could do such a job. Once we’re there, you’ll be in full control.
What about Digital Governance?
It is easy to predict that, once all your access control is centralised, governance will become a major bottleneck. And yes, this will require a rethink. Fortunately, we’re well underway towards a distributed governance model. A model where responsibilities are delegated, within proper guardrails, so that accountability can still be safeguarded. Perhaps better than ever before.
The secret to digital governance is called “shift left and shield right”. That means radically delegating responsibility to the lowest possible level where ownership is felt. Empower these owners with tooling that guides them to making sound decisions and setting proper policies. Ensure that, whenever they go outside their guardrails, they need approval of a ‘higher’ authority. Also make sure that these policies are fully enforced. That’s the part where shield right comes into play. If you properly declare your authorization policies, the digital infrastructure can ensure that only properly authorised actors can access your digital assets. No exceptions, no backdoors. Guaranteed.
I’ve written before about API Security, 42Crunch, and how their toolsuite enhances your API Security. This has now become more relevant than ever.
Is this really a Panacea?
Well, frankly not a full 100%. There’s one category of digital assets we’ve so far not discussed. And that’s the kind of systems where the creator of a digital asset is also the one who manages access to their asset. However, he manages access outside the scope of the access management systems. This breaks the separation of duties as discussed. It also introduces serious problems – there’s no oversight over permissions, and authorizations are often not well-managed. Not good.
Typically, this happens with systems where documents, projects or cases are managed. A single user, as identified by the identity provider, will have different levels of access to different projects, cases, accounts, in the system, based on their kind of involvement. By default, you cannot access anything, unless the owner of an asset has granted you some “involvement role”.
Fundamentally, the problem is that the identifiers of these asset types (projects, cases, client IDs, folders) are not managed in your Identity Provider. Consequently, your Identity Providers doesn’t let you manage access to those unidentified digital objects. In my mind, that makes sense. Firstly, there are no standards available to create an interface for managing those identifiers. Secondly, these assets can be highly dynamic. Think of an IT service management system, where (many) hundreds of cases are closed daily, yet the level of access of a single employee to each case may vary widely.
You might consider OPA — the Open Policy Agent that is widely used in cloud-native environments. It provides a modern declarative language to define access control policies. In fact, WSO2 API Manager and WSO2 Identity Server both provide an OPA integration as a Policy Decision Engine. But it doesn’t address the fundamental problem. Rules build on facts, and the facts are managed outside the scope of the decision engine. Moreover, the very service that must be protected owns the data for its own protection.
Dreaming big
Allow me to dream a little bit about a potential solution. Identity Providers typically include a feature to manage groups of users. You can often assign roles to a group of users, such that every member of the group will automatically inherit the permissions from this role. What if we could look at it this way. Every project has a group of members, a group of owners, and a group of scrum masters. What if we could map those groups on the involvement roles in the project management system. We would only have to add the groups as a custom claim into the token. Moreover, we could simply apply the SCIM2 standard as an interface.
Think about it. There are many potential benefits. From a governance perspective, it would be so much better to have a single point of administration of permissions. Only when you have a complete overview, you can analyse and address undesired confluence of permissions, for instance. When someone moves job, you can revoke all his permissions. But there are also more practical benefits. Whenever the last member in an active “owner” group gets discharged, an alert could be automatically generated to trigger filling the vacancy. When someone is transferred to a new position, their memberships can be automatically scheduled for reassignment. When they go on holiday, access may be temporarily delegated. When a long-term illness hits, permissions can be reassigned. And best of all, no API will ever go unowned.
Closing thought
So, is Full Access Control feasible without breaking the bank and without losing agility? Well, yes, but perhaps not yet today. At least not in every organization for the full hundred percent. But you can undoubtedly come a long way, and, under certain conditions and with some effort, you can achieve it completely tomorrow. It might require some persistence and some hard work, you might have to cut some corners, or take some intermediate steps. But in the end, it will be well worth the effort. After all, every digital organization should evolve into a well-oiled machine, where security has become inherent.
Why not start today?
If you want to dive deeper, don’t be shy. We at Yenlo are here to help you. Just reach out.
