Before we get into the contents of the discussion, we should get three basic terms straight:
- Claims are statements about a users, such as names, other identifiers, groups, roles, privileges or capabilities, which are understood by both partners of a Federation Relationship. Claims are used to make assignments between the Federation partners, for example to map a user of the supplier to a user account of the manufacturer, or a role to a user account.
- Constraints are restrictions, for example a limit for a maximum order value, defined for a user.
- Finally, roles are descriptions of functions (jobs, tasks) of users in organisations. One or more users may have the same role. Roles are used frequently in access management.
During one of the workshops on the European Identity Conference 2007 it was argued that claims and constraints might replace roles in future. On closer examination it becomes evident that a) constraints have, in many approaches of Role Management, been long existing and b) that roles are one of the most important issues for Constraints. In other words: The Role Management is an indispensable basis for Identity Federation.
Roles versus Constraints
When defining role models, Constraints – in this connection often called rules – are frequently used to reduce the complexity of role models. So instead of defining a number of buyer roles with varying order limits, you may also define (using an admittedly very theoretical example) one buyer role plus additional Constraints for maximum order value. This means that you can reduce the roles and at the same time rather exactly control authorizations and business processes.
In addition, Constraints are a flexible supplement for example to define additional restrictions on the basis of attributes which are stored in a directory related to a user.
Roles and Identity Federation
In connection with Identity Federation, roles are important to reduce the varying claims and thus the complexity of assignments. For many business processes, it is completely sufficient to map a role on an user account. In the context of this user account, subsequent processing is possible. This way, a manufacturer does not have to define an individual account for every user of a supplier , but just one account per role.
Here, too, Constraints are helpful because additional restrictions are easily defined without an inadequate administrative effort. Constraints, however, are not suitable to replace roles, because roles allow the merging of many users of the same type – from a Federation Relation point of view –, whereas Constraints aim at handling users in different ways.
So Constraints and Roles are not contradictory. Already today, they are commonly in connection with Role Management. And the same makes sense with Identity Federation.
Tips for proceeding
I would like to emphasize three aspects with regard to practical implementation:
- We need a reliable source of Constraints which can be accessed in a flexible way. As a suitable source we would recommend a central, trustable directory service.
- When modelling roles, Constraints should be used consequently to reduce the complexity of role models. Working with simple Constraints instead of defining many additional roles is the better way.
- This, however, starts from the assumption that these Constraints, for example under the name of “rules” – are able to be processed by the used applications such as provisioning solutions or within Federation solutions. The capability of handling Constraints (no matter under which designation) thus becomes an important factor in favour of a software solution.
No doubt: Constraints, roles and claims are not contradictory, but complement one another.