Authentication design / Authorization in IdM

• simple "if" deciding between LDAP or local log-in
• marking the log-in the in the end system

The user will always log in with the log-in from CzechIdm The use of log-in from the administered system is not possible since more identities can have access to the account on the administered system.

Once the user logs in with his log-in and password (it doesn´t matter whether the basic method is used or a token is requested), CzechIdM will proceed to the internal verification of the entered log-in data.

Log-in and password verification take place against the following data sources:

• local CzechIdM database - implicit behavior
• authentication against the administered system (e.g. LDAP, MS AD, etc.) - the connector must support authentication
• class implementing the user´s authentication - serves for the authentication implementation itself, e.g. against an external relation database or for a request for Radius server, etc.

The default state of log-in and password verification is against the local database CzechIdM. The administrator may configure manually other sources against which he will carry out the verification.

• The configuration enables to choose more sources of authentication.
• The sources order in the authentication chain is respected.
• With each authentication source, it is possible to set up how the whole authentication processing should behave after the processing of the source in question

Response to the authentication result against a particular source of data:

• requisite - the source failure will cause an immediate termination of the authentication chain with the error = the user is not logged in
• required - the source failure will cause error return after the processing of other ways of authentication
• sufficient - successful verification will immediately interrupt the authentication chain with a positive result
• optional - if the source in the authentication chain is the only one, then it is its return deciding whether the user will be authenticated In case there are more sources in the authentication chain, then the result is ignored (but will be performed).

Everything will be processed using "authenticators" that will carry the information on the number, the response to the result, etc. One authentication chain will be implemented which will be put together dynamically from these authenticators. In the future, the request for more chains may arise (e.g. a different chain for basic authentication for rest, and another one for the request for oauth2 token).