READ
, CREATE
, UPDATE
, DELETE
IDENTITY
, ROLE
IDENTITY_READ
, ROLE_CREATE
. Authority is granted to identity by authentication.API access requires the user to be authenticated, excluding a few public endpoints. We can divide the sign in into two parts:
Authentication is implemented through a request filterchain. The filters must always follow specified behavior:
In reality there is only one authentication servlet filter - AuthenticationFilter
. Others filters are Spring beans implementing IdmAuthenticationFilter
interface. An exception in filters is the ExtendExpirationFilter
, which is another servlet filter handling the extension of expiration date of JWT tokens. This filter also controls possible exceptions in authentication flow.
There are 2 endpoints for successful user login:
And one endpoint for user logout:
Filter do not check authorization or user's permissions, just validate the request data, transform these and pass them to Authentication Managers. There are following filters in IdM core (the core module):
idm.sec.core.authentication-filter.core-sso-authentication-filter.enabled=true
User authorization is checked on the API endpoint layer and enforced by Spring Security. The content of IdM JWT:
All IdM JWT tokens are signed using HMAC256 algorithm. The symmetric encryption key is configuration property of CzechIdM, stored as "idm.sec.security.jwt.secret.token". Default token expiration time is 10 hours (idm.sec.security.jwt.expirationTimeout). JWT tokens are persisted in database (IdmToken
entity) with assigned authorities. When identity is logged out, token is disabled. Disabled and expired tokens are purged periodically by internal scheduled task.
Backend of CzechIdM supports immediate detection of user's authorization change. Each modification type is implemented as application event processor, for further details please check the source code and tests :) When user's authorization changes, then persisted tokens, which user owns, are disabled ⇒ user is logged out. Types of modifications:
TokenManager
is used for creating IdM tokens. Token can be created for different purpose (token type). When token is used, can be disabled (e.g. logout, one time usage).
By default both frontend (FE) and backend (BE) automatically extend the expiration of IdM JWT. In case of successful GET request on API, the token expiration is extended on BE and passed in HTTP response (watch out for CORS, has to be explicitly allowed, since the HTTP header is called "CIDMST"). FE (RestApiService.js
) automatically disassembles the response looking for auth. token. If token is present, it is set as new token which shall be used for new API requests (done in App.js
). Expiration is extended in one minute window - when token has expiration at least one minute older than new one (prevent to persist token every api call).
Developer tip: do not trust the console, especially while working with promises:
static printHeadersOK(response) { console.log(response.headers.get('CIDMST')); prints header value } static printHeadersWRONG(response) { console.log(response.headers); // prints '{}', object looks empty }
@since 10.5.0
User with authority IDENTITY_SWITCHUSER
can login as different user. Feature is usable for checking application behavior under selected user (e.g. helpdesk). Logged user needs to have permission SWITCHUSER
to select target user.
Feature is available from user main menu in application - any other active user can be selected and currently logged user will be logged as selected used.
Currently logged user token (see above) is filled with selected user authorities - original user is preserved as token owner. Return back (logout) to originally logged user is available from user main menu too.
@since 10.5.0
When password is reseted (or generated), then password change can be enforced, after the first password usage (after the first user login). User is redirected to password change form and password has to be changed before user can continue to work with application.
SSO support on FE is implemented by issuing the internal IdM JWT without the need to type in user's credentials. This is done by sending a "prerequest" onto secured /authentication/remote-auth endpoint, accessible only to authenticated users. The authentication itself must be done in one of auth filters.
We expect either HTTP header or Cookie to be the bearer of the remote authentication data. When the user accesses IdM, FE first tries to sign him in using the remote-auth
. The remote-auth
attempt is done only on first access to CzechIdM, token expiration, authority change or user login.
SSO authentication to AD domain can be configured with the help of SsoIdmAuthenticationFilter and Apache web server, which is installed in front of IdM. For more details about SSO configuration see SSO install guide.