IBM Security Verify Access Intégration

Verify Access SSO pour JBoss/Wildfly

IBM Security 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. Le composant proxy inverse web est utilisé pour fournir et faire appliquer l'accès aux serveurs en aval jonctionnés par WebSEAL. Les informations d'identité fournies par Verify Access sont ensuite consommé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 implémentées en utilisant le composant Advanced Access Control de Verify Access.

Connaissances supposées

Cette intégration suppose que vous êtes familier avec un certain nombre d'options de configuration d'IBM Security Verify Access. Au minimum, vous devriez être capable de :

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

Prérequis

Ce guide suppose que vous avez Verify Access (matériel, machine virtuelle ou conteneurs) déployé et le serveur d'exécution et le registre d'utilisateurs configurés. Une configuration supplémentaire peut être requise 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 devriez également avoir un serveur JBoss ou Wildfly déployé et configuré pour utiliser la fonctionnalité token-realm de JSON Web Token (JWT) du sous-système de sécurité Elytron. Les instructions pour configurer JBoss sont détaillées dans ce guide. L'identité est fournie via un JWT construit à partir des attributs utilisateur disponibles. Ce guide suppose que vous êtes familier avec l'ICP associée nécessaire pour vérifier et (si requis) déchiffrer les JWT.

Configurer la vérification SSL

Dans la mesure du possible, il est recommandé de sécuriser la jonction WebSEAL vers le serveur JBoss en aval en utilisant SSL. Par défaut, les instances WebSEAL utilisent la base de données de certificats SSL pdsrv. Pour activer la communication SSL, un certificat qui fait partie de la chaîne de confiance X509 de la poignée de main SSL JBoss doit être importé dans la base de données de certificats SSL utilisée par votre instance WebSEAL.

Pour activer 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 JBoss. Le type de magasin de clés par défaut dans JBoss/Wildfly est défini sur JKS cependant ce guide utilise PKCS12. Les éléments par défaut du magasin de clés SSL standalone.xml devraient être mis à jour avec ce qui suit :

        <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>

Configuration du proxy inverse WebSEAL

Une instance WebSEAL est utilisée pour fournir et faire appliquer les 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 revendications configurées pour le sous-système Elytron.

Créer la jonction WebSEAL vers JBoss / Wildfly

Créez une jonction mutuelle vers le serveur JBoss ou Wildfly. Ce guide utilise une jonction standard, cependant une jonction transparente peut être utilisée si le serveur en aval doit être capable de rediriger en utilisant des chemins relatifs. La jonction devrait être configurée pour utiliser une connexion SSL sans autre configuration supplémentaire requise.

Ceci peut également être fait en utilisant 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 Security 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 fournir un JWT

Pour configurer WebSEAL pour fournir un JWT, une strophe [jwt:<nom de jonction>] est ajoutée au fichier de configuration WebSEAL. Cette strophe contient le mappage d'attributs à utiliser ainsi que toute configuration cryptographique requise. L'intégration de démonstration utilise le certificat auto-signé créé dans le magasin de clés pdsrv (magasin de clés par défaut WebSEAL) pour signer les JWT. Dans un environnement de production, ceci devrait être remplacé par une ICP 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 que ceci soit changé.

[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

Optionnel : Configurer un contrôle d'accès supplémentaire des ressources web

Toutes listes de contrôle d'accès (ACL) et politiques d'objets protégés (POP) supplémentaires requises pour la ressource jonctionnée devraient également être créées ici. Les ACL et POP sont utilisées pour définir la logique métier supplémentaire requise pour faire appliquer des exigences de sécurité supplémentaires pour accéder aux ressources web. L'authentification par étapes prête à l'emploi, fournie par le module Advanced Access Control, est un exemple simple à utiliser de l'authentification supplémentaire qui peut être implémentée en utilisant IBM Security Verify Access.