SSO Authelia

Authelia est un serveur d’authentification et d’autorisation open source fournissant une authentification à deux facteurs et une authentification unique (SSO) pour vos applications via un portail Web.

Authelia

Site web officiel : https://www.authelia.com/

• Open source
• SSO
• Authentification 2F avec Yubikey
• OTP basé sur le temps avec Google Authenticator
• Prend en charge LDAP
• Prend en charge Active Directory
• Fonctionne avec les proxys inverses
• Notifications push avec duo
• Bloquer les attaques de force brute
• Vérification d’identité
• Une meilleure gestion des mots de passe
• Flux de travail flexible
• UI intuitif

Prérequis et liens

Un serveur debian + nginx

Installer Authelia

Installation par fichier deb

# Télécharegement fichier deb
wget https://github.com/authelia/authelia/releases/download/v4.39.13/authelia_4.39.13-1_amd64.deb
# droits à l'utilisateur _apt pour l'installation
sudo chown _apt: authelia_4.39.13-1_amd64.deb
# installation authelia et ses dépendances
sudo apt install ./authelia_4.39.13-1_amd64.deb
# redis est utilisé
sudo apt install redis

Configurer authelia

Configuration authelia sur serveur cwwk rnmkcy.eu 192.168.0.205

• Serveur: 127.0.0.1:9091
• Gestion utilisateurs: LLDAP
• Authentification: TOTP + Webauthnn
• Stockage: Base mysql
• Notification: SMTP

Clé de configuration	Signification	Exemple
jwt_secret	Une chaîne aléatoire qui ne peut pas être devinée par un attaquant	Générez-en une en tapant head /dev/random | tr -dc A-Za-z0-9 | head -c64 > jwt_secret.txt et collez-la ici entre guillemets.
default_redirection_url	Si l’utilisateur navigue directement vers auth.myhome.com, Authelia ne peut pas déduire où le rediriger. Il s’agira donc probablement d’une page lister-toutes-les-applications-disponibles	https://www.myhome.com
default_2fa_method	2FA est l’abréviation de 2 factor authentication (authentification à deux facteurs). Il s’agit du processus ennuyeux qui vous demande d’entrer le code que vous avez reçu par SMS ou par l’intermédiaire d’une application d’authentification.	“totp”, au moins c’est gratuit
server/host	Attention! Le serveur d’authentification est un serveur qui ne peut pas être utilisé par les utilisateurs de l’Internet. Si vous laissez la valeur par défaut 0.0.0.0 alors Authelia écoutera sur l’interface réseau de votre serveur. Mais ce n’est pas ce que vous voulez une fois que le serveur est en production, puisque nous allons le faire fonctionner derrière un reverse proxy pour HTTPS.	Lors de la configuration, laissez 0.0.0.0 mais changez pour 127.0.0.1 une fois que tout est configuré.
log/level	Changez pour info une fois que tout est en cours d’exécution	info
authentication_backend	Activez les sous-clés file et file/path pour faciliter l’utilisation dans un premier temps. Ci-dessous, vous trouverez ce qu’il faut stocker dans ce chemin d’accès	Changez path en /etc/authelia/users_db.yml
access_control	Cette partie est un peu complexe, donc regardez ci-dessous pour une explication	Voir ci-dessous
access_control/rule/…/policy	N’importe lequel de deny (rejette la requête), bypass (relai transparent de la connexion), one_factor (demande de login & mots de passe), two_factor (demande de login & mot de passe + preuve de possession d’un appareil)	Voir ci-dessous pour un exemple
session/domain	Typiquement, définir le domaine de base	myhost.com
session/secret	Une autre chaîne aléatoire qui ne peut pas être devinée par un attaquant	Générez-en une en tapant head /dev/random | tr -dc A-Za-z0-9 | head -c64 > session_secret.txt et collez-la ici entre guillemets.
storage	Activez cette option, car elle est nécessaire pour stocker les données de session.
storage/encryption_key	Une autre chaîne aléatoire qui ne peut pas être devinée par un attaquant	Générez-en une en tapant head /dev/random | tr -dc A-Za-z0-9 | head -c64 > session_secret.txt et collez-la ici entre guillemets
notifier	Vous devez définir au moins un notificateur pour que Authelia puisse communiquer avec vous et ses utilisateurs

