IBM Websphere Liberty SSO

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 nuage à l'aide d'un jeton d'identité basé sur des normes. Cette intégration est capable d'intégrer un certain nombre de sources d'identité traditionnelles (LDAP/Active Active Directory ) et distribuées (Federation/Cloud Directory), ainsi que d'appliquer des politiques de contrôle d'accès personnalisables.

L'identité est fournie à un serveur Liberty en aval à l'aide de la fonctionnalité mpJwt Liberty. Cette fonction permet d'utiliser un jeton Web JSON (JWT) fourni dans la demande entrante pour :

  • Établir la confiance avec le service d'authentification en amont.
  • Extraction d'informations sur l'identité à partir de la demande entrante.
    • Vérifier les informations d'identité signées cryptographiquement par l'instance WebSEAL
    • Analyse des déclarations d'identité
  • Construction de l'objet Principal disponible dans la HttpServletRequest

Une démonstration de cette intégration est disponible sur le site 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 de la vérification

Connaissances supposées

Ce guide d'intégration exige que l'utilisateur ait une connaissance pratique de la configuration d' IBM Websphere Liberty. En règle générale, un utilisateur doit être familiarisé avec les technologies suivantes :

  • Déploiement d'applications sur un serveur liberty
  • Création et modification des bases de données fiduciaires de PCKS12
  • (Verify Access uniquement) Configuration des serveurs mandataires inversés de Verify Access et des jonctions associées
    • Créer une jonction WebSEAL
    • Modifier le fichier de configuration de WebSEAL pour la strophe spécifique à la jonction
    • Importer un certificat X509 dans la base de données des certificats WebSEAL
  • (Vérifier SaaS uniquement) Création et gestion des locataires IBM Verify
    • Créer un nouveau client Application/API
    • Créer/gérer un registre en nuage ou une source d'identité fédérée

Prérequis

L'utilisation de ce guide d'intégration nécessite un certain nombre de conditions préalables :

  • Une application Java (ear/war)
    • La configuration de l'application Liberty est détaillée ici
  • Une source d'identité ; elle peut être sur place (Verify Access) ou dans le nuage (Verify SaaS )
  • Infrastructure à 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

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

Présentation de l'architecture

1123

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 dans lequel un proxy inverse identifie les utilisateurs avant de prendre la décision d'autoriser l'accès aux ressources du serveur web. Dans un déploiement en nuage, le proxy inverse est IBM Application Gateway et l'identité est vérifiée par IBM Verify SaaS;. Pour les déploiements sur site, IBM 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 à une source d'identité fédérée.

1123

Le diagramme de séquence décrit l'interaction entre le navigateur et un utilisateur qui tente d'accéder à une ressource protégée. Lorsqu'un utilisateur demande une ressource protégée, le mandataire inverse intercepte la demande et redirige l'utilisateur pour qu'il s'authentifie. Pour les déploiements en nuage, la démonstration est faite en utilisant IBM Verify SaaS comme fournisseur d'identité OIDC; pour les déploiements sur site, IBM Verify Access peut s'authentifier auprès d'un registre d'utilisateurs local (LDAP ou Active Directory ) ou rediriger vers Federated Identity Partner. Une fois que l'utilisateur s'est authentifié, il est renvoyé au proxy inverse où un jeton d'identité est propagé à l'application web protégée où il peut être validé à l'aide de la cryptographie à clé publique.

Configuration du serveur Liberty

La fonction mpJwt peut être configurée pour fournir des informations d'identité via un JWT signé (et/ou crypté). Le serveur de jonction peut également être configuré pour valider les connexions à l'aide de 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 renforcer la sécurité du serveur Liberty protégé.

Propriétés de configuration disponibles

La documentation de mpJwt énumère les propriétés de configuration disponibles. Au minimum, vous devrez définir les options suivantes:\N- La liste des options est disponible sur le site web de la Commission

  • 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 la base de données de clés SSL qui est utilisée pour vérifier les jetons de signature.

Configuration SSL

Dans la mesure du possible, il est recommandé de sécuriser la communication avec le proxy revere en amont en utilisant la communication SSL. Pour activer l'authentification du 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'identifiant de l'entrée dans la configuration httpEndpoint->sslOptions. La configuration de démonstration utilise l'identifiant de configuration SSL par défaut et n'a pas besoin d'être référencée dans l'entrée httpEnpoint.

La documentation d' OpenLiberty décrit d'autres configurations SSL et HTTP. Il est utilisé pour valider les connexions au serveur Liberty et protège contre les accès non autorisés à partir du réseau protégé. Pour configurer la vérification mutuelle entre le proxy inverse utilisé et Liberty, un certificat X509 faisant 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é dans ${server {server.output.dir}/resources/security/key.p12 ) qui est référencé par l'identifiant par défaut defaultKeyStore. Si vous utilisez un keystore personnalisé, une configuration supplémentaire de la configuration SSL du point de terminaison HTTP peut être nécessaire.

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 ainsi que la configuration du serveur correspondant pour faire correspondre les groupes JWT aux rôles Java.

web.xml dans le paquet d'applications 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>

la configuration de l'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 vers les rôles

Notez que le nom du groupe doit être préfixé par la revendication iss du JWT. C'est ainsi que Liberty fait correspondre les groupes définis en externe aux "Security Realms"

Configuration basée sur l'application de gestion

La fonction liberty adminCenter-1.0 peut être activée pour permettre la configuration d'un serveur Websphere Liberty à l'aide d'une application interactive à partir d'un navigateur web.

Configuration basée sur des fichiers

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

  • featureManager:
    La fonction appSecurity doit être activée pour que les sous-systèmes nécessaires au traitement du filtre d'authentification (qui invoque l'authentification JWT) soient activés. La fonction 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 fonction 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 demandes entrantes qui doivent être authentifiées à l'aide de l'élément mpJwt configuré. L'exemple de configuration est déclenché pour toute requête contenant l'en-tête Authorization, mais il peut être modifié pour cibler une application web ou une URL requête spécifique.

Exemple : demandes contenant un en-tête d'autorisation.

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

Exemple : toutes les demandes adressées à un serveur

<authFilter id="myAuthFilter">
    <requestUrl id="authRequest" matchType="contains" name="/"/>
</authFilter>
  • mpJWT:
    Pour configurer la fonction mpJwt, définissez un nom unique, des attributs d'identité (ceux-ci peuvent être omis si vous utilisez les valeurs par défaut de liberty), l'alias de la clé publique et le filtre d'authentification utilisé pour identifier les demandes qui doivent contenir des informations d'identité fournies par IBM Verify ou IBM Verify Access.

Exemple :

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

Vérifier l'intégration

Le guide Verify Integration peut être utilisé pour configurer IAG afin qu'il fournisse des informations d'identité à Liberty. Ce guide présente également une application Java de démonstration simple qui illustre les possibilités de SSO offertes par l'intégration de Liberty à IBM Verify.

Une démonstration d'intégration utilisant IBM Application Gateway et WebSphere Liberty est documentée ici et les fichiers sources sont disponibles dans le référentiel IBM Security Integrations

Vérifier l'intégration de l'accès

Le guide d' intégration de Verify Access peut être utilisé pour configurer Verify Access afin qu'il fournisse des informations d'identité à Liberty. Ce guide présente également une application Java de démonstration simple qui illustre les possibilités de SSO offertes par l'intégration de Liberty avec IBM Verify Access

Traitement des incidents

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