Federation

Access Token Consumer

#Federation #Authentication #OAuth #OpenID Connect

This step generates an AccessTokenConsumer AuthState which is able to validate access tokens issued by an OAuth 2.0 Authorization Server / OpenID Provider.

Use this step in the Initial Authentication Flow of a Authentication Realm to provide a resource server for REST services.

The access token has to be sent as Bearer token in the Authorization header. The content of the token will be stored in session variables prefixed with oauth2.token.claim..

The sub claim of the access token will be used as user ID for nevisAuth. This is technically sufficient for authentication.

However, it is recommended to perform additional checks in subsequent steps. For instance, you may use a nevisIDM User Lookup step to look up a user in nevisIDM.

When the access token is invalid a 403 forbidden will be returned.

This pattern is experimental and it has some limitations.

For instance, it is assumed that the authorization server is running Nevis and is set up by a OAuth 2.0 Authorization Server / OpenID Provider pattern that is part of this project.

If you need improvements for this pattern, please create a feature request.

On Success

Assign a step to continue with after successfully validating the token.

On Missing Token

Assign a step to continue with when no token was sent.

If nothing is assigned then authentication will fail with an error.

OAuth 2.0 Authorization Server / OpenID Provider

Assign the OAuth 2.0 Authorization Server / OpenID Provider which has issued the access token.

Note that this step works in combination with Nevis OAuth 2.0 Authorization Server / OpenID Provider only and the other pattern has to be in the same project.

#Federation #Authentication #OAuth #OpenID Connect

Setup social login, using Apple as OpenID Connect provider.

Client ID

ClientID is Identifier provided by Apple when you register Apple as IdP service.

Client Secret

The Client Secret is a JWT token generated by using a private key provided by Apple. Please follow the instructions here.

You can generate the client secret by yourself and configure it here, or upload the Private Key to generate the client secret automatically. Only private key or client secret can be use at the time

Return Path

The callback URI to go to after a successful login with Apple.

This will create an endpoint in your host config.

The URL will be a combination of the Frontend Address of the Virtual Host and the value configured here. For example, let's assume that you have configured:

Return Path: /oidc/apple/
Frontend Address: https://nevis.net

Then the URL will be https://nevis.net/oidc/apple/.

