Provisioning is, without any doubt, the key feature of any IdM system. Without it, the IdM won’t be able to fulfil its primary role – aggregate all identities and other relevant objects (group, roles, …) and then distribute them to all systems and services where they are needed. This blog will cover several types of provisioning and related topics, and we will see how midPoint can help in various situations.
Just-in-time provisioning
Just-in-time provisioning has a prominent role in academia thanks to academic identity federations like InCommon and eduGAIN. Just-in-time provisioning means a user’s account is created when needed, which typically is when a user is signing in to the service. In academia, this is achieved by using an Identity Provider, which is a component combining access management and single sign-on (SSO) capabilities. SAML2 protocol is currently used the most, but OpenID Connect (OIDC) popularity is rising each day.
We won’t be covering how SAML2 and OIDC works and neither their differences. Instead, we will focus on integrating an identity management system with access management systems in general. Access management requires access to data about users. It has to verify user authentication and be able to query additional attributes of the users (name, e-mail, entitlements, …) These attributes can be delivered using the protocols mentioned above to services which a user is accessing. Service can use obtained data to create or update local user account on the service. Just-in-time provisioning is as simple as that.
Authorization
A careful reader may notice that we had omitted authorization so far. In the simple case described, it is up to the service to make the authorization decision based on the obtained attributes. This principle is used typically in a federated environment, where there are usually too many services to handle individually. Also, the distributed nature of the environment complicates other approaches. We can configure what attributes will be released, which is far more complex topic than it initially seems. Due to the privacy protection laws, we need to know what data are stored in the IdM, their purpose, a legal base for their storage and where they might be provisioned to. Within midPrivacy initiative, Evolveum is continuously improving midPoint capabilities to handle metadata for several use-cases, including supporting privacy-preserving features. The ultimate goal is to have such metadata tied to the primary attributes of users and be able to use them consistently across various use-cases, where just-in-time provisioning is clearly one of them.
Attribute release aside, there is one more thing that we can do for authorization. For services that we know, typically local services within own institution, the access management can decide if a particular user is authorized to sign in to a service or not. The IdM is the ideal source of such information because it contains all information about roles, groups and accesses. There are several benefits of making the decision centrally instead of deciding on a service level based on attributes. The first one is aggregating information in a single place, which can help with internal audits or can be used as a tool for helpdesk that can verify accesses of any user. The second one is user experience. Having authorization decisions on a central level enables consistent user experience in case access is denied. Furthermore, users can be pointed out to possible solutions. For example, offer them a link where they can apply for access. Access requests and approvals are features that identity management can also handle. You can check Evolveum Docs for ideas.
Just in case provisioning
Just in time provisioning also have its own disadvantages. Accounts can be created or updated only when a user is signing in. Deleting accounts is practically impossible because users won’t typically sign in to the service when their account is no longer valid there. Not having regular updates might lower user experience of using services where users are interacting with each other. Without updates there may be old data that are no longer valid.
These disadvantages can be overcome with just in case provisioning. On these terms, the central identity management system has all information about users and their accounts and accesses. Therefore, it can provision any change immediately when it occurres. MidPoint provisioning is doing precisely that. The whole midPoint, including provisioning, is based on delta updates. Each delta contains a changeset on a single object, which is immediately processed, and derived provisioning operations are immediately executed. Thanks to that, you can be sure that any simple operation performed in midPoint GUI or via REST API is provisioned to resources by the time you get the response from GUI or API. This approach addresses the typical doubt that some people are having about just in time provisioning, which is its speed in comparison with just in time strategy. Complex operations which affect multiple objects are processed in the background using tasks. The reason for that is the operation may take even several hours or even days to complete if it is complex enough. The tasks allowed us to monitor the progress of the execution and also to optimize it. MidPoint supports parallel execution of a task in multiple threads or even processing a task on multiple nodes, which might scale the processing to fit the requirements.
In the second part of this blog post we will talk about provisioning performance, messaging and reconciliation.