Configuration

In development, the authentication configuration is used by the development server launched by the "neos run" command. The configuration has to be done in a YAML configuration file of the cluster. When the authentication configuration changes, there is no need to regenerate.

In production, the authentication configuration is used by the gateway. The configuration must be done in the gateway configuration file.

Configuring authentication can be complex, so the framework provides presets to make it easy and to fit the most common scenarios. It is also possible to provide a complete configuration without preset to address more specific cases.

Presets

The standard development server (default)

By default, when a cluster is created via the neos init command, an authentication configuration is defined in the configuration.auth.yml file:

Authentication:
  Preset: NeosDevAuth

We provide a standard authentication server that can be used by clusters under development.

This authentication server offers a connection via a unique identifier and password, but also a connection via the Groupe Isagri Active Directory.

During development, you can log in with your Groupe Isagri Active Directory account or delete the authentication configuration file.

The registration of new users is not yet publicly available because it will be managed by the "Users" transversal module. This development is in progress.

It is important to note that the authentication server is not yet ready to be used in production. It will be improved as we go along as we plan to make it the standard solution we offer to all collaborators.

The source code of the project is available on Azure DevOps.

External providers

It is also possible to set up an authentication through an external provider.

This scenario is ideal to avoid having the responsibility of the authentication server.

Here you will find guides for several external provider (the list will grow as time goes on):

• Azure Active Directory
• Auth0
• Azure AD B2C

If you need an authentication with several providers at the same time (for example a Google connection, a Microsoft connection and a classic login/password connection), you will have to use a custom authentication server (like Auth0, Okta or an homemade authentication server).

Manual configuration

If the framework does not provide a preset for the desired authentication server, you can specify a complete configuration using this template :

Authentication:
  Authority: # (required) The URL of the authentication server.
  ClientId: # (required) The resource identifier of the cluster.
  ClientSecret: # (optional) The resource secret of the cluster.
  Scopes: # (optional) The list of scopes so that the cluster must have access.
  UserPropertiesMap: # (optional)
    Name: # (optional) The name of the token property used to retrieve the user's name to populate the `Name` property of the Neos user. (`name` by default)
    Email: # (optional) The name of the token property used to retrieve the user's email to populate the `Email` property of the Neos user. (`email` by default)
  CookieLifetimeInHours: # (optional) The cookie lifetime in hours. 48 hours by default.

Example with a custom authentication server :

Authentication:
  Authority: https://localhost:5001
  ClientId: b68c22cc-6e48-4ff8-bf3f-49f70e388376
  Scopes:
    - custom_scope
  UserPropertiesMap:
    Name: username
    Email: principal_email
  CookieLifetimeInHours: 72

If you want to use a custom authentication server, the authentication server must comply with the OpenID Connect standard and allow the "Authorization Code Flow + PKCE" flow.

If you want to use the standard development authentication server that we offer in production and/or you want to adapt a behavior, you must fork the project, adjust it and deploy it by yourself.

User synchronization with authentication provider

To be able to synchronize a user from your cluster to the authentication provider, you'll need to set the AuthenticationMode configuration property with one of the following value :

• AzureB2C for synchronization with Azure AD B2C provider.
• Neos for synchronization with Neos dev auth provider.

Production

In production, authentication is configured at the Gateway level.

It must be put in the gateway secret, please see this article for more information.