Authentication
Standard / Username and Password#
No extra actions needed to use it, it is available by default.
SAML#
Configuration steps:
- Configure Tomcat to use HTTPS (if needed).
- Fill properties:
|
|
- Generate Studio metadata and import in your Identity Provider
On your IDP:
- Configure Identity Provider to send attributes with assertion response.
- Check that Identity Provider configuration for Assertion Consumer Service URL and Logout Service URL is correct.
Important! SAML Response signature must include message and assertions!
Attributes Mapping#
SAML Response must contain following attributes:
- Name ID (this is used as user login)
- firstname
- lastname
- roles
When a user logs into Higson Studio, their account is automatically created in the system with an external status.
Roles#
- if higson.studio.security.token.generation.authentication.saml.roles-origin=saml is specified roles are taken from assertion response therefore Identity Provider must be configured to send it with response. internal means Studio will take roles from database instead of SAML assertion response to authorize user.
Active Directory#
- Fill properties:
|
|
Requirements for Access Directory User#
Login - not empty, min size: 1, max size: 200
First name - not empty, min size: 1
Last name - not empty, min size: 1
E-mail address - if empty Higson generates default e-mail consistent with schema: ’login@local.com’
Roles - min one role consistent with Higson role.
Roles defined in Active Directory must be compatible with roles in Higson structure. When a user logs into Higson Studio, their account is automatically created in the system with an external status.
Hierarchy of Roles in Higson#
MPP_ADMIN - Higson Administrator
MPP_USER - Higson User
MPP_USER_READONLY - Readonly Higson User \
It is possible to create own roles in AD but remember to create same roles in Higson structure. It’s necessary to proper authentication process.
CAS#
Configuration steps:
- Configure Tomcat to use HTTPS.
- Fill properties:
|
|
When logging in using CAS, you must configure the corresponding users on the Higson Studio side. Roles are defined and managed on the Higson Studio side.
A refresh token is a special type of access key used to automatically renew a user session without the need to log in again. It is used together with an access token. It is used to ensure user convenience, as it means that users do not have to constantly log in to the application.
The following properties define the lifetime of tokens:
higson.studio.security.token.generation.access-token-lifetime.unit=Minutes
higson.studio.security.token.generation.access-token-lifetime.value=5
higson.studio.security.token.generation.refresh-token-lifetime.unit=Minutes
higson.studio.security.token.generation.refresh-token-lifetime.value=7
The refresh token has a longer lifespan and is used to obtain a new access token. The access token is included in requests and enables authorized access to the API. Once the access token expires, the browser automatically uses the refresh token to retrieve a new access token. If the refresh token also expires, the user will be logged out of the system. Modifying the access token lifetime affects how often it needs to be refreshed — in other words, how frequently the system must generate a new access token. Meanwhile, the refresh token lifetime determines how long a user can remain logged in, that is, how long they can obtain new access tokens without having to log in again.
It’s important to remember that when an automatic logout occurs, any unsaved changes will be lost.
JWT Based Authentication (Runtime Token)#
It is set by default.
The property higson.security.jwt.secret-key must be set in both Studio’s and client’s side
Runtime Rest application with same string sequence:
|
|
You can generate a new token in Studio. A view to see all existing tokens and to generate a new one can be found in Menu’s Tools tab.
When creating a new token, you can specify the expiry date. Admin users may also specify a user that a newly generated token will be assigned to.
To use generated token in REST API calls, you need to add an Authorization Header with the standard bearer format, such as
Authorization: Bearer your_jwt_token
Basic Authentication#
|
|
You can choose from the following password encoder security algorithms: bCrypt (default) or Pbkdf2
To select a Pbkdf2 algorithm, you must set higson.security.basic.password-encoder=Pbkdf2 property in the application.properties
You can choose the complexity of BCrypt algorithm by setting a property higson.security.basic.bcrypt.complexity with values
between 4 and 31 are accepted, 5 is used by default. Be careful, since the bigger the value the safer algorithm is, but the
performance impact is also increasing.
Active Directory#
|
|