Secure Access is used for authenticating users to Matrix42 Core, Pro and IGA solutions and Self-Service. 

With Secure Access, you can securely authenticate different types of users when logging into:

1. Matrix42 Core, Pro and IGA Self-Service
2. Matrix42 Core, Pro and IGA Solutions (like IGA, ITSM etc.)

You can have several different authentication methods in use simultaneously, and users can access to different services or solutions based on selected authentication.  

It is also used for monitoring malicious activity during the authentication, and therefore brute force attack and click-jacking protections are enabled as default.  

Login Page

All Matrix42 Core, Pro and IGA solutions use a common login page. The login page is used to sign in to Matrix42 Core, Pro and IGA Self-Service and solutions. 

Depending on which authentication protocols are used (configurable), separate tabs for (company) login and rest of the authentication methods are displayed.

The background picture and logo in the middle of the login screen can be changed according to customer designs. In the screenshots below, the Matrix42 logo and default background picture are used. These can be changed only from ESA host, so if you don't have access there, you need to ask Matrix42 to do this change according this guidance: Configure themes for ESA

Language options

Users have the option to change the default language to another one by choosing it from the drop-down menu at the top right corner.

Default languages are: English, Suomi, Svenska and Deutsch.
Available languages are: English, Finnish, German, Swedish, Polish, Croatian, Czech, Danish, Dutch, Estonian, French, Italian, Latvian, Lithuanian, Norwegian, Russian, Spanish and Turkish.

Admin consoles
When defining which users are able to enter the login page, configure the provisioning task for authentication in the Service Management platform. 

Authentication configuration only requires further modifications when the authentication protocols are changed or new ones are taken into use.


Authentication protocol also needs to be configured in Secure Access admin console, where also mappings for authentication are defined. For example, see: https://<your instance url>/auth/admin  

