Basic idea of flexible authentication is described on Flexible Authentication page. Before we describe configuration of flexible authentication, we have to become acquainted with a few termterms.
Authentication module is basic building unit of flexible authentication. The easiest example of authentication module is classic login form, which we can find on every application. Login form contains field for username or email and password. Login form represent one authentication module, next modules can be authentication by LDAP, HTTP basic authentication, auhentication authentication via Identity Provider server, etc. Every Authentication module contains some configuration properties, which define configuration for this kind of authentication module.
Authentication sequence is made up of authentication modules, so it contains chain of authentication modules. Each of module have its order in chain and necessity for this sequence. Sequence is define by chanelchannel. Chanel represent Channel represents part of Midpoint, for which is valid this authentication sequence, for example GUI, REST service, etc. Also channel contains url suffix for this authentication sequence. So channel define, which authentication sequence will be used for http request.
We know next Flexible authentication knows following channels:
|Request servlet suffix||Channel/ws/rest||Note|
|model||3#rest||/actuator||Default one, represents GUI. No suffix specified.|
Channels for rest and actuator default don't create audit records about session creation or termination. You can turn on it via variable in System Configuration audit->eventRecording->recordSessionlessAccess.
Choosing of Authentication sequence
Midpoint receives HTTP request with URL 'http:localhost:8080/midpoint/actuator/metrics'. Midpoint obtains suffix 'actuator' from URL and it gets channel from table base-on suffix. Getted Obtained channel is used for searching default sequence for channel. Next midpoint initialize found authentication sequence. After successful authentication Midpoint sends request to actuator service.
Definition of HTTP SecQ module. The module is used for quasi-interative interactive log-in of a user by answering a set of security questions. The HTTP SecQ mechanism is similar to HTTP BASIC mechanism, but it is using security questions instead of password.
|Unique name of the authentication sequence. This name is fact a short identifier. It is supposed to give some idea about purpose of the sequence to system administrator. But it is not supposed to be used as a user-friendly label. Sequence name must be unique.||true||String|
|Free form description of the sequence (administrator comment).||false||String|
|Specification of channel for authentication sequence.||false||AuthenticationSequenceChannelType|
|Required assignment target. This authentication sequence is applicable only to users that have active assignment with this target (and relation). If the sequence is attempted on a user that does not have this assignment then the authentication will fail.||false||ObjectReferenceType|
|Required node group. This authentication sequence is applicable only to node group that have active assignment with this archetype.||false||ObjectReferenceType|
|Specification of authentication module in the sequence.||true||AuthenticationSequenceModuleType|
|Name (URI) of the channel.||true||String|
|Free form description (administrator comment).||false||String|
|Specifies whether this sequence is the default sequence for a specified channel. The default sequence will be chosen in case that specific sequence was not requested, e.g. by using URL suffix. If this element is not present and only a single sequence is defined for a channel, then such sequence is considered to be the default. If more than one sequence is specified then none of them is considered to be default. In that case this element must be used explicitly.||false||boolean|
|URL suffix that can be used to select this authentication sequence specifically.||falsetrue||String|
<sequence> <name>admin-gui-default</name> <description> Default GUI authentication sequence. We want to try company SSO, federation and internal. In that order. Just one of then need to be successful to let user in. </description> <channel> <channelId>http://midpoint.evolveum.com/xml/ns/public/modelcommon/channels-3#user</channelId> <default>true</default> <urlSuffix>default</urlSuffix> </channel> <nodeGroup oid="05b6933a-b7fc-4543-b8fa-fd8b278ff9ee" relation="org:default" type="c:ArchetypeType"/> <module> <name>mySamlSso</name> <order>30</order> <necessity>sufficient</necessity> </module> <module> <name>internalLoginForm</name> <order>20</order> <necessity>sufficient</necessity> </module> </sequence>
<sequence> <name>admin-gui-emergency</name> <description> Special GUI authentication sequence that is using just the internal user password. It is used only in emergency. It allows to skip SAML authentication cycles, e.g. in case that the SAML authentication is redirecting the browser incorrectly. </description> <channel> <channelId>http://midpoint.evolveum.com/xml/ns/public/modelcommon/channels-3#user</channelId> <default>false</default> <urlSuffix>emergency</urlSuffix> </channel> <requireAssignmentTarget oid="00000000-0000-0000-0000-000000000004" relation="org:default" type="c:RoleType"> <!-- Superuser --> </requireAssignmentTarget> <module> <name>internalLoginForm</name> <order>1</order> <necessity>sufficient</necessity> </module> </sequence>
- Configuration schema for flexible authentication is designed to be mostly complete. However, not all configuration options are currently supported.
- Flexible authentication is currently supported only for midPoint administration GUI. Only internal password authentication and SAML2 is officially supported. The rest of the functionality is considered to be experimental.
- OpenID Connect protocol is not supported yet.
- 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 configuration is global. Only global security policy can be used to configure the authentication (i.e. security policy referenced directly from system configuration object). Per-organization security policies or any other security policies cannot be used.
- Support for authentication module necessity is limited. We support only SUFFICIENT modules in 4.1.
- Authentication modules for SOAP web services are not supported because SOAP is deprecated and it will be removed soon.
- REST service supports HTTP basic authentication only. Distributed authetntication authentication protocols (OpenID Connect, SAML) are not supported yet. REST support for flexible authentication is experimental.
- 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.