Introduction

Each application may consist of multiple clients. For example an online web shop might have a native iOS application, an Android APP, a web based version and an API for external suppliers. Each of those represent a client which can have different settings and different security settings. Be sure to identify your clients correctly and not to reuse the same client settings for multiple clients. It’s possible to use the same client in multiple parts of your software, but always keep in mind that this will affect your overall security structure as you loose the ability to change client secrets for a single part, authentication redirect URLs can not be restricted to the minimum and so on.

Parameters

General

Name	Datatype	Mandatory	Example	Description

Name	Datatype	Example	Description
Token specification	Drop Down	oidc	Choose any of the supported token specification `oidc`, `saml2p` or `ws-fed`. Depending on your selection, the subsequent parameters might change.
Client identificator	String	webshop_android	Each client must be uniquely identified. Provide a value that you also must use in the clients configuration later on. Choose either something self explanatory or a random value if you wanna hide the purpose of the client as a security measurement.
Name	String	Android Webshop Application	Identifies your client in a technical way in the system
Displayname	String	Android Webshop Application	Non technical name used to display the application in various places such as the Self-Service Portal Version 7 and above
Logout URI	URL	https://www.webshop.com/logout	If no logout URL is provided by the client, the user will be redirected to this URL after a logout.
Redirect Uri (Regex) *	REGEX Pattern	regex:^https:\/\/webshop\.ch$	The client provides an URL where the user will be redirected to after a successful authentication. It’s good practice to test those URLs against a pattern to ensure that the user can only be redirected to previously configured URLs. This will significantly increase the security of the system. Wildcards can be configured, but only do this when absolutely necessary.
Scope	Multi Value	profile email	A list of scopes that the client can request. If the client requests a scope that is not part of this configuration, he will not be able to perform an authentication. Be careful to only allow the scopes that are really necessary for the application to work with.
Default level of authentication entry	Drop Down	Default	Select a default level of authentication entry that will be used to determinate the authentication flow for the user.
Validate user password using Application Service	Checkbox		Indicates if backend should be used to validate user password (which involves API call and checks password as well as password policies). Otherwise validation is done internally in Authentication Service and password policies are not checked. Default value - `TRUE`

Token

For an in detail description of the various tokens, see the Token documentation.

Name	Datatype	Mandatory	Example	Description

Name	Datatype	Example	Description
Identity Token Life Time	Seconds	3600	Defines the lifetime of the identity token that will be issued for a user.
Access token life time	Seconds	3600	Defines the lifetime of the access token that will be issued for a user and a specific client.
Authorization code life time	Seconds	60	Defines the lifetime of the authorization code that will be used in some authentication processes. Less is more secure!
Refresh token expiration type	Drop Down	Absolute	`absolute` the refresh token will expire on a fixed point in time (specified by the AbsoluteRefreshTokenLifetime). This is the default. `Sliding` when refreshing the token, the lifetime of the refresh token will be renewed (by the amount specified in SlidingRefreshTokenLifetime). The lifetime will not exceed AbsoluteRefreshTokenLifetime.
Sliding refresh token life time	Seconds	1296000 / 15 days	Sliding lifetime of a refresh token in seconds.
Absolute refresh token life time	Seconds	2592000 / 30 days	Maximum lifetime of a refresh token in seconds
Always include user claims in id token	Checkbox	false	When enabled the requested user claims are included in the id token. If disabled the user claims have to be requested from the user info endpoint.
Update access token claims on refresh	Checkbox	true	Defines whether or not the access token should be refreshed when a refresh token is requested
Include JSON web tokens	Checkbox	true	Specifies whether JWT access tokens should have an embedded unique ID (via the jti claim).
Refresh token usage type	Drop Down	OneTime	`ReUse` the refresh token handle will stay the same when refreshing tokens `OneTime` the refresh token handle will be updated when refreshing tokens.
Access token type	Drop Down	JWT	Specifies whether the access token is a reference token or a self contained JWT token
Custom subject type	Drop Down	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress	Specifies what will be delivered as the identifier in the token, for OpenId Connect it will set the sub claim and for SAML the NameIdentifier.

Authentication

Name	Datatype	Mandatory	Example	Description