La génération du “secret” base 64 se fait en ligne de commande

# Commande 
head /dev/random | tr -dc A-Za-z0-9 | head -c64 
# OU
tr -cd '[:alnum:]' < /dev/urandom | fold -w 64 | head -n 1 | tr -d '\n' ; echo

LLDAP est utilisé pour la gestion utilisateur

Stockage géré par une base mariadb (mysl)
Créer une base mariadb
Host : 127.0.0.1
Base : authelia
Utilisateur : authelia
Mot de passe : Mot_de_passe_base_authelia

En ligne de commande

sudo mariadb -e "create database authelia; grant all privileges on authelia.* to authelia@'localhost' identified by 'Mot_de_passe_base_authelia'; flush privileges;"

WebAuthn
Paramètre user_verification :

• discouraged : Le client sera découragé de demander une vérification à l’utilisateur.
• preferred : Le client, s’il est conforme, demandera à l’utilisateur une vérification si l’appareil la prend en charge.
• required : Le client demandera à l’utilisateur une vérification ou échouera si l’appareil ne prend pas en charge la vérification.

attestation_conveyance_preference:

• none : Le client recevra l’instruction de ne pas effectuer de transfert de propriété.
• indirect : Le client reçoit l’instruction d’effectuer le transfert de propriété, mais il peut choisir la manière de le faire, y compris en utilisant une AC d’anonymisation tierce.
• direct : Le client recevra l’instruction d’effectuer le transfert avec une déclaration d’attestation directement signée par le dispositif.

Le fichier de configuration /etc/authelia/configuration.yml

Etendre Réduire configuration.yml

  
###############################################################################
#                           Authelia Configuration                            #
#                                                                             #
# Générer le "secret" en tapant :                                           #
# head /dev/random | tr -dc A-Za-z0-9 | head -c64                             #
###############################################################################

theme: dark
##
## Identity Validation Configuration
##
## This configuration tunes the identity validation flows.
identity_validation:
  ## Reset Password flow. Adjusts how the reset password flow operates.
  reset_password:
    jwt_secret: "xkxxxxxxxxxxxxxxxxxxxxx"

server:
  #host: 127.0.0.1
  #port: 9091
  #path: ""
  address: 'tcp://127.0.0.1:9091/'
  disable_healthcheck: false
  tls:
    key: ""
    certificate: ""
  ## Server Endpoints configuration.
  ## This section is considered advanced and it SHOULD NOT be configured unless you've read the relevant documentation.
  endpoints:
    ## Enables the pprof endpoint.
    enable_pprof: false
    ## Enables the expvars endpoint.
    enable_expvars: false

log:
  level: warn
  file_path: '/etc/authelia/authelia.log'

totp:
  issuer: rnmkcy.eu
  period: 30
  skew: 1
  allowed_digits:
    - 6

##
## WebAuthn Configuration
##
webauthn:
  disable: false
  enable_passkey_login: false
  display_name: 'Authelia'
  attestation_conveyance_preference: 'indirect'
  timeout: '60 seconds'
  filtering:
    permitted_aaguids: []
    prohibited_aaguids: []
    prohibit_backup_eligibility: false
  selection_criteria:
    attachment: ''
    discoverability: 'preferred'
    user_verification: 'preferred'
  metadata:
    enabled: false
    validate_trust_anchor: true
    validate_entry: true
    validate_entry_permit_zero_aaguid: false
    validate_status: true
    validate_status_permitted: []
    validate_status_prohibited:
      - 'REVOKED'
      - 'USER_KEY_PHYSICAL_COMPROMISE'
      - 'USER_KEY_REMOTE_COMPROMISE'
      - 'USER_VERIFICATION_BYPASS'
      - 'ATTESTATION_KEY_COMPROMISE'

# Authentification LLDAP
authentication_backend:
  password_reset:
    disable: false
  refresh_interval: 1m
  ldap:
    implementation: lldap
    address: ldap://127.0.0.1:3890
    timeout: 5s
    start_tls: false
    base_dn: dc=rnmkcy,dc=eu
    additional_users_dn: ou=people
    users_filter: "(&({username_attribute}={input})(objectClass=person))"
    additional_groups_dn: ou=groups
    groups_filter: "(member={dn})"
    user: uid=admin,ou=people,dc=rnmkcy,dc=eu
    password: 'mot_passe_admin_lldap'
    attributes:
      mail: 'mail'
      username: 'uid'
      group_name: 'cn'
      display_name: 'displayName'

