Guide d'intégration SSO IBM Websphere Liberty/OpenLiberty

Ce guide d'intégration peut être utilisé pour configurer un serveur IBM Websphere Liberty ou OpenLiberty afin d'utiliser l'authentification SSO fournie par les solutions IAM IBM sur site ou dans le cloud en utilisant un jeton d'identité basé sur des normes. Cette intégration est capable de s'intégrer avec un certain nombre de sources d'identité traditionnelles (LDAP/Active Directory) et distribuées (Fédération/Cloud Directory) ; ainsi que d'appliquer des politiques de contrôle d'accès personnalisables.

L'identité est fournie à un serveur Liberty en aval en utilisant la fonctionnalité Liberty mpJwt. Cette fonctionnalité est capable d'utiliser un JSON Web Token (JWT) fourni dans la requête entrante pour :

• Établir la confiance avec le service d'authentification en amont.
• Extraire les informations d'identité de la requête entrante.
  • Vérifier les informations d'identité signées cryptographiquement par l'instance WebSEAL
  • Analyser les revendications d'identité
• Construire l'objet Principal disponible dans la HttpServletRequest

Une démonstration de cette intégration est disponible sur IBM Security Integrations en utilisant les derniers conteneurs Websphere-Liberty et IBM Application Gateway. Le déploiement de ce scénario est documenté dans le guide d'intégration verify

Connaissances supposées

Ce guide d'intégration nécessite qu'un utilisateur ait une connaissance pratique de la configuration d'IBM Websphere Liberty. En général, un utilisateur devrait être familier avec les technologies suivantes :

• Déploiement d'applications sur un serveur liberty
• Création et modification des magasins de confiance PCKS12
• (Verify Access uniquement) Configuration des proxies inverses Verify Access et des jonctions associées
  • Créer une jonction WebSEAL
  • Modifier le fichier de configuration WebSEAL pour la stanza spécifique à la jonction
  • Importer le certificat X509 dans la base de données de certificats WebSEAL
• (Verify SaaS uniquement) Création et gestion des locataires IBM Security Verify
  • Créer une nouvelle application/client API
  • Créer/Gérer un registre Cloud ou une source d'identité fédérée

Prérequis

Pour utiliser ce guide d'intégration, il y a un certain nombre de prérequis :

• Une application java (ear/war)
  • La configuration d'application spécifique à Liberty est détaillée ici
• Une source d'identité ; elle peut être soit sur site (Verify Access) soit dans le cloud (Verify SaaS)
• Infrastructure de clé publique pour signer et vérifier les informations d'identité
  • Lors des tests, les certificats peuvent être auto-signés mais doivent être gérés dans les environnements de production

Produits pris en charge

Ce guide d'intégration est destiné à être utilisé avec

• > IBM Websphere Liberty 7.0
  • > OpenLiberty 18.0.0.0
• > IBM Security Access Manager 10.0.0.0

Présentation de l'architecture

Ce guide détaille deux voies d'intégration, l'une pour les solutions sur site et l'autre pour les solutions basées sur le cloud. Une intégration de démonstration utilisant IBM Application Gateway et Websphere Liberty est documentée ici et illustrée dans la figure ci-dessus. Les deux architectures utilisent un modèle de déploiement très similaire où un proxy inverse identifie les utilisateurs avant de prendre une décision d'autoriser l'accès aux ressources du serveur web. Dans un déploiement basé sur le cloud, le proxy inverse est IBM Application Gateway, et l'identité est vérifiée par IBM Security Verify SaaS ; pour les déploiements sur site, IBM Security Verify Access utilise l'architecture de machine virtuelle héritée pour déployer WebSEAL avec un registre d'utilisateurs basé sur LDAP ou s'intégrer avec une source d'identité fédérée.

