In this blog, I want to share some insights on how to tackle those challenges head-first.
Your typical model
If you’re in a microservices state of mind, chances are you’re thinking of different kind of entities as different resources. You would like to separate employees, customers, and suppliers, for instance. For each, you will adopt a different IAM solution. You’ll likely have some Active Directory for employees, perhaps a CIAM-system for customers, and a Procurement system that also keeps accounts for suppliers. And when you think a bit deeper, you can probably think of more resources that require a different approach – contractors, for instance. Conceptually, your resource model will likely look something like this.
Over the years, we’ve learned that this is a recipe for disappointment. A trained architect instantly notices this doesn’t scale. But that’s just the start. Allow me to explain exactly how to tackle this in a superior way. A way that supports any business model, including hospitals, governments and schools. To do so, we’ll first have to explore the problem a bit deeper.
Complexity in classification
The canonical problem with customers is widely discussed. For finance, it’s someone who pays the bill, for sales it’s someone who issues an order, for marketing it’s a qualified lead, and for operations and after-sales it’s someone who requires a product or service. Superficially, there’s not much of a difference. In practice, these different realities tend to work out quite differently. If only because the person who actually receives a present from your online store is not necessarily the one who bought it. Now try asking your stakeholders for how long your customer account should be kept alive. Do you want to welcome back a customer who returns after a year? Five years? Or would that be creepy, and do you prefer having them set up a fresh account instead. What about reusing their username? Do you keep it available only for them? Is that even possible? Chances are the answers you’ll collect will vary widely.
Complexity in employees
And these kinds of intricacies are just a start. The real problem is that any segmentation of user accounts tends to be flawed. Think about it. Employees and contractors are no distinct pools of people. There are many forms of contracts that are somewhere in-between. And these may differ per country where you’re active. So, perhaps classifying them as different ‘resources’ was not such a great idea after all. Similarly with suppliers. Are their employees working on your systems really different from your contractors? Well, I guess it depends on the kind of business you’re in. But if you, for instance, think about a truck driver for inbound logistics, the difference between your drivers collecting goods from your suppliers, or drivers working for your suppliers delivering goods to you is gradual. In fact, the same person my work as a driver for you one week, and as a driver for your supplier the other.
Complexity in customers
If you support a business-to-business channel, as a wholesaler, you’re probably familiar with customer-driven authorization. Employees of your customers get a named account, and different employees have different permissions in your store. A client-side administrator can be authorized to grant permissions to only his colleagues. This is relatively straightforward, as we’ve proven multiple times. But as soon as you start thinking about the individual who works for multiple clients at the same time and has different permissions with each. Or a business that is the result of a merger, and now has multiple identities with you, but a single procurement officer. Moreover, if you’re not only in wholesale, but also in retail – say you’re a utility or telecommunications provider – you have yet another complexity to take into account. This very procurement officer may very well be a retail customer of yours.
One additional, but closely related complexity is with your support staff. If you have a diverse client base, your users may need some help from time to time. In certain situations, it may be helpful for your support staff to use your website or mobile app from their perspective. So your employees need a special authorization to use the application for your customers on behalf of a specific customer for a limited time period. Not unusual. Yet difficult to manage when identities from separate domains are involved.
Complexity in students
It doesn’t end here. Schools and universities have students and teachers, sometimes also parents. Both students and teachers hop from school to school. After graduating, students may come back as teacher. Sometimes, while still student, they are assistant teacher at the same time. And regular teachers may well be following certain classes too. Oh, and before being admitted, universities can have various engagements with prospective students. They also need a user account so you can track them. And then there are the alumni. I told you that social relations of an organization never really are simple. And with the ongoing digitization, capturing more and more kinds of social relations in the digital world, your identity management becomes increasingly challenging.
Complexity in administration
Governments are another example. You can be pretty sure that a civil servant is a citizen at the same time. The administration interacts with natural persons – citizens, tourists, foreign workers, voters – and with people representing legal persons – a company, another government, an institution, a foundation, what have you. Of course, these people are natural persons too. Legal and natural persons commonly carry their own identification scheme, typically managed by different entities. Now, clearly, you do not want a tax advisor to use a different user account for each company he files taxes for. But should he also be able to use the same ID with his personal taxes? And if he is an independent contractor, would he use his private account to file taxes for his personal business, or his professional account? And if he needs a permit? Again, it’s difficult to make a clear cut between the different groups.
Complexity in cure and care
Doctors, nurses, patients, visitors, inspectors, pharmacologists, you get the picture. We’re all part of it from our birth to our death. The social graph of a hospital is highly convoluted indeed.
An improved model
If you need to design for these real-world complexities, separation of resources is not the best way to go. Over time, it will introduce more complexities than it solves. There are so many boundary cases to consider that it’s hard to get it right in the first place, and then you can be sure that future changes will become even harder to implement.
As often, abstraction is the solution. Look at this model.
Here, an identity (person, legal entity, or technical entity), can have any number of relationships of a certain kind – for different realities, if you want. And each can be managed independently. Think of the relationship as an identity classification with a mandatory start date and an optional end date. Next, you can assign a role to a relationship to grant certain authorization. You’ll also notice that two identities can be related as representative. This is also a kind of relationship – employee, executive, agent, guardian, delegate, and so on. You can catch a rule such as, Alice represents Bob as his delegate to file income taxes to the Tax Office. Similarly, Alice can represent Acme as their agent to manage their sales taxes. Moreover, Alice as Alice could be a member of the advisory panel of the same tax office. Clearly, every capacity will come with different permissions.
You will appreciate the extensibility of this model. It’s quite easy to include a Student relationship, or a Patient relationship, for that matter. You just have to add some logic. Moreover, it’s now easy to associate a relationship with its corresponding master data.
Making it work
Now you might wonder how this would work out in practice. Wouldn’t it be confusing to have so many capacities with a single identity? Not necessarily. Actually, this is one of the topics where the modern authorization standards can help you out. There are two approaches. First, during authentication, an application will issue a request to the identity provider for a specific set of scopes. Scopes will be related to the permissions of the relationship. Consequently, an identity provider will only generate an access token if the user has the right permissions. Furthermore, an application is registered with the identity provider. Therefore, the identity provider knows exactly what kind of token to provide, and what content to put into it. Effectively, an application will only receive the relevant identity information, using only relevant relationships (which would be just a single one, for most applications). In other words, the inherent complexity is hidden from application developers.
Making it shine
WSO2 Identity Server is a versatile product. You can effectively use it to cater for simple use cases at a large scale. You can also use it for advanced use cases, such as the ones discussed in this blog. You can go all the way to a unified Identity and Access Management system or start a bit simpler. After all, WSO2 Identity Server is designed as an integration product, with all the flexibility to cater gently for different use cases. Try stretching a typical CIAM product to implement some more advanced logic. Or IDentity-as-a-Service, for that matter. You’ll experience a lot of friction, at the very least.
The WSO2 product famously does not require you to adapt to its identity model. On the contrary. You can adapt the product to optimally suit your needs. And change it whenever your needs change. That’s powerful. That’s reassuring. And we’re here to guide you and avoid any unnecessary complexity. That’s also reassuring.
{{cta(’82e7cfae-e2c3-4a94-bd1f-33411c17f82e’,’justifycenter’)}}