access_control:
  default_policy: deny
  # On définit notre réseau interne si besoin
  networks:
  - name: internal
    networks:
      - '192.168.0.0/24'
      - '192.168.10.0/24'
  # On définit les règles
  rules:
    ## bypass rule
    - domain:
        - "auth.rnmkcy.eu"
      policy: bypass
    ## catch-all
    - domain:
        - "site.rnmkcy.eu"
      policy: one_factor

session:
  secret: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
  name: 'authelia_session'
  same_site: 'lax'
  inactivity: '45m'
  expiration: '12h'
  remember_me: '2M'
  cookies:
    - domain: 'rnmkcy.eu'
      authelia_url: 'https://auth.rnmkcy.eu'
      default_redirection_url: 'https://rnmkcy.eu'
      name: 'authelia_session'
      same_site: 'lax'
      inactivity: '45m'
      expiration: '12h'
      remember_me: '1d'
  redis:
    host: localhost
    port: 6379
    #password: ""
    database_index: 0
    maximum_active_connections: 10
    minimum_idle_connections: 0

regulation:
  max_retries: 3
  find_time: 5m
  ban_time: 5m

# Stockage sur base mariadb (mysl)
storage:
  encryption_key: "mot_passe_base_authelia"
  mysql:
    address: '127.0.0.1:3306'
    database: authelia
    username: authelia
    password: "EnclumeLopetteAtonauxCeigneJavelleRoute"

# Notification par messagerie
notifier:
  disable_startup_check: false

  smtp:
    username: "yanfi@yanfi.net"
    ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html
    password: "mot_passe_smtp"
    address: "submission://mx1.domaine.xyz:587"
    sender: "user@mail.net"
    ## Subject configuration of the emails sent. {title} is replaced by the text from the notifier.
    subject: "[Authelia] {title}"

Vérifier la configuration en mode su

sudo authelia validate-config --config /etc/authelia/configuration.yml

Vous devez obtenir le message suivant, si tout est correct
Configuration parsed and loaded successfully without errors.

Lancer, activer et vérifier

sudo systemctl enable authelia --now
sudo journalctl -u authelia 

oct. 30 18:56:33 alder systemd[1]: Started authelia.service - Authelia authentication and authorization server.

OPTION identity_providers
Pour générer la clé privé (key) de identity_providers

authelia crypto pair rsa generate
cat private.pem

Modifier le fichier de configuration

identity_providers:
  oidc:
    jwks:
      - key: |
          -----BEGIN PRIVATE KEY-----
          (clé privée pour la signature des tokens JWT. Voir ci dessous  "Pour générer la clé privé de identity_providers")
          -----END PRIVATE KEY-----

Configurer la partie HTTPS

Comme Authelia affiche une page de connexion/authentification, il doit être exécuté sur un canal de transport crypté pour éviter les attaques de l’homme du milieu (MITM).

Il ne démarrera pas tant que ce canal n’aura pas été correctement configuré.

Comme d’habitude avec HTTPS, pour démarrer une connexion TLS, vous avez besoin d’un certificat. La solution la plus simple est d’utiliser Let’s Encrypt ou ZeroSSL avec son outil certbot pour automatiser la récupération et le renouvellement des certificats. Il ne s’agit pas d’un tutoriel sur la mise en place du HTTPS, donc je liste les étapes à réaliser avec un reverse proxy NGINX, n’hésitez pas à personnaliser si vous utilisez un autre reverse proxy pour le HTTPS.

Le fichier /etc/nginx/conf.d/auth.rnmkcy.eu.conf