Secure Access (ESA) is a rebranding of Keycloak (https://www.keycloak.org), which is an Open Source application that provides authentication services. 

It has been customized by Matrix42 as follows: 

• Login screens are replaced
• Custom authenticators provide access to Matrix42 Core, Pro and IGA solutions.

Secure Access has the following components:

Apache

An Apache HTTP Server is used by Matrix42 Core, Pro and IGA to be a proxy to all Matrix42 Core, Pro and IGA solutions. When a user opens a browser and types the URL of a solution provided by Matrix42 Core, Pro and IGA, the request is sent to the Apache Server. If the request is authorized (user has entered their credentials correctly), it is forwarded to the Matrix42 Core, Pro and IGA solution user is trying to access (for example: ITSM, ESS, IGA).

ESA

Secure Access provides an admin console, which you can use configure specific requirements for users to log into Matrix42 Core, Pro and IGA solutions. In the admin console, it is possible to configure what information will be extracted from the Identity Provider (IdP) and what information is sent to Matrix42 Core, Pro and IGA solution (for example: Self-Service, ITSM, IGA etc.).

ESA Database

Secure Access uses a PostgreSQL database to store customer specific configurations and a summary of information of the users that have logged into Matrix42 Core, Pro and IGA Solutions.

Each customer in Matrix42 Cloud environment, whether is a dedicated or a private environment, has its own dedicated Apache HTTP server, which has been configured to use Shibboleth (https://www.shibboleth.net) as its service provider. Keycloak acts as a proxy of the real identity provider which can be Azure, AD, OpenLDAP or similar solution.

When a user types the URL of an Matrix42 Core, Pro and IGA application, the request is directed towards the customer's Apache HTTP server via a DNS entry. This behavior is same whether the environment is running as a dedicated or a private environment.  The image below shows a dedicated cloud environment, which has been allocated to one specific customer/tenant:

Each customer's Apache HTTP server is configured to redirect unauthenticated requests towards Keycloak (ESA), which will handle the authentication. The authentication is done by either:

• Presenting its own login screen 
  • This is done if the customer is using AD/LDAP or if the user's credentials are stored locally in the ESM
• Redirecting the user's browser to the login screen provided by Azure.

If a customer is using Azure or ADFS, Keycloak (ESA) can be configured to allow Single Sign-On (SSO). In this situation, a user doesn't need to write his login credentials again if he has done it already in an approved way. For example, the user has turned on their laptop, which has been configured to authenticate with Azure/ADFS on startup.

ESA can contain multiple different realms with own authentication methods. For example internal users can user own authentication method and external users can you their own. 

Monitoring
Secure Access is monitored in Matrix42 centralized monitoring system. Matrix42 has multiple sensors per application, to guarantee that if there is a problem in any of the applications in Matrix42 Cloud, the monitoring system will generate an alarm and the problem will be investigated as soon as possible.  
Matrix42 doesn't bring any customer data to Matrix42 monitoring system. 
 

Logging
Secure Access generates a system log, where admins users can find detailed log files for auditing purposes and troubleshooting.

Federated user identity is used to access multiple domains or applications by only using a single set of user credentials. Standard practice with user federation is that user's identity is linked across several different identity management systems. 

It is very common that an organization already has directory service in use, which they use to store user and credential information (username & password). User federation provides access to external databases and directories, such as LDAP and Active Directory.

Secure Access can validate credentials from a directory and pull the user's identity information for authenticating the user to Matrix42 Pro and IGA solutions. LDAP is supported option. 

Login video

Links to configuration articles

Customer Instructions for User Federation

Configure: User federation for Authentication

Single-Sign-On (SSO) is commonly used authentication method, and it means that user don't need to add credentials (username & password) while authenticating, but instead user is authenticated with credentials received from the Identity Provider (IdP), usually directory like Entra ID (formerly Azure AD) . 

SSO can be technically implemented by using either SAML or OpenID protocols and it always varies which one is used based on the customers IdP. 

Examples of authentication protocols used for SSO: 

ADFS (Microsoft Active Directory Federation Service) uses always SAML protocol. 

Entra ID SSO (Microsoft Azure Single-Sign-On) uses SAML or OpenID protocol.

Login video

Links to configuration articles

Customer instructions for Entra ID configuration SAML

Customer instructions for Entra ID configuration OpenID

Configure: ESA Entra ID SSO

Customer instructions for ADFS Login

Configure: ESA ADFS Login

Secure Access supports also Matrix42 Pro or IGA (ESM) local users. Local user is someone whose credentials are not located in any of the Identity Providers (for example AD, Azure AD, OpenLDAP etc.).

Local users information needs to be found from the Matrix42 Pro or IGA solution customer is using. Local users can be created manually from the platform configuration or local users can be created by using workflow engine. 

Note that this same logic applies to any solution built on top of Matrix42 Pro or IGA platform. 

Login video

Links to configuration articles

Configure: Efecte Local user login

Secure Access supports the ability to grant guest access to Matrix42 Pro and IGA Self-Service. 

From login page, user selects guest access authentication, temporary credentials are generated for the guest user and he/she is redirected to Self-Service.   

Guest users will have limited visibility of services and information in Self-Service, and guest users are not able to return to their requests or reports made from Self-Service. For security reasons, its highly recommended that user completes ReCaptcha action, meaning that user confirms that he/she is not a robot.

Login video - ReCaptcha action

Links to configuration articles

 Configure: ESA - Guest Access configuration

Secure Access can be used for providing the anonymous login functionality, which means that before user login to Efecte Self-Service, username and password are randomly generated for the user. These anonymous users can copy credentials and use them for reviewing for example report status.  

Secure Access or any Matrix42 Pro and IGA solution does not save identifying information about the user or users session. For security reasons, its highly recommended that user completes ReCaptcha action, meaning that user confirms that he/she is not a robot.  

For example: Matrix42 Whistleblower solution uses anonymous login feature. 

Login video - Efecte Whistleblower

Links to configuration articles

Configure: Whistleblower Access configuration

Secure Access supports SAML Discovery Service, which is used for Virtu authentication.

Virtu is the Finnish Government's joint single sign-on solution, and the responsibility of the Government ICT Centre Valtori, which means that customer needs to be part of Virtu trust network. 

From login page, user selects which type of authentication or action he/she is going to use and if it requires Virtu authentication, user is directed to Virtu login page. After user has authenticated, he/she is redirected back to Secure Access and user is able to access Matrix42 Pro and IGA solutions according to defined access rights.

Read more about Virtu from here. 

Links to configuration articles

Configure: ESA Virtu Authentication

Customer instructions for Virtu Authentication

Secure Access supports SAML Discovery Service, which is used for HAKA authentication.

HAKA is the identity federation of the Finnish universities, polytechnics and research institutions joint single sign-on solution, and the responsibility of the CSC (IT center for science ltd.) which means that customer needs to be part of HAKA trust network. 

From login page, user selects which type of authentication or action he/she is going to use and if it requires HAKA authentication, user is directed to HAKA login page. After user has authenticated, he/she is redirected back to Secure Access and user is able to access Matrix42 Pro and IGA solutions according to defined access rights.

Read more about HAKA from here. 

Links to configuration articles

Configure: ESA HAKA Authentication

Customer instructions for HAKA Authentication

Secure Access supports Google authentication.

From login page, user selects which type of authentication or action he/she is going to use and if it requires Google authentication, user is directed to Google login page. After user has authenticated, he/she is redirected back to Secure Access and user is able to access Matrix42 Pro and IGA solutions according to defined access rights.

Login video

Links to configuration articles

Configure: ESA Google authentication

Secure Access supports SAML protocol, which is used for Okta authentication.

Okta is a secure identity cloud that links all your apps, logins and devices into a unified digital fabric. 

From login page, user selects which type of authentication or action he/she is going to use and if it requires Okta authentication, user is directed to Okta login page. After user has authenticated, he/she is redirected back to Secure Access and user is able to access Matrix42 Pro and IGA solutions according to defined access rights.

Login video

Links to configuration articles

How to Configure Authentication for Okta (SAML)?

Secure Access supports OpenID protocol, which is used for Keycloak authentication. Keycloak is an open-source software solution designed to provide single sign-on access to applications and services. It allows users to authenticate once and access multiple applications without needing to re-enter their credentials.

From login page, user selects which type of authentication or action he/she is going to use and if it requires Keycloak authentication, user is directed to Keycloak login page. After user has authenticated, he/she is redirected back to Secure Access and user is able to access Matrix42 Pro and IGA solutions according to defined access rights.

Links to configuration articles

How to Configure Authentication for Keycloak?

SAML is a protocol designed for exchanging authentication and authorization identities between security domains. 

Secure Access supports user authentication performed by Identity Provider (IdP), for example Entra ID, using a SAML 2.0 connector/adapter.

SAML sends claims by using XML SAML format. This format is most commonly used to help organizations with multiple applications, to be able to provide single login for their end-users. 

Links to configuration articles

Configure: SAML Entra authentication
Customer instructions for SAML Entra ID authentication configuration

OAuth 2.0 and OpenID Connect (an extension to OAuth 2.0 protocol) allow organizations to verify identity of the end-user, based on the authentication performed by an Authorization Server, as well as to obtain a basic profile information about the end-user. 

Secure Access supports user authentication performed by an Identity Provider (IdP), for example Entra ID, using OpenID Connect connector/adapter.  

OpenID Connect is built on top of OAuth protocol and it sends claims by using JSON Web Token (JWT) format and it is commonly used with for example cloud-based Identity Providers, consumer websites and mobile apps.

Links to configuration articles

Configure: OIDC Entra ID authentication
Customer instructions for OIDC Entra ID configuration

Secure Access supports Shibboleth authentication.

From login page, user selects which type of authentication or action he/she is going to use and if it requires Shibboleth authentication, user is directed to Shibboleth login page. After user has authenticated, he/she is redirected back to Secure Access and user is able to access Matrix42 Pro and IGA solutions according to defined access rights.

Links to configuration articles
Configure: Shibboleth authentication

Strong authentication is a definition, which is achieved when two (2) out of following three (3) principles are completed during the authentication, 

1. Something you have (for example mobile phone)
2. Something you know (for example username & password)
3. Something you are (for example fingerprint)

Now a days most commonly strong authentication contains, 

1. Something you know (username & password)
2. Something you have (one-time password to mobile device)

Principles are the thing differentiating strong authentication from Two-Factor Authentication (2FA) and from Multi-Factor Authentication, which only require that at least two authentication methods are used, but they can come out of same principle, meaning that 2FA or MFA are not necessary strong authentication. 

Following example can be called MFA or 2FA, but not strong authentication,

1. Something you know (username & password)
2. Something you know (answers to security questions)  

One-time password (OTP) can be part of the authentication and it means that one-time password is sent to user via email or via sms message (sent to users mobile phone). 

Some cases, it is enough to enter only the one-time password, but if customer is aiming for strong authentication, recommendation is to ask user to provide for example credentials (username and password) also for the authentication.

One-time password functionality is provided through-out Signicat services, meaning that they are Efecte's partner whose technology is used for the authentication. 

Secure Access supports one-time code authentication, which are temporal passwords generated by authentication application like for example Google Authenticator or FreeOTP. 

When one-time password (using authenticator application) is configured and user has provided their credentials (username & password), Secure Access asks the user to provide the password generated either Google Authenticator or FreeOTP. Note that the authenticator application needs to be installed in the user's mobile phone. 

Links to configuration articles

Configure: Two-Factor Authentication (2FA)

Bank ID authentication is always strong authentication, and it means that user is using personal bank ID credentials (provided by the bank or government) to authenticate themselves to Self-Service or Efecte solutions. 

It is common authentication method especially in Scandinavian countries, but its getting more and more common also in other European countries. In case you need bank ID authentication outside of Finland or Sweden, please contact Efecte for more information.

Bank ID authentication is made by using country specific protocols and Secure Access uses Signicat services as Identity Broker between banks and Secure Access. Currently bank ID authentication is supported in Finland and in Sweden. 

Links to configuration articles

https://docs.efecte.com/configure-authentication/configure-signicat-authentication 

Finland:

In Finland bank ID authentication is most commonly used by private sector companies, and in cases where government organization, for some reason, is not able to use suomi.fi authentication. 

Sweden:

In Sweden bank ID authentication is commonly used among government and private sector organizations. 

Suomi.fi authentication is similar to bank ID authentication, but only difference is that suomi.fi can be used only by Finnish government organizations. You can identify yourself in services using Finnish online banking codes, a mobile certificate card or a certificate card.

Secure Access uses Signicat services as Identity Broker, between suomi.fi service and Secure Access. 

Read more about suomi.fi authentication here.

Links to configuration articles

https://docs.efecte.com/configure-authentication/configure-signicat-authentication 

SAML is a protocol designed for exchanging authentication and authorization identities between security domains. 

Secure Access supports user authentication performed by Identity Provider (IdP), for example Entra ID, using a SAML 2.0 connector/adapter.

SAML sends claims by using XML SAML format. This format is most commonly used to help organizations with multiple applications, to be able to provide single login for their end-users. 

Links to configuration articles

Configure: SAML Entra authentication
Customer instructions for SAML Entra ID authentication configuration

OAuth 2.0 and OpenID Connect (an extension to OAuth 2.0 protocol) allow organizations to verify identity of the end-user, based on the authentication performed by an Authorization Server, as well as to obtain a basic profile information about the end-user. 

Secure Access supports user authentication performed by an Identity Provider (IdP), for example Entra ID, using OpenID Connect connector/adapter.  

OpenID Connect is built on top of OAuth protocol and it sends claims by using JSON Web Token (JWT) format and it is commonly used with for example cloud-based Identity Providers, consumer websites and mobile apps.

Links to configuration articles

Configure: OIDC Entra ID authentication
Customer instructions for OIDC Entra ID configuration

SAML Discovery Service protocol is used for HAKA and Virtu authentication in Secure Access, but it is also commonly used like for example in universities. 

Links to configuration articles

Configure: ESA HAKA authentication

Configure: ESA Virtu authentication

Finnish Trust Network protocol used when authenticating with Finnish bank ID credentials, also when authenticating with suomi.fi. It is mandatory to be used and more information can be found from here.

Links to configuration articles

https://docs.efecte.com/configure-authentication/configure-signicat-authentication 

A brute force attack attempts to guess a user’s password by trying to login multiple times. Secure Access has brute force detection capabilities and can temporarily disable a user account if the number of login failures exceeds a specified threshold.
By enabling the Brute Force detection (enabled as default), we can temporarily block the attackers trying to break into the system. When a user is temporarily locked and attempts to login, Secure Access displays the default invalid username or password error message to ensure the attacker is unaware the account is disabled. 
 

Links to configuration articles

How to Enable Brute Force Detection to ESA

Clickjacking protection prevents an attacker from embedding a web page within an iframe and tricking the user into clicking on hidden or disguised buttons or links. 

By default clickjacking protection is enabled as default. 

Customer can enable cookie policy into their login process. This means that website visitors are informed about the user data cookies are tracking, why that information is being tracked, and where it is sent. 
 

Links to configuration articles

Configure ESA cookie settings

Customer can enable user consent into their login process, which means that website users give permission to obtain, use, and process their data through cookies. After a user provides their credentials, ESA will pop up a screen identifying the client requesting a login and what identity information is requested of the user. User can decide whether or not to grant the request.

Links to configuration articles

Configure ESA to use User consent