Identity Management and CRM

The use of digital identities for internet users has been discussed in many places. And plenty solutions have been developed. There are lots of identity providers that offer (open) standards based digital identities that can be reused.
For companies the use of digital identities is only part of the problem, the use of external identities is just becoming a necessity.

Apart from offering access for external identities, organisations also have to cope with the internal identities of their customers. The more (legacy) backoffice systems organisations use, the more difficulty they have in identifying the value of their customers. Nothing new here: this problem is solved in Customer Relation Management (CRM) and Master Data Management (MDM): we create a 'Golden Record', a unique internal representation of a customer, that is related to all coupled internal backend systems.

Master Data Management is an area with specific problems. How do you connect customer accounts in different backend systems with different identifiers. Backend1 customer A1 can be the same as Backend2 customer R2D2 and may not at all be Backend3 customer A1, but ASDFG9 instead. Master Data Management uses intelligent rules engines to connect Id's and knows some trics, like deduplication. I will not go into detail (I don't know this kind of process well enough).

In a sense both identity related problems look alike, although they are mirrored. Let me show it in a simple picture and await your reactions...:

RBAC limitations in SOA

For a few years we have been working within a SOA environment and we implemented some form of the RBAC security paradigm. But since a few iterations of our SOA we feel that we arrive at the limits of RBAC. RBAC is fine within a single security domain, like an application, but as soon as you cross your security borders, like you will do in a SOA, you run against problems.

Some RBAC limitations in SOA

• In RBAC you still have to manage every user account and bind these accounts to roles. Unknown accounts can only be linked to a default role, like guest or customer. But users coming in through the Internet channel are not only guests or customers, but they can also be employees, partners, external service providers, you name it. There may be plenty accounts you don't want to manage, because they don’t belong to your security domain. Unless you manage different portals for different roles and have some form of identity management within the portal environment in place, RBAC is of no use.
  Federation could be a solution, but that only limits interaction possibilities to trusted partners you federate with. Besides, most federeation solutions use shadow accounts within the security domains, thereby creating a new identity management problem because all duiplication. Silly, but if you want RBAC, you pay for it…


• RBAC has a problem with the concept of context. If someone has a role, then he will get the permissions associated with that role. Automatically. There is no restriction in place based on the concept of context. A context could be the channel used (internet, lan), time of day, legal entity etc. An account using a wireless home PC might not deserve the same permissions as the same account in an office using a centrally managed workplace. But such a concept does not exist in RBAC terms (unless you define lots of extra roles). RBAC must always be complemented with a rule-based access control function.


• Another big objection (but that is not specifically SOA) is that there is no possibility for user profiling. Meaning authorisation based on the skills of an employees instead of the single fact that the user is connected to a role. RBAC doesn’t know the difference between junior or senior employees within the same role. Unless you define separate roles. And creating duplicate roles is not why you implement RBAC.


• Another problem (also not specifically SOA): role mining. Have you ever tried mining roles? How many roles have you identified? How many unique roles are absolutely necessary? Often mining is an useless excercise. But without mining roles it is hardly possible to define the necessary authorizations. Or is the role the object that you want to manage?

There are more issues, probably, but for us this was sufficient to declare RBAC ‘Old School’. We will continue to apply RBAC for some specific uses, but we will not implement RBAC as a dogma and certainly not within our SOA. We are studying new authorization paradigms, probably using the SAML Claims mechanism.
Identity management will be replaced by identity Provisioning and identity management will no longer be core business for most organizations. Access Control will stay core business, but no longer based on the user part and will also no longer be based on roles.