server {
    listen 80;
    server_name auth.rnmkcy.eu;

    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name auth.rnmkcy.eu;

    include /etc/nginx/conf.d/security.conf.inc;
    ssl_session_cache shared:SSL:2m;

    location / {
        set $upstream_authelia http://127.0.0.1:9091;
        proxy_pass $upstream_authelia;

        client_body_buffer_size 128k;

        #Timeout if the real server is dead
        proxy_next_upstream error timeout invalid_header http_500 http_502     http_503;

        # Advanced Proxy Config
        send_timeout 5m;
        proxy_read_timeout 360;
        proxy_send_timeout 360;
        proxy_connect_timeout 360;

        # Basic Proxy Config
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Uri $request_uri;
        proxy_set_header X-Forwarded-Ssl on;
        proxy_redirect  http://  $scheme://;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_cache_bypass $cookie_session;
        proxy_no_cache $cookie_session;
        proxy_buffers 64 256k;

        # If behind reverse proxy, forwards the correct IP
        set_real_ip_from 10.0.0.0/8;
        set_real_ip_from 192.168.10.0/16;
        set_real_ip_from 192.168.0.0/16;
        set_real_ip_from fc00::/7;
        real_ip_header X-Forwarded-For;
        real_ip_recursive on;
    }

}

Recharger nginx

sudo systemctl reload nginx

Dirigez votre navigateur vers https://auth.rnmkcy.eu et vous devriez voir apparaître la page de connexion de Authelia.

Préparer votre application pour le SSO

Authelia affiche une page de connexion/authentification, il doit être exécuté sur un canal de transport https

L’application doit être adaptée pour traiter avec un serveur d’authentification externe.
Lorsque Authelia a validé l’utilisateur, il redirige vers votre application.
Cette redirection contient des en-têtes spécifiques que votre application doit traiter pour procéder à sa création de session habituelle (typiquement, votre application émettra son Set-Cookie ou une requête de stockage local ou un jeton JWT ou …).
Il s’agit simplement de contourner la page de connexion.

Création dossier snippets

sudo mkdir -p /etc/nginx/snippets

Les fichiers de configuration nginx

Le premier extrait est une route interne /authelia qui n’est pas accessible depuis l’internet, qui est utilisée dans vos applications pour affirmer que la session Authelia est valide.

/etc/nginx/snippets/authelia.conf

# Virtual endpoint created by nginx to forward auth requests.
location /authelia {
    internal;
    set $upstream_authelia http://127.0.0.1:9091/api/verify;
    proxy_pass_request_body off;
    proxy_pass $upstream_authelia;    
    proxy_set_header Content-Length "";

    # Timeout if the real server is dead
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

    # [REQUIRED] Needed by Authelia to check authorizations of the resource.
    # Provide either X-Original-URL and X-Forwarded-Proto or
    # X-Forwarded-Proto, X-Forwarded-Host and X-Forwarded-Uri or both.
    # Those headers will be used by Authelia to deduce the target url of the     user.
    # Basic Proxy Config
    client_body_buffer_size 128k;
    proxy_set_header Host $host;
    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr; 
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-Uri $request_uri;
    proxy_set_header X-Forwarded-Ssl on;
    proxy_redirect  http://  $scheme://;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_cache_bypass $cookie_session;
    proxy_no_cache $cookie_session;
    proxy_buffers 4 32k;

    # Advanced Proxy Config
    send_timeout 5m;
    proxy_read_timeout 240;
    proxy_send_timeout 240;
    proxy_connect_timeout 240;
}

Vous aurez aussi besoin d’un snippet pour l’authentification (interne) elle-même, donc sauvegardez ce snippet sous /etc/nginx/snippets/auth.conf:
Typiquement, ce snippets fait en sorte que NGINX génère une requête vers l’emplacement interne /authelia à chaque fois qu’une requête d’utilisateur est faite vers votre application. Il vérifie le code de résultat HTTP de la requête interne. Si c’est 200, la requête de l’utilisateur est acceptée, sinon il est redirigé vers la page de login Authelia.

/etc/nginx/snippets/auth.conf

