This page describes a feature planned for future midPoint versions.
This feature is roughly designed and it was evaluated as feasible. However, there is currently no specific plan when it will be implemented because there is no funding for this development yet. In case that you are interested in supporting development of this feature, please consider activating midPoint Platform subscription.
Currently the only "official" authentication in midPoint is authentication based on internal midPoint passwords. MidPoint can in fact be configured to perform authentication based on external LDAP server, Active Directory, CAS or variety of other systems. But this is not an official functionality and the support is limited only to a couple of special cases and it requires a special subscription.
The reason for this is that midPoint does not have internal flexible authentication mechanism. The current authentication modules are mostly just a side-effect of using Spring Security in midPoint internally. So Spring Security authentication modules can be (ab)used in midPoint. But this is not an official feature. It is rather something that was endorsed and co-developed by midPoint community without much of official support form Evolveum. This approach works for some cases. But it far from being ideal. E.g. it requires custom build of midPoint, authentication cannot be easily re-configured, it is not integrated with resources (e.g. username translation cannot be used), last login information is not properly recorded, account lockout may not be properly enforced and so on.
What we need:
- Authentication mechanism that would be better integrated with midPoint configuration. E.g. authentication that can be configured in the same way as midPoint password policies are configured (in midPoint objects).
- Flexible authentication, e.g. different authentication requirements for self-service and administration parts of midPoint user interface.
- Common processing code for all authentication options. So last login times will be recorded, policies will be properly enforced and so on.
- Authentication that can take advantage of account linking. MidPoint knows that Active Directory account "foo" actually belongs to user X12345. Therefore the user can log in with his Active Directory account foo, but midPoint will display self service for user X12345.
- Make sure that the old password provided in self-service password reset is checked on the particular resource where authentication is delegated.
- (Optional) There is an authentication function in ConnId connectors. This function might be used. This will avoid duplication of connectors and authentication modules. E.g. Active Directory connector may take care of both identity management and authentication. The same configuration can be reused.
- (Optional) Authentication module chaining. More than one module may be needed to perform an authentication.
We need special "midPoint" authentication mechanism - or rather meta-mechanism. This special code will read the configuration and it will figure out which authentication module to use. The result may be internal midPoint authentication (default), Spring Security authentication module or (optionally) connector-based authentication. After the authentication there again needs to be a common processing to map the authentication identity to midPoint user, check the policies, write proper audit trail and so on.
This needs a rework of midPoint authentication code. MidPoint cannot use Spring Security directly, as midPoint obviously needs more flexibility that Spring Security provides by default. Spring Security modules would be used indirectly. And there may be authentication flows that go around Spring Security completely, e.g. the case of connector-based authentication.