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
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.
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
issuernom de domaine du proxy inverse fournissant l'identité.audiencesnom de domaine du serveur d'application Liberty consommant l'identité.keyNameidentifie 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
issdu 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 fonctionappSecuritydoit ê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 fonctionmpJwtest utilisée pour valider et analyser le JWT fourni et générer un Principal qui est disponible pour les servlets suivants. Enfin, la fonctionssldoit é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êteAuthorization, 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.
Updated about 1 month ago