# Basic Authelia Config
# Send a subsequent request to Authelia to verify if the user is authenticated
# and has the right permissions to access the resource.
auth_request /authelia;
# Set the `target_url` variable based on the request. It will be used to build the portal
# URL with the correct redirection parameter.
auth_request_set $target_url $scheme://$http_host$request_uri;
# Set the X-Forwarded-User and X-Forwarded-Groups with the headers
# returned by Authelia for the backends which can consume them.
# This is not safe, as the backend must make sure that they come from the
# proxy. In the future, it's gonna be safe to just use OAuth.
auth_request_set $user $upstream_http_remote_user;
auth_request_set $groups $upstream_http_remote_groups;
auth_request_set $name $upstream_http_remote_name;
auth_request_set $email $upstream_http_remote_email;
proxy_set_header Remote-User $user;
proxy_set_header Remote-Groups $groups;
proxy_set_header Remote-Name $name;
proxy_set_header Remote-Email $email;
# If Authelia returns 401, then nginx redirects the user to the login portal.
# If it returns 200, then the request pass through to the backend.
# For other type of errors, nginx will handle them as usual.
error_page 401 =302 https://auth.rnmkcy.eu/?rd=$target_url;

Exemple de protection

• Un exemple de SSO avec Authelia et Owntone
• Security key

Enfin, dans la description de votre site d’application, vous devrez inclure ces extraits. Le fichier authelia.conf va dans le bloc serveur et le fichier auth.conf va dans n’importe quel endroit que vous voulez protéger.
Vous éviterez typiquement de protéger les actifs statiques et les redirections, puisqu’il n’y a pas d’intérêt à vérifier l’authentification pour ceux-ci.

Application site, fichier

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name site.rnmkcy.eu;

    include /etc/nginx/conf.d/security.conf.inc;
    include snippets/authelia.conf; # Authelia auth endpoint

    root /sharenfs/rnmkcy/site/;

    location / {
      index index.html index.php /_h5ai/public/index.php;
		  location ~ \.php(?:$|/) {
		    include fastcgi_params;
		    fastcgi_param SCRIPT_FILENAME $request_filename;
		    fastcgi_split_path_info ^(.+\.php)(/.+)$;
		    fastcgi_param HTTPS on;
		
		    fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
		    fastcgi_param front_controller_active true;     # Enable pretty urls
		    fastcgi_param HTTP_ACCEPT_ENCODING "";          # Disable encoding of nextcloud response to in>
		    fastcgi_pass unix:/var/run/php/php8.4-fpm.sock;
		    fastcgi_intercept_errors on;
		    fastcgi_request_buffering off;
		  }
          include snippets/auth.conf; # Protect this endpoint
	}
}

Double Authentification

Totp

On va ajouter une authentification TOTP
Se connecter sur authelia et cliquer sur authelia

Mot de passe usage unique

Sur la boîte de réception

Saisir le code ID

Suivre la procédure

Si vous n”avez pas google authenticator
Prendre une photo avec l’appareil android pour décoder

Cliquer sur le lien pour copier le code

Copier le contenu de secret dans le totp de cockpit keepassxc

Cliquer sur suivant et décocher qrcode

Vérification fonctionnement avec un code généré par cockpi keepassxc

Si tout est OK

et un message de confirmation

Yubikeys

Configuration authelia prérequise

## WebAuthn Actif
##
webauthn:
  ## Désactiver Webauthn avec true.
  disable: false

# l'application web utilisant la double authentification
access_control:
  default_policy: deny
  rules:
    - domain:
        - "cockpit.rnmkcy.eu"
      policy: two_factor

Clé yubikey insérée dans un port USB

Se connecter sur le lien https://auth.rnmkcy.eu avec Firefox
Saisir utilisateur “yann” et son mot de passe

Choisir la méthode

Un message est envoyé

Sur la boîte de réception

Saisir le code ID

Une nouvelle fenêtre s’ouvre

La clé est enregistrée

et un message de confirmation

Se connecter de nouveau à cockpit

Page de connexion auhelia

Validation par clé

Page authentification cockpit

Ajouter une autre clé yubikey
La seconde clé est enregistrée

et un message de confirmation

Authelia Nextcloud OpenID

Versions testées

Authelia v4.38.0
Nextcloud 22.1.0

Notes communes

