Flexible Authentication
|
Flexible authentication feature
This page is an introduction to Flexible authentication midPoint feature.
Please see the feature page for more details.
|
Authentication used to be quite simple back in 20th century. Username and password was all that was needed. The world is a different place now. There are single sign-on (SSO) systems, multi-factor authentication (MFA) mechanisms, authentication sequences, social login, identity federations and many more forms of authentication. Simple username and password is just not enough anymore.
MidPoint 4.1 introduced a concept of flexible authentication. MidPoint authentication mechanisms can be configured in a variety of ways. The usual password-based authentication is still the default authentication mechanism. However, many authentication mechanisms can be configured and combined in a flexible way. There are several authentication modules that are integral part of midPoint. Those modules can be combined into sequences, associated with user interface or the REST service and so on. There are many options to choose from.
Multi-Factor Authentication And Similar Mechanisms
MidPoint has a flexible authentication system. However, midPoint is still an identity management and governance system. MidPoint is not an authentication server, it is not an access management system, and it is not identity provider. Therefore, the flexible authentication of midPoint is designed to handle the client-side authentication use-cases. Such as:
-
MidPoint being a client (a.k.a. service provider) of access management systems, single sign-on systems or identity federations that are using standard protocols (SAML or OpenID Connect).
-
MidPoint using traditional password-based authentication, validating passwords using its own identity repository.
-
MidPoint using traditional password-based authentication, validating passwords using a directory server (LDAP or Active Directory)
-
MidPoint using SAML or OpenID Connect as a primary authentication mechanism, but having an emergency option for administrator log-in using a simple password-based authentication.
-
Special multi-factor authentication scenarios, mostly for purposes of credential recovery.
Although some multi-factor authentication scenarios are supported (see below), full support for multi-factor authentication (MFA), adaptive or risk-based authentication or any similar mechanism is not the goal of flexible authentication feature. There are many access management systems, single sign-on mechanisms and sophisticated authentication servers that can do that much better that midPoint ever could. MidPoint is an identity management and governance system. We see no point in reinventing the authentication wheel. Therefore, the primary goal of flexible authentication feature in midPoint is to allow straightforward and reliable integration with existing authentication providers. Of course, midPoint is the right tool to manage multi-factor authentication credentials. MidPoint is designed to distribute passwords, PINs, asymmetric key pairs, public keys, certificates, shared secrets, seeds and any other authentication credentials. However, it is not a responsibility of midPoint to validate them. Other systems should do that.
This is also a reason that midPoint authentication modules are directly "pluggable". Our approach is to support standard digital identity protocols such as SAML or OpenID Connect. Therefore, need for a ZOO of third-party authentication modules is greatly reduced. Making the modules non-pluggable means that our authentication system can be simpler, more straightforward and seamlessly integrated with the ordinary midPoint infrastructure.
Therefore, following approach is recommended to use multi-factor authentication (MFA) with midPoint:
-
Set up an access management (AM) system, single sign-on (SSO) server or identity provider (IdP) that support multi-factor authentication mechanism. Enable a standard protocol on the server (e.g. SAML).
-
Set up midPoint to be a client (service provider) of that authentication server.
-
(Optional) Set up midPoint to manage authentication credentials that the authentication server is using. Currently, midPoint can only manage the passwords. But there are plans to extend that functionality in the future.
Overall, it is usually not a good idea to set up multi-factor authentication in midPoint - except for few special cases:
-
User registration: Users that are self-registered need to be verified in some way. The usual routine is to verify e-mail address provided by the user by sending a magic link to provided e-mail address. This is technically implemented as an authentication in midPoint. This can be supplemented by additional authentication steps, e.g. sending test message to user’s phone (provided that the required authentication module is available). More authentication steps mean (technically) that there is multi-factor authentication sequence.
-
Credentials recovery: The notorious case of forgotten password. Perhaps the simplest method to recover a lost password is magic link sent to user’s e-mail. However, there may be variety of other mechanisms: security questions, asking for user’s birthday or some similar personal detail, referring to a different identity provider … each deployment has a slightly different combination of the techniques. Once again, this is (technically) implemented as a multi-factor authentication sequence in midPoint.
-
Identifier recovery: The case of lost username, less infamous, yet still interesting. This is once again implemented as a sequence of several authentication modules. Even though it does not really look like authentication, it is technically a multi-factor authentication sequence.
This is not what you would consider as "authentication", yet authentication it is. MidPoint provides multi-factor authentication capabilities that are targeted at use cases that do not look very much like authentication. These are all identity management special cases, cases that are not handled well by other systems, cases where midpoint can add significant value. In such cases, interaction flow is much different that the usual day-to-day authentication flow.
Overall, we recommend to use specialized dedicated authentication system for the usual day-to-day authentication of users. There is a lot of access management, single sign-on and authentication servers that can support variety of authentication systems and provide adaptive and risk-based authentication. MidPoint would be happy to rely on such authentication, using SAML or OpenID Connect protocols - as a client. However, there are special cases where the authentication flow has to be different. MidPoint can shine with its flexible authentication in such cases, even if it includes multiple steps using multiple authentication factors.
Configuration
Please see Flexible Authentication Configuration for configuration details.
Implementation Notes
Flexible authentication mechanism was implemented by using a custom code that is very roughly based on Spring Security concepts. We have started with Spring Security in midPoint 3.x and the plan was to reuse it also for flexible authentication. However, we have found that Spring Security is too simplistic and too rigid for our needs. It was very hard to reconfigure authentication without system restart (and even rebuild), it was difficult to implement authentication sequences and so on. Therefore, we have ended up with a hybrid of some Spring Security components and concepts with our own code. It is quite likely that the last remains of Spring Security will disappear entirely in future midPoint versions.
Which also means that the unofficial way to use Spring Security modules with midPoint is unlikely to work with midPoint.
Limitations
Those are the limitations of current implementation of flexible authentication mechanisms.
-
Configuration schema for flexible authentication is designed to be mostly complete. However, not all configuration options are currently supported.
-
Social login functionality is not supported yet.
-
It is unlikely that midPoint could be used as a member of identity federation directly. Identity proxy or a similar technology may be needed.
-
Authentication modules for SOAP web services are not supported because SOAP is deprecated, and will be removed soon.
-
REST service supports HTTP basic authentication and OpenID Connect authentication.
-
Even though the authentication configuration often suggests that there may be more than one instances of credentials (password, nonce), midPoint currently supports only a single password, single nonce and a single set of security questions. Multiple credentials are not supported. The reason for mentioning credential names the configuration schema is to have ability to extend midPoint functionality in the future.
The implementation can be improved in the future. Please see Flexible Authentication Improvements for details.
See Also
Compliance
This feature is related to the following compliance frameworks: