Vérifier l'accès SSO pour JBoss/Wildfly

IBM Verify Access peut être utilisé pour intégrer des registres d'utilisateurs sur site (par exemple LDAP, Active Directory ) avec des applications fonctionnant sur des serveurs d'application JBoss ou Wildfly fonctionnant sur les serveurs d'application JBoss ou Wildfly. Le composant proxy inverse web est utilisé pour fournir et renforcer l'accès aux serveurs suivants jonction des serveurs en aval par WebSEAL. Les informations sur l'identité fournies par Verify Access sont ensuite utilisées par le sous-système Elytron
qui transmet l'identité aux applications web Java. Des politiques d'accès personnalisées ou complexes peuvent être mises en œuvre
en utilisant le composant Contrôle d'accès avancé de Verify Access.

Connaissances supposées

Cette intégration suppose que vous soyez familiarisé avec un certain nombre d'options de configuration de IBM Verify Access. Au minimum
vous devez être capable de :

Créer des instances et des jonctions WebSEAL
Modifier le fichier de configuration de WebSEAL
Gérer la base de données SSL du serveur d'exécution

Prérequis

Ce guide suppose que vous avez déployé Verify Access (matériel, machine virtuelle ou conteneurs) et que le serveur d'exécution et le registre des utilisateurs sont configurés. Une configuration supplémentaire peut être nécessaire si un registre d'utilisateurs fédéré (par exemple Active Directory ) ou une identité fédérée (par exemple OIDC ou SAML) sont utilisés.

Vous devez également disposer d'un serveur JBoss ou Wildfly déployé et configuré pour utiliser la fonction token-realm (jeton Web JWT) du sous-système de sécurité Elytron. Les instructions pour la configuration de JBoss sont détaillées dans ce guide. L'identité est fournie via un JWT construit à partir des attributs disponibles de l'utilisateur. Ce guide suppose que vous connaissez l'infrastructure de clés publiques associée nécessaire pour vérifier et (si nécessaire) décrypter les JWT.

Configurer la vérification SSL

Dans la mesure du possible, il est recommandé de sécuriser la jonction WebSEAL avec le serveur JBoss en aval à l'aide de SSL. Par défaut, les instances WebSEAL utilisent la base de données de certificats SSL pdsrv. Pour activer la communication SSL, un certificat faisant partie de la chaîne de confiance X509 de l'accord de transfert JBoss SSL doit être importé dans la base de données des certificats SSL utilisée par votre instance WebSEAL.

Pour permettre la vérification mutuelle, un certificat qui fait partie de la chaîne de confiance X509 de la poignée de main WebSEAL doit être importé dans le magasin de clés SSL de JBoss. Le type de keystore par défaut dans JBoss/Wildfly est défini sur JKS mais ce guide utilise PKCS12. Les éléments du keystore SSL par défaut standalone.xml doivent être mis à jour avec les éléments suivants :

        <subsystem xmlns="urn:wildfly:elytron:14.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
            <tls>
                <key-stores>
                    <key-store name="applicationKS">
                        <credential-reference clear-text="demokeystore"/>
                        <implementation type="PKCS12"/>
                        <file path="application.keystore" relative-to="jboss.server.config.dir"/>
                    </key-store>
                </key-stores>
            </tls>
        </subsystem>

WebSEAL Configuration du proxy inverse

Une instance WebSEAL est utilisée pour fournir et appliquer des exigences d'authentification. Au minimum, vous devrez créer/modifier une instance WebSEAL avec une jonction vers le serveur JBoss cible et ajouter la strophe de configuration JWT configurée pour correspondre aux réclamations configurées pour le sous-système Elytron.

Créer la jonction WebSEAL vers JBoss / Wildfly

Créer une jonction mutuelle avec le serveur JBoss ou Wildfly. Ce guide utilise une jonction standard, mais une jonction transparente peut être utilisée si le serveur en aval doit pouvoir rediriger en utilisant des chemins relatifs. La jonction doit être configurée pour utiliser la connexion SSL sans aucune autre configuration supplémentaire.

Cette opération peut également être effectuée à l'aide de l'outil CLI pdadmin:

[user@workstation ~]$ ssh [email protected]
Warning: Permanently added '192.168.42.101' (ED25519) to the list of known hosts.
([email protected]) Password: *****
Welcome to the IBM Verify Access appliance
Enter "help" for a list of available commands

my.isva.appliance> isam admin

pdadmin> server task <instance_name>-webseald-<host_name_or_address> create –t mutual -h target.integration.server -p 9080 -P 9443 /wildfly-sso-demo

Created junction at /wildfly-sso-demo

Configurer WebSEAL pour qu'il fournisse un JWT

Pour configurer WebSEAL afin qu'il fournisse un JWT, une strophe [jwt:<junction name>] est ajoutée au fichier de configuration de WebSEAL. Cette strophe contient le mappage des attributs à utiliser ainsi que toute configuration cryptographique requise. L'intégration de démonstration utilise le certificat auto-signé créé dans le keystore pdsrv (keystore par défaut WebSEAL ) pour signer les JWT. Dans un environnement de production, il doit être remplacé par une infrastructure à clé publique (PKI) appropriée. L'en-tête HTTP utilisé doit être de la forme Authorization: Bearer %TOKEN%, car le sous-système Elytron ne permet pas de le modifier.

[jwt:/wildlflysso]

key-label = WebSEAL-Test-Only

claim = text::www.ibm.com::iss
claim = attr::AZN_*
claim = attr::AZN_CRED_PRINCIPAL_NAME::sub

include-empty-claims = false

hdr-name = Authorization
hdr-format = Bearer %TOKEN%

lifetime = 0
renewal-window = 15

En option : Configurer un contrôle d'accès supplémentaire aux ressources web

Les listes de contrôle d'accès (ACL) et les politiques d'objets protégés (POP) supplémentaires nécessaires pour la ressource jonctionnée doivent également être créées ici. Les ACL et les POP sont utilisés pour définir une logique d'entreprise supplémentaire nécessaire pour appliquer des exigences de sécurité supplémentaires pour l'accès aux ressources web. L'authentification par étapes, fournie par le module de contrôle d'accès avancé, est un exemple simple d'utilisation de l'authentification supplémentaire qui peut être mise en œuvre à l'aide de IBM Verify Access.