1. Le paramètre OpenID Connect 1.0 client_id :
   1. Cela doit être une valeur unique pour chaque client.
      • La valeur utilisée dans ce guide est uniquement à des fins de lisibilité et de démonstration et vous ne devez pas utiliser cette valeur. Nous recommandons 64 caractères aléatoires, mais vous pouvez utiliser n’importe quelle valeur arbitraire répondant aux autres critères.
      • Celui-ci ne doit contenir que des caractères non réservés RFC3986 (RFC3986 Unreserved Characters) .
      • Celui-ci ne doit pas comporter plus de 100 caractères. * Le paramètre OpenID Connect 1.0 client_secret :
   2. La valeur utilisée dans ce guide est uniquement à des fins de démonstration et vous ne devez absolument pas l’utiliser en production et devez plutôt utiliser la FAQ Comment générer des secrets client (How Do I Generate Client Secrets) .
      • Cette chaîne peut être stockée sous forme de texte brut dans la configuration Authelia, mais ce comportement est obsolète et il n’est pas garanti qu’il soit pris en charge à l’avenir. Consultez le guide Texte brut (Plaintext) pour plus d’informations.
      • Lorsque le secret est stocké sous forme hachée dans la configuration authelia ( fortement recommandé ), le coût du hachage peut, s’il est trop élevé, entraîner des timeouts pour les clients. Consultez le guide Réglage des facteurs de travail pour plus d’informations ()Tuning the work factors.
      • L’exemple de configuration pour Authelia ne représente qu’une partie de la configuration requise et il doit être utilisé comme guide en conjonction avec les guides OpenID Connect 1.0 Provider Configuration et OpenID Connect 1.0 Clients Configuration

Hypothèses

Cet exemple fait les hypothèses suivantes :

• URL racine de l’application : https://cloud.rnmkcy.eu/
• URL racine d’Authelia : https://auth.rnmkcy.eu/
• Identité du client: nextcloud
• Secret client : insecure_secret

Remarque importante : il a été signalé que certains plugins Nextcloud n’encodent pas correctement le secret client. en tant que tel, il est important de n’utiliser que des caractères alphanumériques ainsi que les autres caractères non réservés de la RFC3986 . Nous vous recommandons d’utiliser les instructions de génération de secrets client ci-dessus.

Générer jwks

Pour utiliser OpenID (oidc),Authelia demande l’option jwks

Pour générer ou acquérir les valeurs nécessaires à la section jwks pour OpenID Connect (OIDC) dans Authelia, vous devez créer un ensemble de clés Web JSON (JWKs). Voici les étapes pour générer ces clés

1 - Générer une clé privée : Vous pouvez utiliser un outil comme OpenSSL pour générer une clé privée RSA.

openssl genrsa -out private.key 2048

2 - Créer le JWK : convertir la clé privée RSA au format JWK. Vous pouvez utiliser un outil comme node-jose-tools ou un convertisseur en ligne.
node-jose-tools for JOSE key management, token signing and encryption : Installation : npm install -g node-jose-tools

Si vous utilisez node-jose-tools

jose newkey -s 256 -t oct -a HS256

{
"kty":"oct",
"kid":"ORYf0WHq5XAcpwHFQ-OQ4Oo265REyyc7p6EsWRB7D6s",
"alg":"HS256",
"k":"zqsIYRYQ5Zn1kIRSWTqTkG-t2B7xvke7t9pbdFQr4dA"
}

En ligne : https://russelldavies.github.io/jwk-creator/

3 - Extraire la clé publique de la clé privée à l’aide d’OpenSSL :

openssl rsa -in private.key -pubout -out public.key

Configuration Authelia

La configuration YAML suivante est un exemple de configuration de client Authelia à utiliser avec Nextcloud qui fonctionnera avec l’exemple ci-dessus :

identity_providers:
  oidc:
    ## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
    ## See: https://www.authelia.com/c/oidc
    clients:
      - client_id: 'nextcloud'
        client_name: 'NextCloud'
        client_secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng'  # The digest of 'insecure_secret'.
        public: false
        authorization_policy: 'two_factor'
        redirect_uris:
          - 'https://cloud.rnmkcy.eu/apps/oidc_login/oidc'
        scopes:
          - 'openid'
          - 'profile'
          - 'email'
          - 'groups'
        userinfo_signed_response_alg: 'none'

Application

Pour configurer Nextcloud pour utiliser Authelia en tant que fournisseur OpenID Connect 1.0 :

1. Installez l’ application OpenID Connect Login (Nextcloud OpenID Connect Login app)
   • Ajoutez les éléments suivants à la configuration Nextcloud config.php :

