For many years, visionaries have argued that companies should value information as a factor on par with labor, land and capital. And if you look at recent economic success stories –think of Google, Netflix, über, Facebook, WeChat, Amazon and the likes– you have to admit that there is some merit to this idea. Today, many companies are in the process of positioning themselves in the information value chain. We know this process by the name of “digital transformation”. Owning valuable information is key to getting a strong position, at the same time, not having access to such information is a major risk factor.
With new information technologies, such as machine learning, processing data to uncover new information from existing sources has become in reach of anyone with access to data. Hence, data has become potentially much more valuable than ever before. Consequently, companies which harvest a lot of data, and use it to their advantage, may suddenly discover a precious information goldmine.
It goes without saying that with the rise in strategic importance of data, the control of access to this data has grown in importance. Only authorized people may have access, and only for as long as they’re authorized.
Another main driver for identity governance are the privacy laws and regulations which increasingly constrain companies in what data they can collect, who is allowed to access it in which context, and for how long it may be kept.
Traditionally, identity and access management engagements tended to focus on single sign-on technologies. Nowadays, we increasingly find an interest in getting control over data access. That’s were identity governance comes in.
Governing the Provisioning stream
We all know that in an ideal world, every user would be registered only once, and each and every application would have some kind of access to this single identity source to enable authentication and establish entitlements (aka authorization). If you live in such an ideal world, I salute you. More commonly, enterprises face the challenge of distributed identity stacks. Internal employees are registered in a different user store than employees from business partners; different business units each run their own registry, customers are in yet another identity store, maybe different ones for different countries, and suppliers are in yet another realm. There are no identity management procedures for, let’s say, the upgrading of a supplier to a business partner; or the hiring of an employee of a business partner. And we’re not even considering mergers and acquisitions.
To make things more interesting, many SaaS-providers run their own identity management systems, forcing businesses to create accounts for their employees at those sites (and revoking them when an employee leaves, or gets transferred). And many legacy systems still run their own user database. Not to mention that the application portfolio –SaaS or not– is changing all the time.
When you look at the source of the identities, there is another level of complexity. There are commonly different silos of administration for customers (in CRM systems), employees (in HR systems) and suppliers (in SRM systems, Procurement systems, or Purchasing systems). This is where the business manages the lifecycle of its relationships. Obviously, those independently managed systems should be kept in sync with the identity management system. Sometimes, it is also the other way around, where the business has an interest in how often, or what for a digital identity is used. Or even more elementary, when there is a self-service option for users to create and manage their own accounts. It makes sense, right, when you change your email address in your account details that you expect your next mailing at your new address.
At Yenlo, we advocate a single point of control as the second best alternative to having a single source for identities. With a single point of control, you tunnel the traffic from the business systems towards the different identity stores over an Identity Integration Bus. It is on the bus where you can enforce your policies. It’s exactly this kind of structuring of your problem space you need, in order to bring your identity governance solution.
Governing Access
Once you’re on top of identity management, your next challenge is the governance of access control policies. No matter if you’re using role-based access control, a hierarchical group structure, or fine-grained access rules, enforcement can be a headache. Especially when you’re facing advanced business logic, such as “basic authentication required when on the intranet, two-step authentication everywhere else”. Or, similarly, strong authentication is required to buy goods totalling over a 100 dollar. Or, perhaps even more salient: “A service provider may only access data of a customer with his prior consent”. There are many, many more examples of specific qualifications we see in practice. Security clearance level, project assignment, geographical location, number of years in service, specific certification, and sometimes even combinations of those. There are so many facts you can potentially check as part of advanced access control logic.
Traditional identity and access management products very much rely on the implementation of access control logic in business systems and databases. This presents another violation of the single-point-of-control principle. After all, business systems are under control of their respective owners.
Fortunately, there is an easy way out. With your identity integration bus in place, you already manage in which identity management systems a particular actor gets defined. Obviously, without a user account in place, you can be sure there is no access to all the system of interest that rely in this identity provider. Concretely, if an employee has no account at Salesforce.com, you can safely assume he will have no access to your sales pipeline. As a second tier, you can keep using your identity management systems to determine whether a certain user is entitled to access a specific application, based on his business role. It is pretty straightforward to test compliance. The management of the access control logic, namely assigning roles to users, can still be centralized, and updates can simply be tunnelled over your identity integration bus. You only have to close some backdoors.
Now suppose you face advanced access control logic, like the ones mentioned above. You will probably recognize that such intelligent rules typically apply to a accessing a specific application function, or a specific case, rather than access to an application per se. Here, we see an interesting new paradigm taking hold. Businesses are increasingly looking at their API Gateway as an access policy enforcement point. After all, an API Gateway is a gatekeeper to your resources, so this should be an ideal candidate to enforce your access control policy. And it is. The main thing you have to ensure is that the API Gateway has access to the facts your access control rules are built upon. This could be as simple as adding them as claims in an access token.
At this point, you might be wondering how you can make an API Gateway and an Identity Integration Bus work together. You’re probably right that this can be a major challenge. However, with the WSO2 platform, it actually is a breeze. What you need to do is set up a joint policy decision point. This way, the Identity Provider will use the same decisioning service to grant users access to an application as the API Gateway will use to grant the same users access to resources through APIs. As a matter of fact, the Identity Integration Bus can act as a Identity Federation Hub, such that the API Gateway can refer to different identity providers with different applications or groups of users – just like you would do in the provisioning chain. This is hybrid integration at its best. And, you know, WSO2 has been practicing this long before Gartner created the hype. How cool is that.
Final thoughts
From an architectural perspective, an Identity Integration Bus such as the one in WSO2 Identity Server, brings the decoupling of Identity Consumers and Identity Providers. This allows you to isolate changes, which brings agility and robustness to your change processes. With that, a change of Identity Provider will become less burdensome. So if you find yourself locked in to a product you don’t want to continue anymore, putting an Identity Integration Bus in-between is often a great strategy.
But wait, aren’t you trading the devil for beelzebub here? No, you’re most definitely not. You won’t find yourself locked-in into an Identity Integration Bus. Replacing it with another one can be a smooth, gradual change. In fact, there is no reason why you can’t have two busses running happily in parallel. Bus replacement is a process of setting up a new trust with existing identity providers, and one-by-one transferal of your identity consumers from one bus to another. As long as you stick to open standards, which is a good idea anyway, you’re free to move.
One of the main benefits of having a single-point-of-control is that this offers an ideal option to tap the traffic in an audit trail. Think about it. All the changes that are provisioned, all the authentication requests and all the API invocations are handled are orchestrated on your identity bus. Without any exception. With this bus in place, you can really be on top of your data access, and, perhaps more pressing, satisfy authorities with reliable audit data. GDPR anybody?
Obviously, there can be many more data access scenarios to take into consideration. In this post we’ve only discussed a few. If you have any particular concerns, please don’t hesitate to share your challenge with us. We’d be glad to be of help.
