HomeUse CasesConceptsConfig GuidesDeveloper GuidesAPI Reference
Content

IBM Security Verify Intégration

Suggest Edits

IBM Verify SSO pour JBoss / Wildfly en utilisant IBM Application Gateway

IBM Verify peut être utilisé pour fournir une identité basée sur le nuage à IBM Application Gateway (IAG) en utilisant la norme OIDC. IAG est un proxy inverse léger qui fournit l'authentification et l'autorisation aux serveurs d'applications web. L'IAG peut également être utilisé pour mettre en œuvre des politiques d'authentification supplémentaires basées sur le chemin d'accès (telles que 2FA ) lorsque cela est nécessaire.

Connaissances supposées

Ce guide suppose que vous êtes familiarisé avec les applications IBM Verify et la gestion d'un registre d'utilisateurs basé sur le cloud. Les utilisateurs doivent également être familiarisés avec la configuration de IBM Application Gateway. Plus précisément, vous devez être en mesure de

  • Créez une nouvelle application IBM Verify à partir du modèle IAG.
  • Configurer une source d'identité IAG.
  • Configurer un serveur de ressources IAG.
  • Définir la configuration SSL
    • Clé/certificat SSL pour le trafic https.
    • SSL mutuel pour les serveurs de ressources protégés.
    • Fortement recommandé pour le trafic web JBoss et IAG.

Les utilisateurs doivent également être familiarisés avec la configuration d' IBM Application Gateway (IAG). En particulier, vous devez être en mesure de configurer une source d'identité et un serveur de ressources. Vous devez également fournir l'infrastructure de clés publiques requise pour prendre en charge les connexions SSL entre IAG et le serveur jonctionné.

Prérequis

Pour utiliser ce guide, vous devez disposer de

  • Un serveur JBoss / Wildfly configuré pour l'authentification SSO (ce guide)
  • Un abonnement à IBM Verify ou un compte d'essai valide
  • PKI pour sécuriser les connexions vers et depuis l'IAG et le serveur JBoss/Wildfly jonctionné

Configurer IBM Verify

Le guide du scénario de vérification peut être utilisé pour configurer un locataire IBM Verify afin de fournir des capacités SSO à IBM Application Gateway. Une application IAG doit être créée ou mise à jour pour prendre en charge la nouvelle instance IAG. Cela impliquera probablement de modifier les entrées du site redirect_uri pour y inclure le nom de domaine ou d'hôte que l'instance IAG protège.