$CONFIG = array (
    'allow_user_to_change_display_name' => false,
    'lost_password_link' => 'disabled',
    'oidc_login_provider_url' => 'https://auth.rnmkcy.eu',
    'oidc_login_client_id' => 'nextcloud',
    'oidc_login_client_secret' => 'insecure_secret',
    'oidc_login_auto_redirect' => false,
    'oidc_login_end_session_redirect' => false,
    'oidc_login_button_text' => 'Log in with Authelia',
    'oidc_login_hide_password_form' => false,
    'oidc_login_use_id_token' => true,
    'oidc_login_attributes' => array (
        'id' => 'preferred_username',
        'name' => 'name',
        'mail' => 'email',
        'groups' => 'groups',
    ),
    'oidc_login_default_group' => 'oidc',
    'oidc_login_use_external_storage' => false,
    'oidc_login_scope' => 'openid profile email groups',
    'oidc_login_proxy_ldap' => false,
    'oidc_login_disable_registration' => true,
    'oidc_login_redir_fallback' => false,
    'oidc_login_alt_login_page' => 'assets/login.php',
    'oidc_login_tls_verify' => true,
    'oidc_create_groups' => false,
    'oidc_login_webdav_enabled' => false,
    'oidc_login_password_authentication' => false,
    'oidc_login_public_key_caching_time' => 86400,
    'oidc_login_min_time_between_jwks_requests' => 10,
    'oidc_login_well_known_caching_time' => 86400,
    'oidc_login_update_avatar' => false,
);

Voir également

• Nextcloud OpenID Connect Login app
• Nextcloud OpenID Connect Login Documentation

Générer identifiant ou secret

Authelia fournit un moyen simple d’effectuer de telles actions.

ID client

Les utilisateurs peuvent facilement générer un identifiant/identifiant client en suivant le guide Génération d’une chaîne alphanumérique aléatoire
Par exemple, les utilisateurs peuvent exécuter la commande

authelia crypto rand --length 72 --charset rfc3986

pour générer un identifiant/identifiant client de 72 caractères qui est imprimé.
Cette commande aléatoire évite également les problèmes avec une application client/partie de confiance codant correctement les caractères car elle utilise les caractères non réservés RFC3986 .

Si un jeu de caractères différent est utilisé et que la valeur est différente lors du codage de l’URL, il imprimera également cette valeur séparément.

secret client

Les utilisateurs peuvent facilement générer un secret client en suivant le guide Génération d’un hachage de mot de passe aléatoire
Par exemple, les utilisateurs peuvent exécuter la commande

authelia crypto hash generate pbkdf2 --variant sha512 --random --random.length 72 --random.charset rfc3986

pour à la fois générer un secret client de 72 caractères qui est imprimé et doit être utilisé avec la partie utilisatrice et le hacher à l’aide de PBKDF2 qui peut être stocké dans la configuration Authelia. Cette commande aléatoire évite également les problèmes avec une application client/partie de confiance codant correctement les caractères car elle utilise les caractères non réservés RFC3986 .

Si un jeu de caractères différent est utilisé et que la valeur est différente lors du codage de l’URL, il imprimera également cette valeur séparément.

Réglage des facteurs de travail

Lors du hachage des secrets du client, Authelia effectue l’opération de hachage pour authentifier le client lors de la réception des demandes. Cette opération de hachage prend du temps, de par sa conception (la partie travail du facteur travail) pour empêcher un attaquant de tenter d’obtenir le secret client. Le temps nécessaire dépend de votre matériel et du facteur de travail.

Si les opérations de votre client expirent, vous devrez peut-être réduire le facteur de travail à un niveau approprié pour votre client et les capacités de votre matériel.

Pour tester la durée de différents facteurs de travail, vous pouvez la mesurer ainsi :

time authelia crypto hash generate pbkdf2 --variant sha512 --iterations 310000 --password insecure_password 

Remarque : Vous ne devez pas utiliser vos mots de passe réels pour ce test. Le temps nécessaire doit être le même pour toute longueur de mot de passe raisonnable.

Vous pouvez en savoir plus sur le réglage du hachage de mot de passe dans le guide de référence des mots de passe .