Le diagramme de séquence décrit l'interaction du navigateur pour un utilisateur tentant d'accéder à une ressource protégée. Lorsqu'un utilisateur fait une demande à une ressource protégée, le proxy inverse intercepte la demande et redirige l'utilisateur pour s'authentifier. Pour les déploiements basés sur le cloud, ceci est démontré en utilisant IBM Security Verify SaaS comme fournisseur d'identité OIDC ; pour les déploiements sur site, IBM Security Verify Access peut s'authentifier contre un registre d'utilisateurs local (LDAP ou Active Directory) ou rediriger vers un partenaire d'identité fédéré. Une fois que l'utilisateur s'est authentifié, il est retourné au proxy inverse où un jeton d'identité est propagé à l'application web protégée où il peut être validé en utilisant la cryptographie à clé publique.

Configuration du serveur Liberty

La fonctionnalité mpJwt peut être configurée pour fournir des informations d'identité via un JWT signé (et/ou chiffré). Le serveur de jonction peut également être configuré pour valider les connexions en utilisant SSL. Les sections suivantes détaillent la configuration Liberty requise pour : activer la fonctionnalité mpJwt ; configurer une application Java pour consommer les informations d'identité JWT ; et durcir la sécurité du serveur Liberty à protéger.

Propriétés de configuration disponibles

La documentation mpJwt liste les propriétés de configuration disponibles. Au minimum, vous devrez définir les options suivantes :\

• issuer : nom de domaine du proxy inverse fournissant l'identité.
• audiences : nom de domaine du serveur d'application Liberty consommant l'identité.
• keyName : identifie la clé publique dans le keystore SSL qui est utilisée pour vérifier les jetons de signature.

Configuration SSL

Lorsque cela est possible, il est recommandé de sécuriser la communication vers le proxy inverse en amont en utilisant la communication SSL. Pour activer l'authentification client dans Liberty, la configuration SSL peut être ajoutée à la configuration du serveur en ajoutant une entrée SSL et en référençant l'id de l'entrée dans la configuration httpEndpoint->sslOptions. La configuration de démonstration utilise l'id de configuration SSL par défaut et n'a pas besoin d'être référencée dans l'entrée httpEndpoint.

La documentation OpenLiberty décrit la configuration SSL supplémentaire et la configuration de point de terminaison HTTP. Ceci est utilisé pour valider les connexions au serveur Liberty et protège contre l'accès non autorisé depuis le réseau protégé. Pour configurer la vérification mutuelle entre le proxy inverse utilisé et Liberty, un certificat X509 qui fait partie de la chaîne de confiance du proxy inverse doit être importé dans le keystore Liberty. Les commandes suivantes peuvent être utilisées pour importer un certificat X509 :

keytool -importcert \
     -file <certificate to trust> \
     -alias <alias for the certificate> \
     -keystore <name of the truststore> \
     -storepass <password for the truststore> \
     -storetype <type of the keystore>

Ce keystore est ensuite ajouté au serveur Liberty. Pour ce guide (et le serveur de démonstration), le keystore par défaut est utilisé (situé à ${server.output.dir}/resources/security/key.p12) qui est référencé par l'id par défaut defaultKeyStore. Si vous utilisez un keystore personnalisé, alors une configuration supplémentaire de la configuration SSL du point de terminaison HTTP peut être requise.

Exemple :

<keyStore id="defaultKeyStore"
          location="DemoKeyStoreFile.p12"
          type="PKCS12"
          password="demokeystore"
          pollingRate="5s"
          updateTrigger="polled"/>

<ssl id="defaultSSLConfig"
      keyStoreRef="defaultKeyStore"
      clientAuthentication="true"/>

Configuration de l'application Java

L'application de démonstration utilise un fichier web.xml dans le répertoire WEB-INF d'une application web pour définir les contraintes d'authentification. L'extrait de code ci-dessous montre cette définition aux côtés de la configuration du serveur correspondante pour mapper les groupes JWT aux rôles Java.

web.xml dans le bundle d'application Java :

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.5">
  <display-name>DemoApplication</display-name>
    <distributable />

    <servlet-mapping>
        <servlet-name>whoami</servlet-name>
        <url-pattern>/whoami.jsp</url-pattern>
    </servlet-mapping>

    <security-constraint>
        <display-name>
        AnyAuthenticated</display-name>
        <web-resource-collection>
            <web-resource-name>
                AnyAuthenticatedResources
            </web-resource-name>
            <url-pattern>/whoami.jsp</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <role-name>secusers</role-name>
        </auth-constraint>
    </security-constraint>
</web-app>

configuration d'application server.xml correspondante :

    <application type="war"
                 name="DemoApplication"
                 id="DemoApplication"
                 location="${server.config.dir}/apps/DemoApplication.war">
        <application-bnd>
            <security-role name="secusers">
                <group name="secusers"
                       access-id="group:www.ibm.com/SecUsers"/>
            </security-role>
        </application-bnd>
    </application>

📘

Mappage des groupes aux rôles

Notez que le nom du groupe doit être préfixé par la revendication iss du JWT. C'est ainsi que Liberty mappe les groupes définis en externe aux "Domaines de sécurité"

Configuration basée sur l'application de gestion

La fonctionnalité liberty adminCenter-1.0 peut être activée pour permettre la configuration d'un serveur Websphere Liberty en utilisant une application interactive depuis un navigateur web.

Configuration basée sur fichier

Pour configurer le server.xml de votre application liberty directement, ouvrez le fichier server.xml dans un éditeur de texte
et ajoutez les éléments XML suivants à votre définition de serveur :

• featureManager :
  La fonctionnalité appSecurity doit être activée pour activer les sous-systèmes requis pour traiter le filtre d'authentification (qui invoque l'authentification JWT). La fonctionnalité mpJwt est utilisée pour valider et analyser le JWT fourni et générer un Principal qui est disponible pour les servlets suivants. Enfin, la fonctionnalité ssl doit également être activée pour permettre la communication SSL.

Exemple :

<featureManager>
    <feature>appSecurity-3.0</feature>
    <feature>ssl-1.0</feature>
    <feature>mpJwt-1.2</feature>
</featureManager>

• authFilter :
  Le filtre d'authentification est utilisé pour identifier les requêtes entrantes qui doivent être authentifiées en utilisant l'élément mpJwt configuré. L'exemple de configuration est déclenché pour toute requête qui contient l'en-tête Authorization, cependant cela pourrait être modifié pour cibler une webapp spécifique ou une URL de requête.

Exemple : requêtes qui contiennent un en-tête d'autorisation.

<authFilter id="myAuthFilter">
    <requestHeader id="authRequest" matchType="equals" name="Authorization"/>
</authFilter>

Exemple : toutes les requêtes vers un serveur

<authFilter id="myAuthFilter">
    <requestUrl id="authRequest" matchType="contains" name="/"/>
</authFilter>

• mpJWT :
  Pour configurer la fonctionnalité mpJwt, définissez un nom unique, les attributs d'identité (ceux-ci peuvent être omis si vous utilisez les valeurs par défaut de liberty), l'alias de clé publique et le filtre d'authentification utilisé pour identifier les requêtes qui doivent contenir des informations d'identité fournies par IBM Security Verify ou IBM Security Verify Access.

Exemple :

<mpJwt
    id="myMpJwt"
    userNameAttribute="sub"
    groupNameAttribute="groups"
    issuer="www.ibm.com"
    audiences="demo.integration.server"
    authFilterRef="myAuthFilter"
    keyName="isvajwt">
</mpJwt>

Intégration Verify

Le guide Intégration Verify peut être utilisé pour configurer IAG afin de fournir des informations d'identité à Liberty. Ce guide documente également une application Java de démonstration simple présentant les capacités SSO offertes par l'intégration de Liberty avec IBM Security Verify.

Une intégration de démonstration utilisant IBM Application Gateway et WebSphere Liberty est documentée ici avec des fichiers sources disponibles sur le référentiel IBM Security Integrations

Intégration Verify Access

Le guide Intégration Verify Access peut être utilisé pour configurer Verify Access afin de fournir des informations d'identité à Liberty. Ce guide documente également une application Java de démonstration simple présentant les capacités SSO offertes par l'intégration de Liberty avec IBM Security Verify Access

Dépannage

Si vous rencontrez des problèmes ou avez une exigence de déploiement spécifique non couverte par ce guide, vous pouvez créer un problème sur le GitHub ibm-security-integration. À partir de là, les développeurs IBM et les membres de la communauté peuvent contribuer et collaborer pour trouver une solution.