Name	Datatype	Example	Description
Require Consent	Checkbox	false	Defines whether or not the user needs to give consent when accessing this client.
Allow remember me	Checkbox	false	Whether or not the user is presented with the option to select “remember me” which will cause the persistence of a cookie in the clients browser for any subsequent logins.
Enable local authentication	Checkbox	true	Specifies if this client can use CoreOne Suite users, or external providers only.
URI	string	https://www.coreone.ch	The url of the client / application.
Email verification redirect uri	REGEX Pattern	regex:^https:\/\/webshop\.ch$	If any external systems are using urls to verify the mail address of authentication users, the provided redirect uri in the link will be tested against this configured pattern.
Post logout redirect URI's	REGEX Pattern	regex:^https:\/\/webshop\.ch$	The client provides an URL where the user will be redirected to after being logged out. It’s good practice to test those URLs against a pattern to ensure that the user can only be redirected to previously configured URLs. This will significantly increase the security of the system.
Identity provider restrictions	REGEX Pattern	regex:^https:\/\/swissid\.ch$	Defines a list of allowed external identity providers that are allowed. If you do not specify any, all configured IdPs are allowed. Version 7 and above
Required Multi-Factor Authentication	Checkbox	true	Whether or not a MFA authentication is required for the client Deprecated version 6 and above
Allow self-registration	Checkbox	true	Whether or not a self registration is allowed for this client or not.
Activation disabled	Checkbox	true	If the activation process is enabled in the system, you can disable it for a specific client.
Show in self-service	Checkbox	true	Whether or not the client should be listed in the user self-service portal.

OpenID Connect

Those options are only available if the token specification oidc was selected.

Name	Datatype	Mandatory	Example	Description

Name	Datatype	Example	Description
Allowed Cross-Origin Resource Sharing origins	string	http://www.externalorigin.com	A collection of sources that will be used in the CORS policy.
Require client secret	Checkbox	true	Whether or not the client needs a secret to request a token or not.
Require PKCE	Checkbox	true	Whether clients using an authorization code based grant type must send a proof key.
Allow plain text PKCE	Checkbox	false	Whether clients using PKCE can use a plain text code challenge.
Allow access token via browser	Checkbox	false	Whether this client is allowed to receive access tokens via the browser.
Allow offline access	Checkbox	false	Specifies whether this client can request refresh tokens (by requesting the `offline_access` scope)
Flow	Multi Select	authorization code	One of the following grant types according to the OIDC and OAuth 2 specification `Implicit` `Authorization code` `Hybrid` `Client credentials` `Resource owner password` `Device flow` `Refresh tokens` `Extension grants` See also https://itsense.atlassian.net/l/c/Tk3J589J
Secret	Password	* * * * * * *	The secret that will be shared with the client.
BackChannelLogoutUri	String	https://localhost:5411/backchannel-logout	Backchannel logout URL. Logout token will be send there with POST method when user logs out from different client but is also logged in with this client.

Relying party

Those options are only available if the token specification ws-fedwas selected.

Name	Datatype	Mandatory	Example	Description

Name	Datatype	Example	Description
Signature algorithm	Drop Down	Sha256	Any signature algorithm that is installed on the server
Digest algorithm	Drop Down	Sha256	Any digest algorithm that is installed on the servers
Saml name identfier format	Drop Down	Email Adress	The format of the saml name identifier format
Token type	Drop Down	Saml 2.0	The format of the token. Either `SAML 1.0` or `SAML 2.0`

Service

Those options are only available if the token specification saml2pwas selected.

Name	Datatype	Mandatory	Example	Description

Name	Datatype	Mandatory	Example	Description
Require Saml Request Destination	Checkbox		true	Defines whether or not a Saml Requestion Destination has to be present in the AuthnRequest in order to start the authentication
Sign assertions	Checkbox		true	Defines if our saml response is signed with the configured certificate
Signing certificate type	Drop Down	Only when sign assertions is checked	Windows store	The format of the certificate. It can either be hosted in the `Windows store` or added directly to the configuration as a `Base64 encoded` text.
Signing certificate	Certificate	Only when sign assertions is checked	MyCert	See above.
Encrypt assertions	Checkbox		true	Defines if our saml response is encrypted with the configured certificate
Encryption certificate type	Drop Down	Only when sign assertions is checked		The format of the certificate. It can either be hosted in the `Windows store` or added directly to the configuration as a `Base64 encoded` text.
Encryption certificate	Certificate	Only when sign assertions is checked		See above.

Client