Guide d'intégration SSO d' Apache Tomcat

Ce guide d'intégration peut être utilisé pour configurer un serveur Apache Tomcat afin d'utiliser l'authentification SSO fournie par les solutions IAM d' 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 Tomcat en aval à l'aide de la valve JWT disponible dans les versions du guide d'intégration. Cette vanne décode et valide un jeton Web JSON (JWT) fourni à partir de la demande entrante :

• É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.
  • Analyser les déclarations d'identité.
• Construction de l'objet Principal disponible dans la HttpServletRequest
  • La vanne est capable de définir les attributs du nom d'utilisateur et des groupes (rôles).

Une démonstration de cette intégration est disponible sur le site IBM Security Integrations utilisant les conteneurs Apache Tomcat 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' Apache Tomcat. D'une manière générale,
un utilisateur doit être familiarisé avec les technologies suivantes :

• Déploiement d'applications sur un serveur tomcat
• 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
• (Verify SaaS uniquement) Création et gestion des locataires IBM Security 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 :

• Un paquet d'applications web Java (ear/war)
  • La configuration de l'application Tomcat 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

• > Apache Tomcat 8.0
• > IBM Security Verify Access 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 démonstration d'intégration de conteneurs utilisant IBM Application Gateway et Apache Tomcat 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 le cas d'un déploiement en nuage, 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 existante pour déployer WebSEAL avec un registre d'utilisateurs basé sur LDAP ou s'intégrer à une source d'identité fédérée.

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 dans le nuage, la démonstration est faite en utilisant IBM Security Verify SaaS comme fournisseur d'identité OIDC ; pour les déploiements sur site, IBM Security 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 Tomcat

Un serveur d'application Tomcat est configuré pour utiliser la valve fournie, qui vérifie un JWT fourni et crée un objet Principal avec le nom d'utilisateur et les revendications de groupes. L'identité résultante peut alors être consommée par : soit la configuration des contraintes de sécurité web.xml ; soit l'utilisation de JACC pour mettre les informations d'identité à la disposition du code Java.

Propriétés de configuration disponibles

La valve JWT dispose d'un certain nombre d'options de configuration qui doivent être définies afin de vérifier et d'analyser le JWT fourni.

Configuration SSL

Pour mettre en place une vérification mutuelle entre le proxy inverse utilisé et Tomcat, un certificat X509 faisant partie de la chaîne de confiance du proxy inverse doit être importé dans le keystore de Tomcat. Les commandes suivantes permettent d'importer un certificat X509 dans un keystore JKS ou PKCS12:

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>

Dans Tomcat, la configuration SSL pour le trafic HTTP est définie dans l'élément Connector. Ce connecteur effectue le SNI sur le certificat X509 fourni, de sorte que le CN ou l'extension appropriée doit satisfaire à cette vérification.

    <Connector port="8443"
               maxThreads="150"
               scheme="https"
               secure="true"
               protocol="org.apache.coyote.http11.Http11NioProtocol"
               SSLEnabled="true"
               defaultSSLHostConfigName="demo-tomcat-server"
               allowTrace="true">
        <SSLHostConfig protocols="all"
                       certificateVerification="required"
                       hostName="demo-tomcat-server"
                       truststoreFile="DemoKeystore.p12"
                       truststorePassword="demokeystore"
                       truststoreType="PKCS12">
        <Certificate type="RSA"
                     certificateKeystoreFile="DemoKeystore.p12"
                     certificateKeyAlias="1"
                     certificateKeystorePassword="demokeystore"
                     certificateKeystoreType="PKCS12"/>
        </SSLHostConfig>
    </Connector>

Configuration de l'application Java

Les éléments login-confg et security-congstraints peuvent être ajoutés au fichier web.xml du répertoire WEB-INF du déploiement d'une application web Java. Cette configuration est suffisante pour imposer l'utilisation de la vanne JWT configurée pour les ressources web spécifiées.

Ce fichier de configuration peut également être utilisé pour mettre en œuvre des politiques d'accès basées sur les rôles (à l'aide d'un mappage groupe-rôle) pour les ressources web. Pour accéder à la ressource /secTestSSO.jsp, l'utilisateur doit être membre du groupe "développeur". Le nom du groupe est préfixé par l'attribut/la revendication JWT "issuer" afin d'éviter les collisions entre les sources d'identité ayant le même nom de groupe. Tous les rôles Java requis doivent être définis dans ce fichier.

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>secTestSSO</web-resource-name>
            <url-pattern>/secTestSSO.jsp</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>www.ibm.com/developer</role-name>
        </auth-constraint>
    </security-constraint>

    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>defaultRealm</realm-name>
    </login-config>

    <security-role>
        <role-name>www.ibm.com/developer</role-name>
    </security-role>

Configuration basée sur des fichiers

Le stub de configuration du serveur fourni montre comment JwtValve peut être activé et configuré pour un serveur d'application Tomcat. La configuration de ce composant repose sur l'infrastructure de clés publiques créée aux étapes précédentes ainsi que sur la configuration de l'émetteur et de l'audience définie dans le proxy inverse qui fournit le JWT (IAG ou WebSEAL ):

<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN">
  <Service name="Catalina">
    <Engine name="Catalina" defaultHost="localhost">
      <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true">
        <Valve className="ibm.security.verify.sso.valve.JwtValve"
            signKeyAlias="/c=au/st=qld/l=gold coast/o=ibm/cn=demo-iag-server"
            keyStorePath="DemoKeystore.p12"
            keyStorePassword="demokeystore"
            issuer="www.ibm.com"
            audience="demo.tomcat.server"/>
      </Host>
    </Engine>
  </Service>
</Server>

Vérifier l'intégration

Le guide Verify Integration peut être utilisé pour configurer IAG afin qu'il fournisse des informations d'identité à Tomcat. 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 Tomcat avec IBM Security Verify.

Une intégration de démonstration utilisant IBM Application Gateway et Apache Tomcat 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é à Tomcat. 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 Tomcat avec IBM Security 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.