Le registre des utilisateurs doit également être configuré maintenant (si ce n'est pas déjà fait). IBM Verify prend en charge les utilisateurs de l'annuaire en nuage ainsi que les sources d'identité fédérées.

Déploiement de IBM Application Gateway

Pour configurer l'IAG afin qu'il transmette les informations d'identité de IBM Verify à JBoss, les clés de configuration resource_servers et identity sont utilisées. La configuration requise pour chaque clé est détaillée ci-dessous.

Serveurs de ressources

La clé du serveur de ressources est utilisée pour configurer les applications en aval qui seront protégées par IAG. Au minimum, un chemin de jonction (préfixé par / ) et un serveur de ressources doivent être définis. Les en-têtes d'identité (ou JWT) et la configuration de sécurité supplémentaire sont également définis ici pour le serveur JBoss en aval.

Le serveur d'intégration cible peut être identifié par un nom DNS ou une adresse IP, pour les environnements Kubernetes, il doit s'agir du service créé pour le déploiement JBoss cible. Le certificat X509 (ou un certificat de signature) configuré pour l'authentification mutuelle (par exemple : iag.pem ) doit être un certificat de confiance dans le keystore utilisé par JBoss.

L'émetteur ( iss ), l'audience ( aud ) et le sujet ( sub ) configurés pour le JWT doivent correspondre à la configuration définie dans la configuration XML du serveur JBoss. L'ICP utilisée pour signer (et chiffrer) le JWT généré doit également être importée dans le magasin de clés utilisé par le serveur JBoss. JBoss ne prend en charge que l'utilisation de l'en-tête Authorization pour fournir des JWT et doit être du type pour Authorization: Bearer <j.w.t>.

resource_servers:
  - path: "/wildflysso"
    connection_type: ssl
    transparent_path: false
    sni: "demo.integration.server"
    mutual_auth:
      certificate_auth:
        certificate:
          - "@iag.pem"
          - "@iag.key"
    servers:
      - host: "wildfly.integration.server"
        port: 8443
        ssl:
          certificate:
            - "@integration.target.pem"
    identity_headers:
      jwt:
        hdr_name: "Authorization"
        certificate:
          - "@iag.pem"
          - "@iag.key"
        claims:
          - text: "www.ibm.com"
            name: iss
            type: string
          - attr: AZN_CRED_PRINCIPAL_NAME
            name: sub
            type: string
          - text: "demo.websphere.server"
            name: aud
            type: string

Identité

La clé d'identité peut être utilisée pour configurer IAG en tant que RP OIDC. Vous pouvez utiliser l'application IBM Verify créée ici pour fournir des informations d'identité à IAG. L'exemple fourni utilise également des types de données spéciales que IAG expose pour obscurcir les informations sensibles qui peuvent être nécessaires pour définir votre déploiement. Dans ce cas, l'identifiant et le secret du client pour l'application IBM Verify sont stockés dans un secret Kubernetes au lieu d'une carte de configuration ou définis dans le fichier de déploiement.

La définition de l'OIDC met également en correspondance l'attribut preferred_username au lieu de l'attribut sub renvoyé dans les réclamations de Verify. Cela permet de renvoyer un attribut reconnaissable par l'homme en tant que nom principal disponible pour l'application en aval.

JBoss et Wildfly utilisent également le champ kid dans un en-tête JWT pour identifier la clé publique qui doit être utilisée pour vérifier le JWT fourni. La valeur de kid utilisée par Elytron est définie dans le fichier de configuration XML du serveur. Dans un déploiement vérifié, il s'agit du nom distinctif du certificat X509 utilisé pour signer le JWT ; dans un accès vérifié, il s'agit de la valeur de l'étiquette de la clé de la base de données SSL.

identity:
  oidc:
    client_id: secret:ibm-verify-oidc-integration/client_id
    client_secret: secret:ibm-verify-oidc-integration/client_secret
    discovery_endpoint: https://your.tenant.ibmcloudsecurity.com/oidc/endpoint/default/.well-known/openid-configuration
    redirect_uri_host: ibm.security.integration.demo:30443
    mapped_identity: "{preferred_username}"
    ssl:
      certificate:
        - "@verify_tenant_ca.pem"
    response_type: code
    response_mode: query

Configuration avancée :

IAG nécessite quelques paramètres de configuration avancés supplémentaires afin de fournir un JWT dans le bon format. Le format de l'en-tête doit être modifié pour inclure la chaîne statique Bearer. Le nom de la strophe pour cette propriété dépend du nom de la jonction avec le serveur JBoss. Si un nom de jonction différent est utilisé, la clé de strophe doit être mise à jour à jwt:/<junction name>.

    advanced:
      configuration:
        - stanza: "jwt:/wildflysso"
          entry: "hdr-format"
          operation: set
          value: "Bearer %TOKEN%"

Retour au guide d'intégration JBoss/Wildfly

Démonstration du serveur d'application Wildfly : "Exemple d'intégration "hello world

Ce guide peut être utilisé pour faire une démonstration simple des fonctionnalités d'identité disponibles sur IBM Verify et IBM Application Gateway (IAG). Cette démo fournit la configuration de deux conteneurs : Un conteneur IAG configuré pour authentifier les utilisateurs avec IBM Verify; et un conteneur Wildfly avec une application Java de démonstration.

Cette démo est déployée sur Kubernetes mais pourrait être modifiée pour OpenShift ou une autre plateforme d'orchestration de conteneurs. Le code source de cette démonstration est disponible sur le site IBM Security Integrations.

Connaissances supposées

Pour réussir cette démonstration, certaines connaissances sont nécessaires. Un utilisateur doit être familier avec :

  • Déployer des conteneurs, des cartes de configuration et des secrets dans Kubernetes.
  • Création et gestion des locataires IBM Verify.

Prérequis

Pour déployer cette démo, l'utilisateur doit tout d'abord

  • Récupérer les artefacts d'intégration requis à partir des artefacts de publication ou les construire à partir du code source
  • Configurez votre environnement pour vous connecter au cluster Kubernetes (ou équivalent) utilisé pour héberger cette démo.

Configuration IBM Verify

L'identité de cette démo est fournie par IBM Verify. Un guide pour la configuration de IBM Verify en tant qu'OP pour IAG est disponible dans le Readme d'IAG

Créer/demander une ICP

Les clés asymétriques sont nécessaires pour les connexions SSL et pour signer/vérifier les JWT. Les commandes openssl suivantes permettent de générer des clés RSA et des certificats X509 auto-signés pour Wildfly et IBM Application Gateway. Le certificat X509 et la clé publique utilisés par IBM Application Gateway pour les connexions aux serveurs jonctionnés doivent également être importés dans le keystore (fichier .p12 ) utilisé par Wildfly. Pour les environnements de production, l'ICP utilisée doit être signée par une autorité de certification appropriée.

# Create IAG certificates/keys
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:4096 -keyout iag.key -out iag.pem \
        -subj "/C=AU/ST=QLD/L=Gold Coast/O=IBM/CN=demo.iag.server"

# Create Wildfly certificae/keys/pcsk12
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:4096 -keyout wildfly.key -out wildfly.pem \
        -subj "/C=AU/ST=QLD/L=Gold Coast/O=IBM/CN=demo.integration.server"

# Import IAG X509 into the Wildfly keystore
openssl pkcs12 -export -out application.keystore -inkey wildfly.key -in wildfly.pem -passout pass:demokeystore -name server
keytool -importcert -keystore application.keystore -file iag.pem -alias isvajwt -storepass demokeystore -noprompt

Déploiement de IBM Application Gateway

Une fois que l'application IBM Verify a été créée et que l'ICP a été générée, l'application peut être déployée sur votre plateforme d'orchestration de conteneurs ( OpenShift/Kubernetes ). Deux conteneurs sont nécessaires pour cette démonstration : le conteneur IAG est configuré en tant que RP OIDC pour l'OP IBM Verify précédemment configuré; et un serveur d'application Wildfly qui est la cible de l'intégration. Le déploiement de l'IAG nécessite trois objets Kubernetes: Une carte secrète pour les données sensibles; une carte de configuration avec la configuration IAG; et un déploiement qui définit les conteneurs IAG à déployer. Les sections suivantes expliquent comment ces objets sont créés.

Carte IAG Secrets

Kubernetes les secrets sont utilisés pour obscurcir des données sensibles telles que l'identifiant du client et le secret de l'application IBM Verify. Des informations supplémentaires non sensibles telles que le fichier config.yaml et tous les certificats/clés X509 doivent être ajoutés à l'aide des cartes de configuration.

apiVersion: v1
kind: Secret
metadata:
  name: ibm-verify-oidc-integration
type: Opaque
data:
  client_id: "change this"
  client_secret: "change this"

Carte de configuration IAG

Le fichier de configuration yaml, qui définit les ressources protégées et les politiques d'accès, est au cœur du déploiement de l'IAG. L'exemple suivant établit une jonction avec un serveur d'application Wildfly et définit la JWT fournie au serveur. IBM Verify la configuration de l'identité est également définie dans ce fichier. Si une option de configuration ne peut pas être définie avec les options de configuration documentées, l'entrée advanced/configuration peut être utilisée pour définir les entrées de configuration du démon proxy inverse.

apiVersion: v1
kind: ConfigMap
metadata:
  name: ibm-verify-wildfly-integration-config
data:
  iag.pem: |
%%IAG_CERTIFICATE%%
  iag.key: |
%%IAG_KEY%%
  integration.target.pem: |
%%INTEGRATION_SERVER_CERTIFICATE%%
  verify_tenant_ca.pem: |
%%VERIFY_TENANT_CERT%%
  config.yaml: |
    version: 21.09
    server:
      ssl:
        front_end:
          certificate:
            - "@iag.pem"
            - "@iag.key"
    resource_servers:
      - path: "/wildflysso"
        connection_type: ssl
        transparent_path: false
        sni: "demo.wildfly.server"
        mutual_auth:
          certificate_auth:
            certificate:
              - "@iag.pem"
              - "@iag.key"
        servers:
          - host: "wildfly-integration"
            port: 8443
            ssl:
              certificate:
                - "@integration.target.pem"
        identity_headers:
          jwt:
            hdr_name: "Authorization"
            certificate:
              - "@iag.pem"
              - "@iag.key"
            claims:
              - text: "www.ibm.com"
                name: iss
                type: string
              - attr: AZN_CRED_PRINCIPAL_NAME
                name: sub
                type: string
              - text: "demo.integration.server"
                name: aud
                type: string
    advanced:
      configuration:
        - stanza: "jwt:/wildflysso"
          entry: "hdr-format"
          operation: set
          value: "Bearer %TOKEN%"
    identity:
      oidc:
        client_id: secret:ibm-verify-oidc-integration/client_id
        client_secret: secret:ibm-verify-oidc-integration/client_secret
        discovery_endpoint: https://iag-dev.pre1.idng.ibmcloudsecurity.com/oidc/endpoint/default/.well-known/openid-configuration
        redirect_uri_host: ibm.security.integration.demo:30443
        #mapped_identity: "{sub}"
        ssl:
          certificate:
            - "@verify_tenant_ca.pem"
        response_type: code
        response_mode: query

IBM Application Gateway déploiement

Ensuite, nous devons définir le conteneur IBM Application Gateway et le connecter à la couche de service Kubernetes afin qu'il soit accessible à partir d'adresses réseau extérieures au cluster Kubernetes. La version du conteneur utilisée doit correspondre à la version définie dans le ConfigMap config.yaml. Des contrôles de santé des conteneurs sont également définis pour permettre à Kubernetes de réagir si le conteneur IBM Application gateway cesse de répondre.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iag-instance
  labels:
    app: iag-instance
spec:
  selector:
    matchLabels:
      app: iag-instance
  replicas: 1
  template:
    metadata:
      labels:
        app: iag-instance
    spec:
      #serviceAccountName: ibm-application-gateway
      imagePullSecrets:
        - name: iag-login
      volumes:
        - name: integration-config
          configMap:
            name: ibm-verify-wildfly-integration-config
      containers:
        - name: iag-instance
          image: ibmcom/ibm-application-gateway:21.09.0
          imagePullPolicy: IfNotPresent
          volumeMounts:
            - name: integration-config
              mountPath: /var/iag/config
          readinessProbe:
            exec:
              command:
              - /sbin/health_check.sh
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            exec:
              command:
              - /sbin/health_check.sh
            initialDelaySeconds: 120
            periodSeconds: 20
---
apiVersion: v1
kind: Service
metadata:
  name: iag-instance
  labels:
    app: iag-instance
spec:
  ports:
    - port: 8443
      name: iag
      protocol: TCP
      nodePort: 30443
  selector:
    app: iag-instance
  type: NodePort

Déploiement du serveur JBoss Wildfly de démonstration

L'étape finale de cette démo consiste à déployer le serveur Wildfly qui est la cible de cette intégration. Un conteneur Wildfly simple est fourni dans le cadre des ressources de démonstration. Ce conteneur est déjà configuré pour utiliser la fonction JWT token-realm afin de fournir des informations d'identité à l'application Java.

L'application de démonstration déployée dans le conteneur Wildfly est configurée pour refléter les informations d'identité fournies dans l'objet java Principal. Un keystore PCKS12 est également monté dans le fichier keystore par défaut de Wildfly, ce qui permet de s'assurer que le certificat SSL fourni par IBM Application Gateway peut être validé par Wildfly (TLS mutuel).

apiVersion: v1
kind: ConfigMap
metadata:
  name: wildfly-config
binaryData:
  application.keystore: %%WILDFLY_KEYSTORE%%
  SecTestWeb.war: %%DEMO_APPLICATION%%
  standalone.xml: |
    %%STANDALONE_XML%%
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wildfly-integration
  labels:
    app: wildfly-integration
spec:
  selector:
    matchLabels:
      app: wildfly-integration
  replicas: 1
  template:
    metadata:
      labels:
        app: wildfly-integration
    spec:
      volumes:
        - name: wildfly-config
          configMap:
            name: wildfly-config
      containers:
        - name: wildfly-integration
          image: jboss/wildfly:latest
          imagePullPolicy: IfNotPresent
          args: ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]
          ports:
            - containerPort: 8443
          volumeMounts:
            - mountPath: /opt/jboss/wildfly/standalone/configuration/application.keystore
              subPath: application.keystore
              name: keystore-volume
            - mountPath: /opt/jboss/wildfly/standalone/deployments/SecTestWeb.war
              subPath: SecTestWeb.war
              name: wildfly-config
            - mountPath: /opt/jboss/wildfly/standalone/configuration/standalone.xml
              subPath: standalone.xml
              name: wildfly-config
---
apiVersion: v1
kind: Service
metadata:
  name: wildfly-integration
  labels:
    app: wildfly-integration
spec:
  ports:
    - port: 8443
      name: wildfly-integration
  selector:
    app: wildfly-integration
  type: NodePort

Updated about 1 month ago