Use the exact: prefix to use the given path as-is. Without this prefix a normal mapping with /* will be generated and thus sub-paths will be accessible as well.

Scope(s)

Select the requested scopes for getting user information from Apple.

The default is email and thus minimal information will be returned.

The scope openid will always be added as Apple uses OpenID Connect.

Virtual Host

Assign a Virtual Host which shall serve as entry point for the callback from social login provider.

In case your host has

1 address, that address will be used
many addresses with
- 1 https, and many http, the https will be used without warning
- mix between http and https, the 1st https will be used with warning
- single scheme (http or https only) the 1st address will be used with warning

E.g.

http://nevis.net
http://nevis-security.net
https://nevis.net
https://nevis-security.net

The https://nevis.net will be used as the host for Apple callback

On Success

The step executed after a successful authentication. If no step is configured here the process ends with AUTH_DONE.

In case you change this to your custom step(s), you can assign pattern Social Login Final Step as the last step of the Authentication process to redirect back to original URL.

On Failure

The step that will be executed if the authentication fails. If no step is configured here the process ends with AUTH_ERROR.

In case you change this to your custom step(s), you can assign pattern Social Login Final Failure Step as the last step of the Authentication process to redirect back to original URL.

Private Key

Private key provided by Apple. Find out more here.

If you upload your private key here and set the Issuer, the pattern will automatically generate the Client Secret.

If you do not want to configure your private key, you have to set the Client Secret instead.

Issuer

The issuer registered claim identifies the principal that issued the client secret. Since the client secret belongs to your developer team, use your 10-character Team ID associated with your developer account. Find out more here.

nevisIDM

Choose which nevisIDM instance you want to store the user's information after logged in with social login provider.

Client External ID

The ExtId of the client in nevisIDM that will be used to store the user

On User Not Found

Configure the authentication flow to be executed when no user was found and the email provided by social account does not exist. The authentication flow must contain the Social Login Create User pattern if a new user shall be created.

Note: Please select scope email and profile for getting user's information from social account.

On User Found

Configure the Authentication Flow in case no user with Subject/ID from social account was found but email does exist in nevisIDM. The Authentication Flow must contain:

Social Login Link User pattern to link an existing user in IDM with Subject/ID of social account.
Social Login Done to end the social login flow after some other action(s).

Note: Please select scope email and profile for getting user's information from social account.

Claims Request

The claims request parameter. This value is expected to be formatted in JSON and does not accept trailing spaces nor tabs.

User ID Field

Logged userId will automatically get from social account. But you can change the userId by using this field.

Additional Auth Request Parameters

Arbitrary additional request parameters used in the authentication request. The property supports variable substitution.

Example:

[paramName]=[paramValue]

Button Label

Enter the text that should be displayed for the end-user on the social login button, and provide translations for this label on the Authentication Realms.

#Federation #Authentication #OAuth #OpenID Connect

Set up social login, using Facebook as OpenID Connect provider.

Client ID

ClientID is App ID provided by Facebook when you register Facebook as IdP service.

Client Secret

Client Secret is App Secret provided by Facebook when you register Facebook as IdP service.

Return Path

The callback URI to go to after a successful login with Facebook.

This will create an endpoint in your host config.

The URL will be a combination of the Frontend Address of the Virtual Host and the value configured here. For example, let's assume that you have configured:

Return Path: /oidc/facebook/
Frontend Address: https://nevis.net

Then the URL will be https://nevis.net/oidc/facebook/.

Use the exact: prefix to use the given path as-is. Without this prefix a normal mapping with /* will be generated and thus sub-paths will be accessible as well.

Scope(s)

Select the request scopes for getting user information from Facebook.

The default is email and thus minimal information will be returned.

Select public_profile to return additional user information.

Scope offline_access is not supported as Facebook has removed this scope.

Virtual Host

Assign a Virtual Host which shall serve as entry point for the callback from social login provider.

In case your host has

1 address, that address will be used
many addresses with
- 1 https, and many http, the https will be used without warning
- mix between http and https, the 1st https will be used with warning
- single scheme (http or https only) the 1st address will be used with warning

E.g.

http://nevis.net
http://nevis-security.net
https://nevis.net
https://nevis-security.net

The https://nevis.net will be used as the host for Apple callback

On Success

The step executed after a successful authentication. If no step is configured here the process ends with AUTH_DONE.

In case you change this to your custom step(s), you can assign pattern Social Login Final Step as the last step of the Authentication process to redirect back to original URL.

On Failure

The step that will be executed if the authentication fails. If no step is configured here the process ends with AUTH_ERROR.

In case you change this to your custom step(s), you can assign pattern Social Login Final Failure Step as the last step of the Authentication process to redirect back to original URL.

nevisIDM

Choose which nevisIDM instance you want to store the user's information after logged in with social login provider.

Client External ID

The ExtId of the client in nevisIDM that will be used to store the user

On User Not Found

Note: Please select scope email and profile for getting user's information from social account.

On User Found

Configure the Authentication Flow in case no user with Subject/ID from social account was found but email does exist in nevisIDM. The Authentication Flow must contain:

Social Login Link User pattern to link an existing user in IDM with Subject/ID of social account.
Social Login Done to end the social login flow after some other action(s).

Note: Please select scope email and profile for getting user's information from social account.

Claims Request

The claims request parameter. This value is expected to be formatted in JSON and does not accept trailing spaces nor tabs.

User ID Field

Logged userId will automatically get from social account. But you can change the userId by using this field.

Additional Auth Request Parameters

Arbitrary additional request parameters used in the authentication request. The property supports variable substitution.

Example:

[paramName]=[paramValue]

Button Label

Enter the text that should be displayed for the end-user on the social login button, and provide translations for this label on the Authentication Realms.

#Federation #Authentication #OAuth #OpenID Connect

Use to set up a generic social login, either using OAuth2 or OpenID Connect.

Provider Type

The provider type of the social account: either OpenID Connect or OAuth2.

Client ID

The identifier provided by the social account when you register with it as the IdP service.

Client Secret

The secret of the client ID that has been set in the OAuth/OpenID Connect configuration of the social account.

Return Path

The callback URI to go to after a successful login with the social account.

This will create an endpoint in your host config.

The URL will be a combination of the Frontend Address of the Virtual Host and the value configured here. For example, let's assume that you have configured:

Return Path: /oidc/app/
Frontend Address: https://nevis.net

Then the URL will be https://nevis.net/oidc/app/.

Use the exact: prefix to use the given path as-is. Without this prefix a normal mapping with /* will be generated and thus sub-paths will be accessible as well.

Scope(s)

The request scope(s) for getting the user information from the social account. The default value is email.

The scope openid will be added automatically if providerType is set to OpenID Connect.

Scope offline_access for generate refresh token.

Virtual Host

Assign a Virtual Host which shall serve as entry point for the callback from social login provider.

In case your host has

1 address, that address will be used
many addresses with
- 1 https, and many http, the https will be used without warning
- mix between http and https, the 1st https will be used with warning
- single scheme (http or https only) the 1st address will be used with warning

E.g.

http://nevis.net
http://nevis-security.net
https://nevis.net
https://nevis-security.net

The https://nevis.net will be used as the host for Apple callback

On Success

The step executed after a successful authentication. If no step is configured here the process ends with AUTH_DONE.

In case you change this to your custom step(s), you can assign pattern Social Login Final Step as the last step of the Authentication process to redirect back to original URL.

On Failure

The step that will be executed if the authentication fails. If no step is configured here the process ends with AUTH_ERROR.

In case you change this to your custom step(s), you can assign pattern Social Login Final Failure Step as the last step of the Authentication process to redirect back to original URL.

Client Secret Method

The method used for authenticating the client. It can be either Basic Authentication or POST. The default value is Basic Authentication.

Response Mode

The mode used for the responses of the server. It can be either Query or Form POST. The default value is Query.

PKCE

Setting for PKCE in Authorization/Authentication request.

enabled, the Code Challenge and Code Verifier will be included in the Authorization/Authentication request.
disabled (default), the Code Challenge and Code Verifier will not be included in the Authorization/Authentication request.

PKCE Secret

Allow to set the secret for PKCE. The secret format should follow RFC 7636.

Code Challenge Method

Setting for PKCE Code Challenge Method.

plain (default), the Code Challenge will be sent with raw format.
S256, the Code Challenge will be hashed and base 64 encoded.

Provider Endpoint

The provider endpoint that contains the configuration of the OpenID Connect server. It's required when providerType has the value OpenID Connect.

Authorization Endpoint

The authorization endpoint of the OAuth2 provider.

Required when Provider Type is set to OAuth2.

Token Endpoint

The token endpoint of the OAuth2 server. It's required when providerType has the value OAuth2.

User Information Endpoint

The user information endpoint of the OAuth2 server. It's required when providerType has the value OAuth2.

JWKS Endpoint

The JWKS endpoint of the OAuth2 server. It's optional when Provider Type has the value OAuth2.

nevisIDM

Choose which nevisIDM instance you want to store the user's information after logged in with social login provider.

Client External ID

The ExtId of the client in nevisIDM that will be used to store the user.

On User Not Found

Note: Please select scope email and profile for getting user's information from social account.

On User Found

Configure the Authentication Flow in case no user with Subject/ID from social account was found but email does exist in nevisIDM. The Authentication Flow must contain:

Social Login Link User pattern to link an existing user in IDM with Subject/ID of social account.
Social Login Done to end the social login flow after some other action(s).

Note: Please select scope email and profile for getting user's information from social account.

Account Linking - User Property

Enter the name of the nevisIDM user property that is used for linking the account.

The property will contain the value of the sub claim of the social login provider.

This pattern will ensure that the property is created in nevisIDM by contributing to the generation of the nevisIDM configuration. The pattern adds a property definition file to /var/opt/nevisidm/<instance>/conf/import/user_<name>.json. This file is interpreted by nevisIDM during startup.

Before the May 2025 release, the sanitized pattern name was used for this property. This is not recommended anymore, as the account link will break when the pattern is renamed.

To avoid this problem, it is now recommended to configure this setting. If you are upgrading from a previous version you must use the property name which was used so far.

First Name Claim

The claim that contains the first name of the logged-in user in the social account. The default value is given_name.

Second Name Claim

The claim that contains the second name of the logged-in user in the social account. The default value is family_name.

Email Claim

The claim that contains the e-mail of the logged-in user in the social account. The default value is email.

Subject Claim

The claim that contains the subject of the logged-in user in the social account. The default value is sub.

Claims Request

The claims request parameter. This value is expected to be formatted in JSON and does not accept trailing spaces nor tabs.

User ID Field

Logged userId will automatically get from social account. But you can change the userId by using this field.

Additional Auth Request Parameters

Arbitrary additional request parameters used in the authentication request. The property supports variable substitution.

Example:

[paramName]=[paramValue]

Button Label

The text that should be displayed for the end-user on the social login button, and provide translations for this label on the Authentication Realms.

Button CSS class

The css class that apply for the social login button. Ensure that the Login Template used in your realm pattern includes a CSS file which defines the CSS class.

Button Logo Path

The path to logo file of the social login provider. This path is the path of logo file which you which uploaded at Login template in Realm pattern. E.g:

In the zip file the icon with path /webdata/resources/icons/icon.csv, the input is /icons/icon.csv

#Federation #Authentication #OAuth #OpenID Connect

Set up social login, using Google as OpenID Connect provider.

Client ID

ClientID is Client ID provided by Google when you create a OAUTH 2.0 credential in Google.

Client Secret

Client Secret is Client Secret provided by Google when you create a OAUTH 2.0 credential in Google.

Return Path

The callback URI to go to after a successful login with Google.

This will create an endpoint in your host config.

The URL will be a combination of the Frontend Address of the Virtual Host and the value configured here. For example, let's assume that you have configured:

Return Path: /oidc/google/
Frontend Address: https://nevis.net

Then the URL will be https://nevis.net/oidc/google/.

Use the exact: prefix to use the given path as-is. Without this prefix a normal mapping with /* will be generated and thus sub-paths will be accessible as well.

Virtual Host

Assign a Virtual Host which shall serve as entry point for the callback from social login provider.

In case your host has

1 address, that address will be used
many addresses with
- 1 https, and many http, the https will be used without warning
- mix between http and https, the 1st https will be used with warning
- single scheme (http or https only) the 1st address will be used with warning

E.g.

http://nevis.net
http://nevis-security.net
https://nevis.net
https://nevis-security.net

The https://nevis.net will be used as the host for Apple callback

Scope(s)

Select the request scope(s) for getting user information from Google. Default scopes is email.

Scope openid will be added automatically because Google is implement based on OpenID protocol.

Scope offline_access for generate refresh token. This scope will transfer to access_type=offline request parameter for matching with Google spec

On Success

The step executed after a successful authentication. If no step is configured here the process ends with AUTH_DONE.

In case you change this to your custom step(s), you can assign pattern Social Login Final Step as the last step of the Authentication process to redirect back to original URL.

On Failure

The step that will be executed if the authentication fails. If no step is configured here the process ends with AUTH_ERROR.

In case you change this to your custom step(s), you can assign pattern Social Login Final Failure Step as the last step of the Authentication process to redirect back to original URL.

nevisIDM

Choose which nevisIDM instance you want to store the user's information after logged in with social login provider.

Client External ID

The ExtId of the client in nevisIDM that will be used to store the user

On User Not Found

Note: Please select scope email and profile for getting user's information from social account.

On User Found

Configure the Authentication Flow in case no user with Subject/ID from social account was found but email does exist in nevisIDM. The Authentication Flow must contain:

Social Login Link User pattern to link an existing user in IDM with Subject/ID of social account.
Social Login Done to end the social login flow after some other action(s).

Note: Please select scope email and profile for getting user's information from social account.

Claims Request

The claims request parameter. This value is expected to be formatted in JSON and does not accept trailing spaces nor tabs.

User ID Field

Logged userId will automatically get from social account. But you can change the userId by using this field.

Additional Auth Request Parameters

Arbitrary additional request parameters used in the authentication request. The property supports variable substitution.

Example:

[paramName]=[paramValue]

Button Label

Enter the text that should be displayed for the end-user on the social login button, and provide translations for this label on the Authentication Realms.

#Federation #Authentication #OAuth #OpenID Connect

Set up social login, using Microsoft as OpenID Connect provider.

Client ID

ClientID is Application (client) ID provided by Microsoft when you create an Application Microsoft.

Client Secret

Client Secret is Client Secret provided by Microsoft when you create an Application Credentials & Secrets in Microsoft.

Return Path

The callback URI to go to after a successful login with Microsoft.

This will create an endpoint in your host config.

The URL will be a combination of the Frontend Address of the Virtual Host and the value configured here. For example, let's assume that you have configured:

Return Path: /oidc/microsoft/
Frontend Address: https://nevis.net

Then the URL will be https://nevis.net/oidc/microsoft/.

Use the exact: prefix to use the given path as-is. Without this prefix a normal mapping with /* will be generated and thus sub-paths will be accessible as well.

Scope(s)

Select the request scope(s) for getting user information from Microsoft. Default scopes is email.

Scope openid will be added automatically because Microsoft is implement based on OpenID protocol.

Scope offline_access for generate refresh token.

Virtual Host

Assign a Virtual Host which shall serve as entry point for the callback from social login provider.

In case your host has

1 address, that address will be used
many addresses with
- 1 https, and many http, the https will be used without warning
- mix between http and https, the 1st https will be used with warning
- single scheme (http or https only) the 1st address will be used with warning

E.g.

http://nevis.net
http://nevis-security.net
https://nevis.net
https://nevis-security.net

The https://nevis.net will be used as the host for Apple callback

On Success

The step executed after a successful authentication. If no step is configured here the process ends with AUTH_DONE.

In case you change this to your custom step(s), you can assign pattern Social Login Final Step as the last step of the Authentication process to redirect back to original URL.

On Failure

The step that will be executed if the authentication fails. If no step is configured here the process ends with AUTH_ERROR.

In case you change this to your custom step(s), you can assign pattern Social Login Final Failure Step as the last step of the Authentication process to redirect back to original URL.

nevisIDM

Choose which nevisIDM instance you want to store the user's information after logged in with social login provider.

Client External ID

The ExtId of the client in nevisIDM that will be used to store the user

On User Not Found

Note: Please select scope email and profile for getting user's information from social account.

On User Found

Configure the Authentication Flow in case no user with Subject/ID from social account was found but email does exist in nevisIDM. The Authentication Flow must contain:

Social Login Link User pattern to link an existing user in IDM with Subject/ID of social account.
Social Login Done to end the social login flow after some other action(s).

Note: Please select scope email and profile for getting user's information from social account.

Application Type

The application type that you choose when you create your application in Microsoft. We are supporting 3 types

common
organizations
consumers

Please follow this document to select your application type correctly

Tenant ID

Enter the Tenant ID of your Azure Active Directory.

This setting is used when Application Type is set to organizations.

Check Microsoft documentation on How to find your Azure Active Directory tenant ID.

Claims Request

The claims request parameter. This value is expected to be formatted in JSON and does not accept trailing spaces nor tabs.

User ID Field

Logged userId will automatically get from social account. But you can change the userId by using this field.

Additional Auth Request Parameters

Arbitrary additional request parameters used in the authentication request. The property supports variable substitution.

Example:

[paramName]=[paramValue]

Button Label

Enter a label for the social login button.

Translations for this label can be configured in the Authentication Realm pattern.

nevisMeta REST Service

#Federation #Applications

The pattern exposes the nevisMeta REST API on a nevisProxy Virtual Host.

The REST API is exposed on the path /nevismeta/rest.

nevisMeta

Reference the nevisMeta Instance.

Virtual Host(s)

Assign a Virtual Host which shall serve as entry point.

Authentication Realm

Assign a realm pattern which authenticates access to nevisMeta.

Application Access Token

Assign a Nevis SecToken pattern.

The token informs nevisMeta about the authenticated user.

If you are not using automatic key management then you also have to configure nevisMeta Instance / SecToken Signer Trust Store so that the signer certificate is trusted.

Additional Settings

Assign add-on patterns to customize the behavior of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

nevisMeta Web Console

#Federation #Applications

Sets up the nevisMeta Web Console, which is a component supporting the setup of OAuth2 and OpenID Connect for nevisAuth.

You can access the Web console on the assigned Virtual Host.

For instance, let's say your domain is example.com, and you have entered https://example.com as a Frontend Addresses in the Virtual Host pattern. This means that you can access the Web console on https://example.com/nevismeta/.

nevisMeta

Reference the nevisMeta Instance.

Virtual Host(s)

Assign a Virtual Host which shall serve as entry point.

Trust Store

Assign the Trust Store provider for outbound TLS connections. If no pattern is assigned a trust store will be provided by nevisAdmin 4 automatic key management.

Hostname Validation

Enable to verify that the hostname on the certificate presented by the backend matches the hostname of nevisMeta

Key Store

Assign a key store if you want to use 2-way TLS for the connection between nevisProxy and nevisMeta.

Outbound Client Authentication

Controls whether the service access presents a client certificate on outbound TLS connections.

automatic follows the referenced target's server-side client-authentication setting. required ensures that client authentication is used, preserving an explicitly configured key store and generating an implicit identity only when no key store is configured. disabled prevents client authentication and is rejected when the referenced target requires it.

Authentication Realm

Assign a realm pattern which authenticates access to nevisMeta.

Application Access Token

A Nevis SecToken pattern must be assigned here.

The token will be issued after authentication and propagated to nevisMeta.

The user must have the role nevisMeta.admin.

Request Validation (ModSecurity)

off - no request validation
standard - uses ModSecurity OWASP Core Rule Set (CRS) with default paranoia level 1 - Basic security
custom - configure Request Validation Settings via Additional Settings
log only - uses standard in log only mode

Additional Settings

Assign add-on patterns to customize the behavior of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

OAuth 2.0 / OpenID Connect Dynamic Client Registration Endpoint

#Federation #OAuth #OpenID Connect

Links to a Dynamic Client Registration endpoint for OAuth 2.0 / OpenID Connect.

The information is by OAuth 2.0 / OpenID Connect Metadata Endpoint to provide metadata.

Endpoint Path

Enter the URL of the registration endpoint.

Note that if the value contains a hostname, this pattern will not set up a registration endpoint, it just provides information about that endpoint.

The information is then used by the OAuth 2.0 / OpenID Connect Metadata Endpoint to provide metadata.

The prefix exact: is not supported here, enter the path as-is.

OAuth 2.0 / OpenID Connect JWKs Endpoint

#Federation #OAuth #OpenID Connect

Sets up a JWKs endpoint for OAuth 2.0 / OpenID Connect.

Endpoint Path

If you enter a path the REST service will be generated and exposed on the nevisProxy Virtual Host assigned to the OAuth 2.0 Authorization Server / OpenID Provider.

The prefix exact: is not supported here, enter the path as-is.

If you enter a URL no REST service will be generated. Use this variant if you want to use an external service.

Either way, the information will be used by the OAuth 2.0 / OpenID Connect Metadata Endpoint to provide metadata.

OAuth 2.0 / OpenID Connect Metadata Endpoint

#Federation #OAuth #OpenID Connect

Sets up a Metadata endpoint for OAuth 2.0 / OpenID Connect.

Endpoint Path

If you enter a path the REST service will be generated and exposed on the nevisProxy Virtual Host assigned to the OAuth 2.0 Authorization Server / OpenID Provider.

The prefix exact: is not supported here, enter the path as-is.

If you enter a URL no REST service will be generated. Use this variant if you want to use an external service.

Either way, the information will be used by the OAuth 2.0 / OpenID Connect Metadata Endpoint to provide metadata.

OAuth 2.0 / OpenID Connect Pushed Authorization Request Endpoint

#Federation #OAuth #OpenID Connect

Sets up a Pushed Authorization Request endpoint for OAuth 2.0 / OpenID Connect.

Endpoint Path

If you enter a path the REST service will be generated and exposed on the nevisProxy Virtual Host assigned to the OAuth 2.0 Authorization Server / OpenID Provider.

The prefix exact: is not supported here, enter the path as-is.

If you enter a URL no REST service will be generated. Use this variant if you want to use an external service.

Either way, the information will be used by the OAuth 2.0 / OpenID Connect Metadata Endpoint to provide metadata.

Protected Endpoint

Set Basic authentication for REST Service of OAuth 2.0 Authorization Server / OpenID Provider.

When this property is enabled, the request must include Authentication Header. The header is a combination of clientID and clientSecret with base64 encoded

Request Timeout

Configure how the PAR request shall be valid.

For security reasons, we suggest to keep this duration as low as possible.

If not set, the default in the nevisAuth component (90s) applies.

OAuth 2.0 / OpenID Connect Token Introspection Endpoint

#Federation #OAuth #OpenID Connect

Sets up a Token Introspection endpoint for OAuth 2.0 / OpenID Connect.

Endpoint Path

If you enter a path the REST service will be generated and exposed on the nevisProxy Virtual Host assigned to the OAuth 2.0 Authorization Server / OpenID Provider.

The prefix exact: is not supported here, enter the path as-is.

If you enter a URL no REST service will be generated. Use this variant if you want to use an external service.

Either way, the information will be used by the OAuth 2.0 / OpenID Connect Metadata Endpoint to provide metadata.

Protected Endpoint

Set Basic authentication for REST Service of OAuth 2.0 Authorization Server / OpenID Provider.

When this property is enabled, the request must include Authentication Header. The header is a combination of clientID and clientSecret with base64 encoded

OAuth 2.0 / OpenID Connect Token Revocation Endpoint

#Federation #OAuth #OpenID Connect

Sets up a Token Revocation endpoint for OAuth 2.0 / OpenID Connect.

Endpoint Path

If you enter a path the REST service will be generated and exposed on the nevisProxy Virtual Host assigned to the OAuth 2.0 Authorization Server / OpenID Provider.

The prefix exact: is not supported here, enter the path as-is.

If you enter a URL no REST service will be generated. Use this variant if you want to use an external service.

Either way, the information will be used by the OAuth 2.0 / OpenID Connect Metadata Endpoint to provide metadata.

Protected Endpoint

Set Basic authentication for REST Service of OAuth 2.0 Authorization Server / OpenID Provider.

When this property is enabled, the request must include Authentication Header. The header is a combination of clientID and clientSecret with base64 encoded

OAuth 2.0 / OpenID Connect User Info

#Federation #Authentication #OAuth #OpenID Connect

An OAuth 2.0 Authorization Server / OpenID User Info returns information about the authenticated user.

Virtual Host(s)

Assign a Virtual Host which shall serve as entry point.

Authentication Realm

Assign a realm which shall be exposed to get user information of an OAuth2 Authorization Server or OpenID Connect Provider.

Endpoint

Enter the path where the endpoint shall be exposed on nevisProxy.

Use the exact: prefix to expose only the given path. Without this prefix sub-paths will be accessible as well. This is because a normal mapping with /* at the end will be created in nevisProxy.

Signer

Configure the key material which is used to validate tokens. This signer must be the same signer that use to sign the tokens.

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector to get user information.

OAuth 2.0 Authorization Server / OpenID Provider

#Federation #Authentication #OAuth #OpenID Connect

An OAuth 2.0 Authorization Server / OpenID Provider can issue tokens for a client, considering the requested scopes, claims, and end user consent.

See AuthorizationServer for details.

The pattern is experimental. We recommend using it for prototyping configuration only, as there may be breaking changes in future versions.

The metadata of OAuth 2.0 clients is managed in nevisMeta. The pattern nevisMeta Web Console should be configured as well.

Virtual Host

Assign a Virtual Host which shall serve as entry point.

Authorization Path

This is the path where relying parties redirect the browser to.

Example use cases:

OAuth: acquire an access and refresh tokens
OpenID Connect: acquire access, refresh and ID tokens

Use the exact: prefix to expose only the given path. Without this prefix sub-paths will be accessible as well. This is because a normal mapping with /* at the end will be created in nevisProxy.

Token Path

The endpoint to exchange the authorization code for tokens.

Use the exact: prefix to expose only the given path. Without this prefix sub-paths will be accessible as well. This is because a normal mapping with /* at the end will be created in nevisProxy.

Authentication Realm

Assign a realm which shall be exposed as an OAuth2 Authorization Server or OpenID Connect Provider.

Signer

Configure the key material which is used to sign issued codes and tokens.

Access Token Format

Choose between:

JWE: the access token will be encrypted. This is the default.

The token is considered opaque and thus resource servers need to call the token introspection endpoint to validate the token.

JWS: the access token will not be encrypted. Choose this mode to get a signed token

which can be validated without calling the token introspection endpoint. Assign the OAuth 2.0 / OpenID Connect JWKs Endpoint pattern to publish the public signing key, so that resource servers can validate the signature.

OpenID Connect

If enabled the scope openid is allowed for this client.

OpenID Connect Issuer

Enter the issuer for OpenID Connect.

The value must be a case-sensitive URL using the https scheme that contains at least scheme and host. The port number and path component are optional. No query or fragment components are allowed.

If not set the issuer will be calculated based on:

the first Frontend Address with scheme https of the assigned Virtual Host
the first Frontend Path

Access Token Claims

Configure additional claims for the OAuth2.0 Access Token.

Claims are added if they have a value.

For instance, claims may be added when a certain scope is requested which includes them.

OpenID Connect defines the following scope values which may be requested to get claims:

profile. claims: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at.
email. claims: email, email_verified
address. claims: address
phone. claims: phone_number, phone_number_verified

Examples:

given_name=${sess:ch.nevis.idm.User.firstName}
family_name=${sess:ch.nevis.idm.User.name}
email=${sess:ch.nevis.idm.User.email}
mobile=${sess:ch.nevis.idm.User.mobile}

ID Token Claims

Define claims for the OpenID Connect ID token.

For the value you can use a constant, a nevisAuth expression, an EL expression, or refer to an inventory variable by using the ${var.<name>} syntax.

Note that you also have to do this for standard OpenID Connect claims. The only exception are sub, iss which will always be added.

Here are some examples:

Claim	Value
`given_name`	`${sess:ch.nevis.idm.User.firstName}`
`family_name`	`${sess:ch.nevis.idm.User.name}`
`email`	`${sess:ch.nevis.idm.User.email}`
`mobile`	`${sess:ch.nevis.idm.User.mobile}`
`customer`	`${var.customer-number}`

Which claims will be added to the ID token depends on the incoming request. Non-standard claims have to be requested using the claims request parameter. Standard claims are added when a certain OpenID Connect scope is requested:

Requested Scope	Added Claims
`profile`	`name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, `updated_at`
`email`	`email`, `email_verified`
`address`	`address`
`phone`	`phone_number`, `phone_number_verified`

ID Token Headers

Define custom JOSE headers for the OpenID Connect ID token.

For the value you can use a constant, a nevisAuth expression, an EL expression, or refer to an inventory variable by using the ${var.<name>} syntax.

The header name must be a valid JOSE header parameter name. For encrypted ID tokens, custom headers are added to the outer JWE header.

Examples:

Header	Value
`typ`	`JWT`
`custom_header`	`${sess:ch.nevis.idm.User.customHeader}`
`customer`	`${var.customer-number}`

REST Endpoint(s)

Add extension services for OAuth 2.0 Authorization Server / OpenID Provider

JWK Set Key ID

When set to enabled a kid header value will be added to issued access and ID tokens.

The value allows the authorization server to explicitly signal a change of key material to recipients.

The meaning of the kid header is slightly different for signed and encrypted tokens.

nevisMeta

Assign a nevisMeta Instance or nevisMeta Connector.

nevisMeta is used to lookup metadata for the given OAuth2 / OpenID Connect Setup (see Setup ID).

Setup ID

ID of the nevisMeta setup.

Create your setup via the nevisMeta Web Console.

Then the ID of the setup can be determined. There are several ways to do that:

hover over the icon which links to the REST API
export the setup and check the exported files
Configure a nevisMeta REST Service, login and send a GET to /nevismeta/rest/v2/modules/oauthv2/setups/

Cache Timeout

Caching of responses from a nevisMeta instance. After this time (in seconds), a response is considered outdated and attempts are made to update it.

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector.

Required when User Info is enabled.

Assignment is required to determine the URL for the REST API call to the nevisIDM user info endpoint.

User Info

When enabled, the nevisIDM user info endpoint is called to retrieve information about the authenticated user.

The following property will be added to the configuration of the AuthorizationServer AuthState:

<property name="openid.userInfoEndpointUri" value="https://<idm-host>:<idm-port>/nevisidm/api/oic1.0/userinfo"/>

For reasons of backward compatibility, the default is disabled.

The information from the user info endpoint is used to populate any claims in the returned ID and access tokens.

Auth Code Lifetime

How long an authorization code issued by the authorization server should be valid.

Refresh Token Rotation

Defines if a new Refresh Token is issued together with the Access Token on the Token Endpoint while exchanging a refresh token for a new access token (grant_type=refresh_token).

enabled, a new Refresh Token is issued, the existing Refresh token is deleted.
disabled, the existing Refresh token is returned and remains valid.

Remove Empty Claim(s) In Token

Defines if the empty claim(s) will appear in the Access Token and ID Token.

enabled: the ID Token and Access Token will not include empty claim(s).
disabled (default): the ID Token and Access Token may include empty claim(s).

Audience Field Strategy

Defines whether the audience (aud) claim is added to the issued Access Tokens, following RFC 9068 and RFC 8707.

disabled (default): the Access Token will not contain the aud claim. The resource request parameter is ignored.
resource: the audience is derived from the resource request parameter or from the configured resource servers in nevisMeta that own the requested scopes. The eligible resource servers must have the URL field set in nevisMeta. Requires nevisMeta as the data source.

JWK Set Endpoint Trust Store

Assign a trust store for the outbound TLS connection to JWK Set endpoint for ID Token encryption.

Import the CA certificate of the JWK Set endpoint into this trust store.

Since version 4.38 nevisAuth trusts CA certificates included in the JDK.

Thus, it is not required to configure this.

However, you can still configure a trust store here to be as strict as possible.

JWK Set Endpoint Proxy

Forward proxy for the connection to the JWK Set endpoint for ID token encryption. Enter the hostname:port here

Example: proxy.your-internal-domain:3128

Invalid Client

Configure the step to execute after error when the client sending the request is not registered.

If no step is configured here the process ends and the error will display on UI.

Invalid Redirect URI

Configure the step to execute when the redirect_uri request parameter value is not registered for the client sending the request.

If no step is configured here the flow ends and an error will be displayed.

Valid Authorization Request Authentication Required

The nevisMeta UI has a setting on the Client called Force Reauthentication.

If enabled, users need to authenticate for every invocation of the Authorization Path.

To ensure that this setting works out of the box, this pattern generates configuration which always dispatches the request into the Initial Authentication Flow of the assigned Authentication Realm.

If you want to use a different authentication flow for re-authentication, then assign a different step here.

When configured, a ResultCond with name valid-authorization-request-authentication-required will be added.

Configure the step to execute after authorization request is valid and end-user authentication can be skipped.

If no step is configured here the process ends and the final AUTH_DONE will be reached.

Invalid Authorization Request

Configure the step to execute after error when the authorization request is invalid. Example:

Cannot parse Authorization Request
Request response-type mismatch with client configuration
Invalid scope
Policy not allow
PKCE method not support
Missing code challenge
Plain code challenge

If no step is configured here the process ends and the error will display on UI.

Invalid Token Request

Configure the step to execute after error when token request is invalid and token error response is about to be issued.

If no step is configured here the process ends and the error response issued and return to the client.

Custom Transitions

Add or overwrite ResultCond elements in the AuthorizationServer state.

This setting is advanced. Use without proper know-how may lead to incorrect behavior.

If you use this setting, we recommend that you contact Nevis to discuss your use case.

The position refers to the list of Additional Follow-up Steps. The position starts at 1.

Examples:

`ResultCond`	Position
valid-token-request	1
valid-authorization-request	2

The following ResultCond elements cannot be overruled by this setting:

authenticate:valid-authorization-request
stepup:valid-authorization-request
server-error
invalid-client (configure Invalid Client instead)
invalid-redirect-uri (configure invalid Redirect URI instead)
invalid-authorization-request (configure Invalid Authorization Request instead)
invalid-token-request (configure Invalid Token Request instead)

Custom Follow-up Steps

Assign follow-up steps.

The order of steps is relevant. The first step in this list has index 1.

You may reference a step in the configuration via the Custom Transitions.

Propagation Scope

Define propagation scope to store information for following AuthStates. Following are propagated data:

Authorization request:
- oauth2.authorization_request.[requestParameter]
Client configuration:
- oauth2.client.id
- oauth2.client.metadata.[field]
Scope configuration:
- oauth2.scope.policy.clientCredentialsFlow
- oauth2.scope.policy.authorizationCodeFlow
- oauth2.scope.policy.implicitFlow
- oauth2.scope.policy.refreshTokenRequest
- oauth2.scope.policy.authenticationRequired
- oauth2.scope.metadata.[field]

You can find out more information in the output session of AuthorizationServer

The propagated data is intended for logging purposes only, no standard AuthState will use it. But you can access and use with Groovy Script Step.

Note: If your flow has multiple user interactions, use the scope session to ensure that the information is available throughout the flow.

Allowed Origins

List of URL from where that allow to access the authorization endpoint and token endpoint. If this field does not set, authorization endpoint and token endpoint can be access from everywhere.

Select enabled if you want to ask the user to grant consents for scopes.

Which scopes require consent can be configured in nevisMeta.

Select disabled if you do not have any scopes that require consents, or if you have to do custom consent handling.

Custom Pre-Processing

Assign a step to apply custom pre-processing logic.

This pre-processing logic is executed on the Authorization Path and Token Path.

You may assign a chain of steps to build a flow. The dispatching will continue when leaving this flow on the happy path.

For On Success exits this works automatically.

However, generic exits (i.e. Additional Follow-up Steps in Generic Authentication Step) must be marked a success exits by assigning the Pre-Processing Done pattern.

Custom Properties

Configure properties of the nevisAuth AuthorizationServer.

Add or overwrite properties by entering a value.

Remove properties generated by this pattern by leaving the value empty.

Examples:

Key	Value
propagationScope	session
nevismeta.blockClientInterval	600

Old Signer

Configure the key material which is used to validate codes and tokens during the certificate rollover period.

SAML IDP

#Federation #Authentication #SAML

Sets up a SAML Identity Provider (IDP).

The Authentication Realm provides Single-Sign-On.

By default, only SP-initiated authentication is allowed. This method is most secure and standard.

Service providers (SP) may initiate authentication by sending an AuthnRequest to any of the configured Frontend Path(s).

You can enable IDP-initiated authentication via the Authentication Type drop-down.

SAML Issuer

Configure the Issuer used by this IDP.

The issuer can be an arbitrary String but it is a common practise to use the URL of the IDP.

Example: https://idp.example.org/SAML2/

Virtual Host

Assign a Virtual Host which shall serve as entry point.

Frontend Path(s)

Define paths for the following cases.

SP-initiated authentication

Service providers may send a parameter SAMLRequest containing an AuthnRequest (using POST or redirect binding) to request authentication. On successful authentication the IDP returns a SAML Response.

On entry an initial session will be created. The session may expire during authentication due to timeout.

When this happens an error page (name: saml_dispatcher) with title title.saml.failed and error message error.saml.failedwill be rendered.

SP-initiated logout

Service providers may send a LogoutRequest (POST or redirect binding) to logout from this IDP and other service providers.

IDP-initiated logout

Applications may have a link pointing to the IDP to trigger a global logout.

This link may point to:

<path>/logout: to show a logout confirmation page (GUI name: saml_logout_confirm, label: info.logout.confirmation)
<path>/?logout: to skip the logout confirmation page.

If a Referer header has been sent by the browser, the logout confirmation page will have a cancel button which redirects to the referer. Note that if the SP is NEVIS you may have to adapt the Security Response Headers of the Virtual Host. By default, the header Referrer-Policy: strict-origin-when-cross-origin is set and this will prevent the path being sent so the cancel button will redirect to /.

During SAML logout the IDP renders a GUI named saml_logout with the following hidden fields:

saml.logoutURLs: the URL of the SPs including LogoutRequest message as query parameter
saml.logoutURL: the URL to redirect to after successful logout

The default nevisLogrend template contains Javascript to invoke all saml.logoutURLs and redirect to saml.logoutURL after all requests have been sent. This is a best effort operation which means that the JavaScript does not check if the logout was successful.

IDP-initiated authentication

Requests to the base path without SAMLRequest will trigger IDP-initiated authentication.

In this case the following parameters must be sent:

Issuer: as entered for a SAML SP Connector
RelayState: this parameter is returned to the SAML SP together with the Response

Authentication Realm

Optionally assign a realm to protect this application or service.

Service Providers

Define the SAML Service Providers which can use this IDP.

For each SP an own AuthState of class IdentityProviderState will be generated.

SAML Signer

Configure the key used by this Identity Provider to sign outgoing SAML Assertions.

Metadata Service

When enabled a SAML Metadata Service will be generated which can be accessed on the Metadata Service Path.

The SAML Metadata Service is not protected by authentication.

Metadata Service Path

Enter a path where the SAML Metadata Service shall be exposed on the assigned Virtual Host.

Authentication Type

Select which authentication types are allowed:

sp-initiated: recommended
idp-initiated: less secure as no AuthnRequest is sent.
both: both sp-initiated and idp-initiated are allowed.

Error Handling

Define how dispatching errors are handled.

Choose between:

redirect: Redirect according to the configuration of Error Redirect.
show-gui: Stay in state to show an error screen.

Error Redirect

URL or path to redirect to when the IDP is unable to handle the request.

If no URL is configured, the IDP will redirect back to the Referer, or / if no Referer header has been sent.

There are several cases:

session loss due to timeout.
a session is required for the current operation (e.g., logout, stepup), but no session was found.
the authentication type (SP-initiated or IDP-initiated) is not allowed.
not enough information for IDP-initiated authentication (e.g., missing query parameters).

Logout Confirmation

Choose between:

enabled - shows a logout confirmation screen when the path ends with /logout
disabled - never shows a logout confirmation screen

Please be aware that we plan further changes which affect SAML logout and thus this setting may change or even disappear in a future release.

Custom Pre-Processing

An an authentication step to execute before dispatching according to the issuer.

SAML IDP Connector

#Federation #SAML #Connector

The pattern represents the connection to a SAML IDP.

You can use the pattern in:

SAML SP Realm
SAML Response Consumer

IDP Issuer

Enter the Issuer of the IDP.

Example: https://idp.example.org/SAML2

The Issuer is used to look up the trust store containing the signer certificate of the IDP.

For this purpose a KeyObject element will be configured in the nevisAuth esauth4.xml using the Issuer for the attribute id.

IDP URL

Enter the Location of the SAML SingleSignOnService. This may be a URL or a path on the same virtual host.

nevisAuth will send an AuthnRequest to this location to delegate the authentication or session upgrade process to the IDP.

By default, the AuthnRequest contains a RequestedAuthnContext which specifies the required authentication level. You can disable this feature via Custom Properties.

Message Decryption Key Store

Assign a pattern to configure the private key to decrypt the incoming message of the identity provider.

Binding: Outbound

Configure the outgoing binding. This affects how the SAML AuthnRequest is sent to the IDP.

Signature Validation

Configure for which SAML elements signature validation shall be performed.

This setting is used to generate the property in.verify of the ServiceProviderState.

When nothing is selected, then the option recommended is used. The recommended option produces the following configuration:

<property name="in.verify" value="Response Assertion"/>

Thus, both the signature of the Response and the Assertion contained in the Response are expected to be signed and the signature of both elements will be checked.

This configuration is compatible with the default configuration of the SAML IDP pattern.

This also is the strictest configuration. If your IDP signs only one of these 2 elements, then you have to adapt the configuration here.

It is recommended that the IDP signs the entire Response. If only the Assertion is signed, then that is potentially vulnerable because an attacker may replace the Response.

To prevent common attack scenarios, nevisAuth will perform additional checks when only the Assertion is signed.

IDP Signer Trust Store

Assign a pattern to configure the signer certificate of the identity provider.

Attribute Extraction

Configure to extract attributes from SAML assertions and store them in a session variable.

Examples:

Session Variable	Attribute
sess:user.email	email
sess:user.mobile	mobile

Audience Check

Define how to validate the optional Audience element of received SAML assertions.

disabled - Audience is not checked
lax - if present the Audience has to match the Allowed Audience
strict - the Audience element must be present and must match the Allowed Audience

Allowed Audience

Enter a regular expression to validate the Audience of a received SAML Assertion.

Allowed Lifetime

SAML assertions have an issue timestamp. nevisAuth validates the timestamps of SAML assertions received from the IDP.

Some identity providers create the SAML assertion on login and return the same assertion as long as the session is active on the identity provider.

In this case enter a duration which is at least as long as the maximum session lifetime on the identity provider.

For identity providers which always return a new assertion (e.g. nevisAuth) the value can be very low (e.g. 30s)

Enter unlimited to disable the maximum lifetime check for received SAML Responses. This sets in.max_age to -1 in the generated ServiceProviderState.

Selection Expression

The expression configured here will be used by nevisAuth to determine the IDP for SP-initiated SAML flows.

Configuration is required there are multiple SAML IDP Connector patterns assigned to the same SAML SP Realm.

For IDP-initiated flows the expression is not relevant as the IDP can usually be determined based on the Issuer contained in received SAML messages.

You may enter nevisAuth or EL expressions.

You must ensure that there is always exactly 1 expression which evaluates to true

If there is no match or multiple IDPs are applicable then 403 Forbidden is returned.

Examples:

IP of the user starts with 10.0.106: ${request:clientAddress:^10.0.106}
Request path starts with /myapp: ${request:currentResource:(http.?.//[^/]+)/myapp.*}

Artifact Resolution Service

Configure to enable HTTP Artifact Binding.

Enter the Location of the ArtifactResolutionService. This information can usually be found in the SAML metadata provided by the IDP.

The location must be a valid URL. In case of https:// import the CA certificate of the endpoint into the backend truststore of nevisAuth.

When a SAML artifact is returned by the IDP the service provider will send a request to the artifact resolution service to retrieve the SAML assertion.

Authentication Request: Lifetime

SAML authentication requests have a maximum lifetime which may be validated by the identity provider.

The lifetime should be low but high enough so that the authentication works on slow network connections.

Custom Properties

Enter custom properties for the nevisAuth ServiceProviderState.

Example: overwrite authnContextClassRef in the AuthnRequest

out.authnContextClassRef = urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified

Example: remove authnContextClassRef from AuthnRequest

out.authnContextClassRef =

Logout Type

Setting for SP-initiated logout, logout methods can be chosen

IMPLIED: the logout method will be used by getting configuration of Binding: Outbound
POST: force logout method to POST
SOAP: force logout method to SOAP. This only work when IdP SAML Response contain SessionIndex.

Custom Transitions

Add or overwrite ResultCond elements in the ServiceProviderState state.

This setting is advanced. Use without proper know-how may lead to incorrect behavior.

If you use this setting, we recommend that you contact Nevis to discuss your use case.

The position refers to the list of Additional Follow-up Steps. The position starts at 1.

Examples:

`ResultCond`	Position
status-Responder	1
status-Responder-AuthnFailed	2

The following ResultCond elements cannot be overruled by this setting:

ok
logout
logoutCompleted
logoutFailed

Custom Follow-up Steps

Assign follow-up steps.

The order of steps is relevant. The first step in this list has index 1.

You may reference a step in the configuration via the Custom Transitions.

Disable Restore Level States

Defines if the additional AuthStates need to be added for restore pre-adding context from Nevis SP

enabled (default): the additional AuthState will be added for context restoration from Nevis SP.
disabled: no additional AuthState will be added.

SAML Response Consumer

#Federation #Authentication #SAML #Experimental

The pattern exposes an authentication service on the assigned Virtual Host.

The service can consume incoming SAML Response or SAML artifact messages, and can execute an optional post-processing flow.

The overall process may work as follows:

Consume a SAML Response and RelayState on the Frontend Path. The RelayState must contain the URL of an application.
If configured, execute the Post-Processing Flow.
The authentication is now done.
Redirect to the RelayState parameter pointing to the application.
Assuming the application is protected by the realm assigned to this pattern, the caller is allowed access.

Frontend Paths

Enter a path where SAML Response messages sent by an external IDP shall be consumed.

The external IDP may send messages using POST or redirect binding.

SAML IDP Connector(s)

Assign a SAML IDP Connector for each SAML Identity Provider.

SP-initiated authentication is not supported and thus the Selection Expression of the connector patterns is ignored.

SAML Signer

Configure the key material for signing outbound SAML messages.

The following messages will be signed: ArtifactResolve, LogoutRequest, LogoutResponse

SAML Artifact Binding

To use SAML Artifact Binding with a certain IDP, the Artifact Resolution Service must be configured in the SAML IDP Connector.

The flow begins with the IDP sending an ArtifactResponse message to any of the configured frontend paths.

Now an ArtifactResolve message will be created and signed using this certificate. The message will then be sent to the IDP via a server-to-server call.

Authentication Processing Flow

Assign a step to apply custom post-processing logic, e.g. to enrich the authenticated user.

Virtual Host(s)

Assign a Virtual Host which shall serve as entry point.

Authentication Realm

Optionally assign a realm to protect this application or service.

SAML Issuer

Configure the Issuer used by this SAML Service Provider (SP).

This setting is used only when Artifact Binding is used.

Example: https://sp.example.org/SAML2

Logout Processing Flow (Experimental)

Assign a step to apply custom post-processing logic which is executed when a LogoutRequest or LogoutResponse message is received.

SAML SP Connector

#Federation #SAML #Connector

The pattern defines the connection to a SAML Service Provider (SP).

Assign the pattern to a SAML IDP.

SP Issuer

Configure the issuer used by the SAML service provider.

SP URL - Assertion Consumer Service(s)

Enter the Assertion Consumer Service URL of the SP.

Enter multiple values if the same SP can be accessed via multiple URLs.

If the SP is provided by a SAML SP Realm the URLs are structured as follows:

scheme, host and port: Frontend Addresses of each Virtual Host where the SAML SP Realm is used.
path component: Assertion Consumer Service of the SAML SP Realm.

The URLs are used during SP-initiated SAML authentication to validate incoming SAML requests. The assertionConsumerServiceURL attribute of received SAML AuthnRequest messages must match one of these URLs.

The first URL is also used for IDP-initiated authentication (property spURL of the IdentityProviderState).

IDP-initiated authentication may be triggered by sending a request to any of the Frontend Path(s) of the SAML IDP. The following parameters must be provided either in the query or as POST parameters:

Issuer - the unique name used by the SP (also called entityID in the SAML metadata).
RelayState - will be sent back to the SP together with the SAML Response when authentication is done.

In case the SP is setup by a SAML SP Realm this should a URL of an application protected by this realm.

SP URL - Single Logout Service

Enter the Single Logout Service URL of the SP.

If omitted the Assertion Consumer Service URL is used.

SP Signer Trust Store

Configure the trust store used to validate incoming SAML messages (e.g. AuthnRequest, LogoutRequest) which are sent by this SP.

Encrypted Content

Select a part of the outgoing message going to be encrypted from the service provider.

Message Encryption Trust Store

Assign a pattern to configure the certificate to encrypt the outgoing message to the service provider.

Outbound Binding

The Outbound Binding controls how SAML messages are returned to the service provider.

Choose a binding which is supported by the service provider.

Use http-redirect when the SAML Response has to be returned using a 302 Redirect.

Use http-post to generate a self-submitting form which produces a POST request. This binding is recommended as SAML Response messages will include a signature.

When http-post is selected, HTML encoding will be applied to the RelayState parameter to include it in the self-submitting form. This ensures that the parameter can be returned to the service provider, even when it contains special characters.

Subject

Set to use a different subject for the SAML Assertion.

Examples:

${sess:ch.nevis.session.loginid} - what the user has entered to login

Subject NameID Format

Set the format of the NameID element.

Examples:

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Subject Confirmation

Many SAML service providers require a subject confirmation element to be present in the SAML assertion.

Select bearer to add a bearer subject confirmation.

Further options may be provided in future releases.

It may be required to set additional properties. Consult the documentation of the nevisAuth IdentityProviderState and apply them via Custom Properties.

User Attributes

Add attributes to SAML assertions.

Values may be static, produced by a nevisAuth expression (${...}), or an EL expressions (#{...}). This table shows how to enter the configuration:

Attribute	Value
some_attribute	`${...}`
some_attribute	`#{...}`
some_attribute	`some_value`

Set the log level Vars = DEBUG and check the nevisAuth esauth4sv.log to find out which variables may are available.

For instance, if you have a nevisIDM Second-Factor Selection pattern in your authentication flow, you can use the expression ${sess:user.mobile} to add a mobile attribute.

Multi Value

This setting defines how multi-value attributes are added to the SAML Assertion.

Example for enabled:

<saml2:Attribute Name="example">
  <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">value 1</saml2:AttributeValue>
  <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">value 2</saml2:AttributeValue>
</saml2:Attribute>

Example for disabled:

<saml2:Attribute Name="example">
  <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">value 1,value 2</saml2:AttributeValue>
</saml2:Attribute>

Authentication Context Class

Select nevis if the SAML service provider is provided by a SAML SP Realm and you want to use Authorization Policy to specify the required Authentication Level for application protected by that realm.

When nevis is selected the roles and attained authentication level are added to the SAML Response via an AuthnContextClassRef element.

Example:

<saml2:AuthnStatement AuthnInstant="2021-05-07T06:48:14.967Z">
  <saml2:AuthnContext>
    <saml2:AuthnContextClassRef>...,nevisIdm.Admin,urn:nevis:level:1</saml2:AuthnContextClassRef>
  </saml2:AuthnContext>
</saml2:AuthnStatement>

Select PasswordProtectedTransport to add the following standard context:

<saml2:AuthnStatement AuthnInstant="2021-05-07T06:48:14.967Z">
  <saml2:AuthnContext>
    <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
  </saml2:AuthnContext>
</saml2:AuthnStatement>

Select none to not add any AuthnContext element.

Audience Restriction

Configure if an <AudienceRestriction> element shall be added to generated SAML assertions and what the element shall contain.

Choose between:

automatic: use Custom Audience, if configured, and SP Issuer otherwise.
issuer: use SP Issuer.
custom: use Custom Audience.
none: no <AudienceRestriction> element is added.

Custom Audience

Set custom audience(s).

If you need multiple <Audience> elements in the generated <AudienceRestriction>, enter multiple lines.

This configuration is ignored when Audience Restriction is set to issuer or none.

Check the documentation of the service provider on what is expected.

Assertion Lifetime

On successful authentication this IDP will issue a SAML assertion.

The SAML assertion is re-created on each session upgrade to avoid replay attacks.

The lifetime of the assertion should be low but high enough so that the authentication works on slow network connections.

The SAML assertion will be consumed by the service provider. The service provider should then use a different mechanism to track the user session (e.g. a session cookie).

Signed Element

Configure what to sign.

When nothing is selected then the option recommended is used.

With recommended the signed element depends on the Outbound Binding:

http-redirect: nothing will be signed as signing is not supported.
http-post: the Response is signed as this is most secure.

The setting none is not recommended for productive setups as it is vulnerable to attacks.

The setting Assertion may require additional checks on service provider side to close the attack vector. For instance, count the number of Assertion elements in the message.

Signature KeyInfo

The KeyInfo embedded into the signature informs the service provider about the signer credential used.

Enter one or several of the following elements:

SKI
Certificate
CertificateChain
Subject
IssuerSerial
CRLs
SubjectDNAsKeyName
SubjectCNAsKeyName
KeyNames
EntityID
PublicKey

Note that only configured fields defined in the signer certificate are actually added to the KeyInfo structure.

Minimum Required Authentication Level

Enforce a minimum required authentication level for this Service Provider.

If not set, the minimum required authentication level will depend on the incoming AuthnRequest. An SP may specify the level by including a RequestedAuthnContext, such as:

<samlp:RequestedAuthnContext Comparison="minimum">
  <saml:AuthnContextClassRef>urn:nevis:level:2</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

If there is any requirement for a minimum authentication level, the Authentication Realm must provide a Session Upgrade Flow for that level. See the help of the Authentication Realm pattern for details.

Note that when there is no authenticated session, the Initial Authentication Flow of the Authentication Realm will be executed first.

After successfully completing the Initial Authentication Flow the attained authentication level is compared against the minimum level and, if required, a Session Upgrade Flow is executed.

Required Roles

Check for required roles.

Roles provided by nevisIDM have the following format: <applicationName>.<roleName>. Roles provided by other systems (e.g. LDAP) may have a different format.

Examples:

myApp.Admin

Required roles are always checked at the end of authentication, after enforcing the Minimum Required Authentication Level (optional).

The user must have any of the enter roles to continue.

If the user does not have any of these roles, the authentication will fail and a SAML Response with status AuthnFailed message will be returned to the SP.

If you want to do custom error handling (e.g. show a GUI to the user), assign a step to On Forbidden.

On Forbidden

Configure a step that shall be executed when the Required Roles check fails.

Logout Mode

Configure the logout mode when a logout is initiated by or for this SP. Choose between:

ConcurrentLogout-Redirect: IdP will send logout to all SP(s) at once.
SingleLogout: IdP will send logout to 1 SP at a time.
SingleLogout-SOAP: IdP will send SOAP logout to SP(s) one by one using SOAP method.

Session Index

Set current session ID to SAML Response in SessionIndex element. This element is required for IDP-initiated logout and SP-initiated logout when Logout Type is set to SOAP.

The element will be included in SAML Response like:

<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response Destination=... >
 ...
 <saml2:Assertion ID=...>
  ...
  <saml2:AuthnStatement SessionIndex="JeBKZSJah-0m2QjC4LJ8u74LUOY2ayAeenlPgBOx1N8" ... >
            ...
  </saml2:AuthnStatement>
 </saml2:Assertion>
</saml2p:Response>

And in SAML LogoutRequest, the SessionIndex element will be included like:

<?xml version="1.0" encoding="UTF-8"?>
<saml2p:LogoutRequest Destination=...>
    ...
 <saml2p:SessionIndex>JeBKZSJah-0m2QjC4LJ8u74LUOY2ayAeenlPgBOx1N8</saml2p:SessionIndex>
</saml2p:LogoutRequest>

Custom Pre-Processing

Assign a step to apply custom pre-processing logic before validating the incoming request for this SP.

You may assign a chain of steps to build a flow.

The flow will be executed for all incoming requests, no matter if the user has a session already.

If you need to apply different logic for these 3 cases you can use Dispatcher Step and dispatch based on the following expressions:

${request:method:^authenticate$:true}
${request:method:^stepup$:true}
${request:method:^logout$:true}

The dispatching will continue after leaving this flow on the happy path.

For On Success exits this works automatically.

However, generic exits (i.e. Additional Follow-up Steps in Generic Authentication Step) must be marked as success exits by assigning the Pre-Processing Done pattern.

Authentication Request: Lifetime

SAML authentication requests have a maximum lifetime which may be validated by this identity provider.

Enter unlimited to disable the maximum lifetime check for received SAML AuthnRequests. This sets in.max_age to -1 in the generated IdentityProviderState.

Custom Properties

Configure properties of the nevisAuth IdentityProviderState.

Use this setting only when the pattern does not offer a more high-level way to achieve the required configuration.

Add or overwrite properties by entering a value.

Remove properties generated by this pattern by leaving the value empty.

Examples:

Key	Value
out.extension.Bearer	ch.nevis.esauth.auth.states.saml.extensions.SubjectConfirmationExtender
Bearer.inResponseTo	`${notes:saml.request.id}`
out.signatureKeyInfo	Certificate

Assertion Consume URL Validation

By default, the whitelist is calculated based on SP URL - Assertion Consumer Service(s). But in some special cases, you can use wildcards to allow a wide range of whitelisted urls. Examples:

*.mydomain.com
mydomain.com*

SAML SP Realm

#Federation #Realms #SAML

Represents a SAML Service Provider (SP).

Assign this pattern to applications to enforce authentication using SAML.

SAML Issuer

Set the Issuer used by this SAML Service Provider.

The issuer can be an arbitrary string but it is recommended to use the complete URL that the Assertion Consumer Service is exposed on.

Example: https://sp.siven.ch/SAML2/ACS/

SAML IDP Connector(s)

Assign a SAML IDP Connector for each SAML Identity Provider.

SP-initiated authentication with multiple IDPs requires a Selection Expression to be configured for each connector.

SAML Signer

Use a pattern to configure the signer certificate used by this Service Provider. If no pattern is assigned a key store will be provided automatically.

Assertion Consumer Service

Enter the path where SAML Response messages sent by the IDP shall be consumed.

This path also accepts LogoutRequest messages.

The IDP may send messages using POST or redirect binding.

Application Access Tokens

SAML Responses returned by the IDP are consumed in nevisAuth and not forwarded to applications.

If your application requires a token then you have assign a pattern which can produce that token here. For instance, assign a Nevis SecToken or SAML Token.

To forward the token to applications you also have to assign the token pattern to these applications via Application Access Token.

The token will be created on first access (missing token role triggers a stepup). In case of a session upgrade via SAML the token (role) is revoked and thus the token is recreated on the next access.

In your application you may use the Ninja authentication filter provided by NEVIS to extract user id, roles, and custom attributes.

nevisAuth

Assign a nevisAuth Instance pattern.

Key Store

Define the key store to use for 2-way HTTPs connections from nevisProxy to nevisAuth.

If no pattern is assigned automatic key management will provide the required key material. This requires that the nevisAuth Instance is part of this project and also uses automatic key management.

Automatic key management should be used for test setups only.

Trust Store

Defines the trust store that nevisProxy uses to validate the nevisAuth HTTPs endpoint.

If no pattern is assigned automatic key management is used to provide the trust store. This requires that the nevisAuth Instance is part of this project and also uses automatic key management.

Automatic key management should be used for test setups only.

Hostname Validation

Enable to verify that the hostname on the certificate presented by nevisAuth matches the configured hostname in the nevisAuth Instance or nevisAuth Connector pattern.

Internal SecToken Trust Store

Defines the trust store nevisProxy uses for validating the signature of the NEVIS SecToken issued by nevisAuth.

If no pattern is assigned automatic key management is asked to provide the trust store. This requires that the nevisAuth Instance is part of this project and also uses automatic key management.

Automatic key management should be used for test setups only.

OriginalURL SecretKey

If set, the parameter OriginalUrl.Enable of the IdentityCreationFilter will be set to true and the parameter OriginalUrl.SecretKey to the configured value.

This parameter solves many issues with multiple tabs, multiple frames, and incorrect redirects after login.

Custom Parameters (IdentityCreationFilter)

Add custom init-param elements to each IdentityCreationFilter generated by this pattern.

This pattern generates 2 IdentityCreationFilter elements:

Authentication_<name>: enforces authentication for applications.
SAML_<name>: provides the Assertion Consumer Service and Session Upgrade Path

If you want to patch only one of these filters consider using Generic Application Settings instead.

Note that the parameter InterceptionRedirect of the SAML_<name> filter is forced to never. If you configure InterceptionRedirect here it will be ignored for this filter as leads to message loss in SAML POST binding.

Examples:

BodyReadSize = 64000

Custom Parameters (SecurityRoleFilter)

Add custom init-param elements to the SecurityRoleFilter generated by this pattern.

Multi-line values, as required for conditional configuration, can be entered by replacing the line-breaks with \n.

Custom Parameters (Esauth4ConnectorServlet)

Add custom init-param elements to the Esauth4ConnectorServlet generated by this pattern.

That servlet is called Connector_<name>.

Multi-line values, as required for conditional configuration, can be entered by replacing the line-breaks with \n.

Examples:

Key	Value
EnablePollTerminatedCalls	true

Choose a login renderer.

In Kubernetes deployments, assignment of a renderer is mandatory.

Assign either a nevisLogrend Instance or a Proxy Login Renderer pattern.

The renderer has to be compatible with the Default Template (see Login Template tab).

In classic VM deployments, a default login renderer will be created when no pattern is assigned.

In case of nevisLogrend, the instance will be called default and deployed on the same host as nevisProxy.

Key Store

Configure a key store to use for 2-way TLS connections to nevisLogrend.

If no pattern is assigned no key store will be created.

The connection will be either 1-way TLS or plain HTTP, depending on the URL of nevisLogrend.

This configuration does not apply when a Proxy Login Renderer is used.

Trust Store

Configure a trust store to use for TLS connections to nevisLogrend.

If no pattern is assigned an automatic trust store will be created.

This configuration does not apply when plain HTTP or the Proxy Login Renderer is used.

Hostname Validation

When enabled the server cert has to match the hostname of nevisLogrend.

This configuration does not apply when plain HTTP or the Proxy Login Renderer is used.

nevisLogrend / Application default.properties

Add or overwrite properties in the default.properties of the nevisLogrend Application.

This is an advanced setting. Use only when there is no other alternative and consider creating a support ticket with your use case.

Check Login Application Configuration for supported properties.

We recommend not overwriting any language related properties, as the languages have to be in sync with nevisAuth. You can configure the supported languages on the nevisAuth Instance.

This setting requires that nevisLogrend is used for GUI rendering. Check the help of Login Renderer for details.

Template Style

Choose a default template:

classic: default in releases before May 2025.
modern: default since May 2025.
proxy: a template for the nevisProxy Login Renderer.

The modern template is recommended for new setups.

Company Logo

Upload a logo to be displayed on the login page.

The logo file should have an appropriate size, e.g. 50x50 pixels.

Out of the box, this setting is supported by the modern template only.

If you use a different nevisLogrend template, you can add the expression ${logo} to point to the uploaded file.

Download the modern template to see how the expression is used there.

Primary Color

Configure the primary color.

Out of the box, this setting is supported by the modern template only. It is used to color buttons.

If you use a different nevisLogrend template, you can add the expression ${primaryColor} in your CSS file.

Download the modern template to see how the expression is used there.

Border Radius

Configure the corder radius of the login box.

Out of the box, this setting is supported by the modern template only.

If you use a different nevisLogrend template, you can add the expression ${borderRadius} in your CSS file.

Download the modern template to see how the expression is used there.

Font Family

Configure the font family.

By default, this setting is supported by the modern template only.

If you use another template, you can reference the expression ${fontFamily} in your CSS file. Check the modern template for an example of how the expression is applied.

The actual font used depends on the browser and operating system.

You can specify multiple font families, separated by commas, to provide fallbacks. The CSS files in the template append additional fonts to ensure all characters (even emojis) can be rendered.

This approach follows the idea described here: Bootstrap Native Font Stack.

Example values:

Arial, sans-serif
Helvetica, Arial, sans-serif
Times New Roman, serif

Template Customization

Customize the rendering of login pages.

Download one of the default templates to get started.

nevisLogrend: Direct Mode

You can upload Velocity template files and resources to nevisLogrend.

Zip files will be extracted into the nevisLogrend application:

/var/opt/nevislogrend/<instance>/data/applications/<realm>

Flat files will be added to the following subdirectories:

webdata/template: Velocity templates (*.vm)
webdata/resources: static resources (e.g. images, CSS, Javascript)

nevisLogrend: Expressions

In nevisLogrend templates you may use the following expressions:

Expression	Description
`${form}`	login form (`form.vm`)
`${lang.switch}`	language switcher component (`lang.vm`)
`${lang.code}`	current language code (i.e. `en`, `de`)
`${label.myLabel}`	a label which must be translated via `Custom Translations`
`${resources}`	path to static resources (e.g. CSS, images, Javascript)
`${resource:<name>}`	path to static resource `name` with attached hash

These expressions will be replaced with a corresponding Velocity snippet at generation time.

For instance, using the expression ${resource:bootstrap.min.css} with the modern template yields the following path:

${login.appDataPath}/resources/bootstrap.min.css?v=3f1c72e8.

Note that the expression ${login.appDataPath} is handled at runtime by nevisLogrend.

nevisProxy provides a basic login renderer which can be used instead of nevisLogrend. See Login Renderer for details.

For each enabled language (e.g. en) upload a file named <lang>_template.html. The template must contain the placeholder NEVIS_AUTH_FORM.

If your templates require additional resources (e.g. CSS, images) upload them as Hosted Resources on the nevisProxy virtual host.

nevisLogrend: Simple Mode

In simple cases you may not have to deal with Velocity template files.

To replace the outer HTML you can upload a file named template.html. The template must contain the ${form} expression.

Here is a simple example:

<!DOCTYPE html>
<html lang="${lang.code}">
  <head>
    <title>${label.title}</title>
    <link href="${resources}/bootstrap.min.css" rel="stylesheet" type="text/css">
    <link href="${resources}/default.css" rel="stylesheet" type="text/css" media="all">
  </head>
  <body>
    <header id="header" class="container-fluid">
      <img class="logo center-block" src="${resources}/logo.png" alt="Company Logo">
    </header>
    <main id="content" class="container">
      ${form}
    </main>
  </body>
</html>

Customization Mode

Choose between:

additive: files uploaded as Login Template will be added on top of the default.
- Use this option when you want to add or replace files, but do not want to upload an entire template.
complete: only the files uploaded as Login Template will be deployed.
- Use this option when you want to provide the entire template.

Default Translations

Choose between:

enabled - add translations for labels which are commonly used

(e.g. title or language.* labels in nevisLogrend, error.* labels in nevisAuth) and which are provided by realm patterns (e.g. assigned authentication steps).

disabled - add only what has been uploaded via Custom Translations.

If your translations are incomplete, users will see the untranslated labels.

Note that nevisAuth supports only 1 set of translations and the generation is cumulative. Thus, if you have 1 nevisAuth Instance with multiple realms, and you want to leave out default labels, then you have select disabled in all these realms.

Custom Translations

Labels are used to provide human-readable text in the language of the user. Here you can overwrite the defaults and add your own translations.

The name of uploaded files must end with the language code. As the format is compatible you may upload existing text_<code>.properties files of nevisLogrend or LitDict_<code>.properties of nevisAuth.

The encoding of uploaded files does not matter as long as all translations are HTML encoded.

So far this property is relevant only if the Logout Reminder feature is enabled because then a page will be rendered. The following labels are used:

title - used as browser page title
logout.text
language.<code> - used by language switch component
info.logout.reminder
continue.button.label

Translation Mode

Choose between:

combined - upload 1 file per language code named labels_<code>.properties.

The labels will be added to both nevisAuth and nevisLogrend. Alternatively, you can upload a zip file called labels.zip containing these properties files.

separate - select only when you need different labels in nevisAuth and nevisLogrend.

The files must be called LitDict_<code>.properties for nevisAuth and text_<code>.properties for nevisLogrend. Alternatively, you may upload zip file called LitDict.zip and text.zip containing these properties files.

Each realm has its own session cookie. By default, this cookie will be called Session_<pattern-name>

Set this optional property to use a different name (e.g. ProxySession).

Note that each realm has its own session. However, if the same cookie name is configured for multiple realms running on the same host the sessions will be cleaned up together when the first session expires.

In February 2020 Chrome 80 has been released which treats cookies without SameSite flag as Lax.

This change can break cross-domain use cases (e.g. SAML).

Thus, it is recommended to select None here.

If None is selected, and you have to support older browsers also check Cookie Same Site Relaxation.

If you do not expect any requests from other domains, you may also go for Lax or Strict as this increases security.

Some older browsers treat cookies with SameSite=None as Strict.

See this example bug report for Safari:

Bug 198181 - Cookies with SameSite=None or SameSite=invalid treated as Strict

Enable this feature to map a filter to the root location /* which evaluates the User-Agent request header to remove SameSite=None for browsers which are known to be affected.

Configures the number of seconds a cookie is still valid after a new cookie is generated, for example, due to a successful login.

Increasing the value can help minimize the chance of session loss during a login or step-up with parallel requests.

Session Validation

A newline separated list of rules declaring attributes that must not change in the same session. A rule has the following syntax:

AUTH|ENV|CONST|PARAM|HEADER:<name of the attribute>:block|invalidate

block: the request will be blocked and 403 (Forbidden) will be returned
invalidate: the session will be invalidated and a new one will be created

nevisProxy Conditions are supported. See nevisProxy reference guide for details.

For instance, use the following configuration to terminate the session if the source IP changes:

ENV:REMOTE_ADDR:invalidate

Initial Session Timeout

Define the idle timeout of the initial session. The user must complete the authentication within this time.

Authenticated Session Timeout

Define the idle timeout of an authenticated session.

Max Session Lifetime

Define the maximum lifetime of an authenticated session. The session will be removed after that time even if active.

Update Session Timestamp Interval

Sets the minimum time interval between two updates of the session timestamp.

If the parameter is set to "0", the system will update the session timestamp each time a request accesses a session.

The Initial Session Timeout is used as Update Session Timestamp Interval if it is shorter than the duration configured here.

Timeout Page

Renders a timeout page when the user session has expired.

This is different from the Logout Reminder Page feature which also show a page when the user comes back after closing the browser.

The page contains a heading, an info message and a continue button. You can customize them via Custom Translations by setting the following labels:

title.timeout.page
info.timeout.page
continue.button.label

For this feature an additional cookie Marker_<name> will be issued. The value will be set to login or logout depending on the last user action.

The following requirements must be fulfilled:

Usage of HTTPs to access the application and for the entire SAML process.
No other session expiration feature must be used.

Timeout Redirect

Enter a URL or path to redirect to after session timeout.

The redirect is executed on next access when the session has expired.

This is different from the Logout Reminder Redirect feature which also performs the redirect when the user comes back after closing the browser.

For this feature an additional cookie Marker_<name> will be issued. The value will be set to login or logout depending on the last user action.

The following requirements must be fulfilled:

Usage of HTTPs to access the application and for the entire SAML process.
No other session expiration feature must be used.

Custom Parameters (SessionManagementFilter)

Add custom init-param elements the SessionManagementFilter generated by this pattern.

Examples:

Key	Value
Cookie.Persistent	true
Cookie.Path	/some/path

Logout Reminder Page

Enable this feature to show a logout reminder page.

The page will be shown on next access in the following cases:

the user has closed the browser
user session has expired due to idle timeout

The page contains a heading, an info message and a continue button. You can customize them via Custom Translations by setting the following labels:

title.logout.reminder
info.logout.reminder
continue.button.label

For this feature to work an additional cookie Marker_<name> will be issued. The value will be set to login or logout depending on the last action of the user.

The following requirements must be fulfilled:

Usage of HTTPs to access the application and for the entire SAML process.
No other session expiration feature must be used.

Logout Reminder Redirect

Enter a URL or path to redirect to when a user accesses, and the session has expired.

The redirect is executed on next access in the following cases:

the user has closed the browser
user session has expired due to idle timeout

The following requirements must be fulfilled:

Usage of HTTPs to access the application and for the entire SAML process.
No other session expiration feature must be used.

Logout Mode

Defines how this SP should react when an SP-initiated logout completes on this SP.

redirect-target: redirects to a defined path or URL.

When this option is selected a Logout Target must be entered.

redirect-state: redirects according to the RelayState query parameter

received in combination with the LogoutResponse. The IDP is expected to return this parameter as-is and thus the RelayState should contain the URL where the logout was initiated. As this is a protected application URL authentication will be enforced and the user will be sent to the IDP again to perform a login.

Logout Target

Enter a path or URL to redirect to when an SP-initiated SAML logout completes on this SP.

The redirect is performed only when Logout Mode is set to redirect-target.

Session Upgrade Path

Applications may redirect to this location to force the SP to invoke the IDP again by sending an AuthnRequest.

This mechanism allows applications to enforce a session upgrade.

The URL must contain the following query parameters:

relayState: the path to redirect to after successful session upgrade.
level: the required authentication level (2-9). The level will be sent to the IDP within the RequestedAuthnContext.

Tokens produced by Application Access Token patterns assigned to applications will be re-created on next access to reflect updated user data.

Example for RequestedAuthnContext with level=2:

<saml2p:RequestedAuthnContext>
  <saml2:AuthnContextClassRef xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">urn:nevis:level:2</saml2:AuthnContextClassRef>
</saml2p:RequestedAuthnContext>

Custom Pre-Processing

Assign a step to apply custom pre-processing logic before executing SP-initiated SAML authentication. This pre-processing logic is executed for methods: authenticate, stepup, unlock, and logout.

You may assign a chain of steps to build a flow. The dispatching will continue when leaving this flow on the happy path.

For On Success exits this works automatically.

However, generic exits (i.e. Additional Follow-up Steps in Generic Authentication Step) must be marked a success exits by assigning the Pre-Processing Done pattern.

Post-Processing

Assign a Generic Authentication Step to apply custom post-processing logic to an SP-initiated SAML process (e.g. authentication, session upgrade, or logout).

By assigning a step here the last AuthState of the process will be replaced so that it points to the first AuthState provided by the assigned step. This AuthState should be marked with the name ${state.entry}.

Use the expression ${state.done} to complete with the SAML process.

#Federation #Authentication #OAuth #OpenID Connect

Creates a new account in nevisIDM for the logged-in user.

On Success

The step executed after a successful authentication. If no step is configured here the process ends with AUTH_DONE.

Note: In order to have profile selection in case account have multiple profiles, you need to use the User Lookup pattern.

Unit External ID

The ExtId of the unit in nevisIDM that will be used to store the user

#Federation #Authentication #OAuth #OpenID Connect

Use this step to terminate On User Found and On User Not Found flows of social login patterns (e.g. Google Login, Apple Login).

The step ensures that the conversation is completed (AUTH_DONE or AUTH_ERROR), and the user is redirected back to the originally requested path.

This step can be omitted when federation is used to access authentication as the caller will be redirected in this case.

In you flow you have to create or link the user. You can use Social Login Link User and Social Login Create User for this.

Status

Choose how to complete the flow:

AUTH_DONE: user is authenticated
AUTH_ERROR: session is terminated

In both cases the caller is redirect back to the path before jumping of to the social login provider.

When social login is behind federation (e.g. SAML IDP), AUTH_ERROR will be handled by sending the caller back to the origin (e.g. the SAML SP) with a technical error message.

#Federation #Authentication #OAuth #OpenID Connect

Use to link to an existing user account.

On Success

The step executed after a successful authentication. If no step is configured here the process ends with AUTH_DONE.

Note: In order to have profile selection in case account have multiple profiles, you need to use the User Lookup pattern.

User External ID

By default, the extId is taken from the request.

Here you can enter a different source for the extId.

Examples:

${sess:ch.nevis.idm.User.extId}

This setting only has to be set when you have specific patterns in yoru flow that determine the user to link to.

#Federation #Authentication #OAuth #OpenID Connect

Creates and verifies Swiss e-ID logins with swiyu. For more information, see the swiyu documentation

Verifier Base URL

The URL where the verifier service is available. For example https://swisseid-verifier.mctsnr.getnevis.net

Accepted Issuer DIDs

DIDs of the credential issuers whose e-IDs this verifier accepts (e.g. the Beta Credential Service (BCS) issuer DID). Enter one value per line. At least one DID is required.

On Success

The step executed after a successful authentication. If no step is configured here the process ends with AUTH_DONE.

In case you change this to your custom step(s), you can assign pattern Social Login Final Step as the last step of the Authentication process to redirect back to original URL.

On Failure

The step that will be executed if the authentication fails. If no step is configured here the process ends with AUTH_ERROR.

WaltID Step

#Federation #Authentication #OAuth #OpenID Connect

This pattern implements the WaltID authentication step. WaltID is a decentralized identity solution that allows users to authenticate using their electronic identification.

See more details in the WaltID documentation.

Verifier URL

Enter a valid verifier URL for WaltID. If nothing is set, the default verifier URL (https://verifier.demo.walt.id) is used.

On Success

Set the step to continue with on successful authentication. If no step is configured here the process ends with AUTH_DONE.

On Failure

Set the step to continue with in case of error. If no step is assigned an AuthState named <Realm>_Authentication_Failed is generated.

Access Token Consumer​

On Success​

On Missing Token​

OAuth 2.0 Authorization Server / OpenID Provider​

Apple Login Step​

Client ID​

Client Secret​

Return Path​

Scope(s)​

Virtual Host​

On Success​

On Failure​

Private Key​

Issuer​

nevisIDM​

Client External ID​

On User Not Found​

On User Found​

Claims Request​

User ID Field​

Additional Auth Request Parameters​

Button Label​

Facebook Login Step​

Client ID​

Client Secret​

Return Path​

Scope(s)​

Virtual Host​

On Success​

On Failure​

nevisIDM​

Client External ID​

On User Not Found​

On User Found​

Claims Request​

User ID Field​

Additional Auth Request Parameters​

Button Label​

Generic Social Login Step​

Provider Type​

Client ID​

Client Secret​

Return Path​

Scope(s)​

Virtual Host​

On Success​

On Failure​

Client Secret Method​

Response Mode​

PKCE​

PKCE Secret​

Code Challenge Method​

Provider Endpoint​

Authorization Endpoint​

Token Endpoint​

User Information Endpoint​

JWKS Endpoint​

nevisIDM​

Client External ID​

On User Not Found​

On User Found​

Account Linking - User Property​

First Name Claim​

Second Name Claim​

Email Claim​

Subject Claim​

Claims Request​

User ID Field​

Additional Auth Request Parameters​

Button Label​

Button CSS class​

Button Logo Path​

Google Login Step​

Client ID​

Client Secret​

Return Path​

Virtual Host​

Scope(s)​

On Success​

On Failure​

Access Token Consumer

On Success

On Missing Token

OAuth 2.0 Authorization Server / OpenID Provider

Apple Login Step

Client ID

Client Secret

Return Path

Scope(s)

Virtual Host

On Success

On Failure

Private Key

Issuer

nevisIDM

Client External ID

On User Not Found

On User Found

Claims Request

User ID Field

Additional Auth Request Parameters

Button Label

Facebook Login Step

Client ID

Client Secret

Return Path

Scope(s)

Virtual Host

On Success

On Failure

nevisIDM

Client External ID

On User Not Found

On User Found

Claims Request

User ID Field

Additional Auth Request Parameters

Button Label

Generic Social Login Step

Provider Type

Client ID

Client Secret

Return Path

Scope(s)

Virtual Host

On Success

On Failure

Client Secret Method

Response Mode

PKCE

PKCE Secret

Code Challenge Method

Provider Endpoint

Authorization Endpoint

Token Endpoint

User Information Endpoint

JWKS Endpoint

nevisIDM

Client External ID

On User Not Found

On User Found

Account Linking - User Property

First Name Claim

Second Name Claim

Email Claim

Subject Claim

Claims Request

User ID Field

Additional Auth Request Parameters

Button Label

Button CSS class

Button Logo Path

Google Login Step

Client ID

Client Secret

Return Path

Virtual Host

Scope(s)

On Success

On Failure