Main article: Advanced Hybrid RBAC
MidPoint is using a Role-Based Access Control (RBAC) principle to make provisioning more manageable. However the use of simple RBAC leads to a role explosion problem. Much more sophisticated approach is needed to make RBAC really useful. And that's exactly what midPoint has:
Assignment is a basic structural element of midPoint policy. Assignments define what should be (as opposed to links which describe what is). Assignments associate a user with roles and resource objects such as accounts. Traditional IDM systems has a very simple structure instead of assignment. It is mostly binary: either a user has a role or he does not. This can work for very simple cases but it fails miserably in more complex scenarios. However the assignment in midPoint is much more powerful. It contains activation and deactivation dates. It can be conditional. It can contain parameters for parametric roles. The consequence is that several assignments can be used to assign the same role to the same used at the same time.
But the assignment is even more powerful than that. Only a very naive IDM project expects that everything and everyone will comply to to rules (e.g. RBAC) and that there will be no exception. There are always exceptions. Assignments are a way to support such exceptions in systematic and elegant way. The assignments can make sure that the exceptions are recorded and properly managed. The assignment can specify attributes that are specific for a particular user. As assignment is a part of the policy, specifying attributes in assignment efficiently legalizes such exception. Think of the assignment as a personal role that every user has for himself. Adding assignments to a user can be subject to approvals exactly like adding a role (because even roles are added in assignments). Therefore the processes can be created to make sure that the exceptions does not get our of control.
There are many examples of IDM systems that have fallen into the technological traps and bound themselves to a bad standards or data formats. The way out of that trap is very difficult and in many cases it is a death sentence. We have been lucky enough to foresee the situation and we have successfully avoided such pitfalls.
Pragmatic SOA and REST
Service-Oriented Architecture (SOA) is a great idea. However this is usually not the case when it comes down to the implementation of SOA concepts. The deployers of SOA solutions too often forget about the basic principles of the software architecture which should be the crucial part of Service-Oriented Architecture. The widely spread idea is that the first and essential part of SOA is an Enterprise Service Bus (ESB) and that this single component is a solution to all the problems. It isn't. We can tell for sure. We have been there already. Several times.
We fully support SOA principles such as publishing of independent services which can be composed into a larger solutions. We just know first-hand that the techniques which are currently used to implement it are more than questionable. They way in which we support Service-Oriented Architecture is what we call pragmatic SOA. It is basically this:
- MidPoint is exposing vast majority of its functionality in the form of a network service which follows a well-defined interface.
- The service is exposed in several forms:
- Java API (local only)
- SOAP-based web service with WSDL definition
- HTTP-based RESTful service
- The specific interface definition is adapted to the form which is appropriate for each technology. E.g. We have Java classes for Java API and WSDL for SOAP. Shamefully REST does not have any way of formal interface definition therefore we at least have a textual description and examples.
- The functionality of all the interface forms is roughly equivalent - considering limitations of each technology.
- We try to follow standards (Java, WSDL) and existing conventions (REST) as much as practically possible.
- The interfaces follow a proper software engineering practice: none of them is designed especially for a specific case or architecture. They are generic. Universal.
- MidPoint can be used as a service in traditional ESB-driven Service-Oriented Architectures by the means of midPoint SOAP web service.
- MidPoint can be used as a service in Resource-Oriented Architectures (ROA) by the means of midPoint RESTful service.
- MidPoint can be used as an orchestrator for the purposes of identity integration.
Which in fact means that midPoint can be used in almost all the currently fashionable architectures as a first-class citizen. However midPoint is not bound to any particular integration architecture. It just follows the practical, pragmatic way, good engineering practices and common sense. That's the reason it works so well.