Scénarii de connexion unique, fonctions et limitations SAML

Le langage SAML (Security Assertion Markup Language) est une norme ouverte OASIS de représentation et d'échange d'informations sur l'identité, l'authentification et l'attribut de l'utilisateur. Le langage SAML devient la technologie de premier plan assurant l'interopérabilité de connexion unique entre les fournisseurs.

Le fournisseur de services WebSphere Application Server SAML prend en charge la connexion SSO initiée par SAML 2.0 Identity Provider (IdP). Le service SSO initié par WebSphere IdP est mis en oeuvre en tant qu'intercepteur de relations de confiance et peut être décrit comme suit :
  1. L'utilisateur accède à une application Web en avant-plan pouvant résider sur IdP, SP ou ailleurs.
  2. L'application Web en avant-plan réachemine l'utilisateur vers IdP, et l'utilisateur s'authentifie auprès d'IdP.
  3. IdP réachemine l'utilisateur vers ACS (Assertion Consumer Service) dans SP en envoyant une réponse SAML sur HTTP POST à l'intérieur d'un formulaire masqué.
  4. SP traite la réponse SAML et crée un contexte de sécurité WebSphere.
  5. SP ajoute le cookie LTPA à la réponse HTTP et réachemine la requête vers la ressource Web ou l'application métier.
  6. WebSphere Application Server intercepte la requête et met en correspondance le cookie LTPA avec le contexte de sécurité, puis autorise l'utilisateur à accéder à la ressource Web demandée.
  7. WebSphere Application Server renvoie la réponse HTTP à l'utilisateur.

Les images ci-dessous illustrent le flux SAML SSO :

Flux SAML SSO

Les fonctions SAML SSO sont les suivantes :
  • Le fournisseur de services WebSphere SAML prend en charge la connexion unique avec plusieurs fournisseurs d'identité.
  • Le fournisseur de services WebSphere SAML prend en charge des options de vérification d'identité et de mise en correspondance de la vérification d'identité avec le registre d'utilisateurs du fournisseur de services.
  • Le fournisseur de services WebSphere SAML peut mapper ou présenter les attributs de jeton SAML avec le domaine, le principal, l'ID unique et le groupe et les définir dans le contexte de sécurité du fournisseur de services.
  • Le fournisseur de services WebSphere SAML offre un point de module d'extension permettant la mise en correspondance d'identité personnalisée.
  • Le fournisseur de services WebSphere SAML a la possibilité d'extraire l'appartenance au groupe de l'identité de son registre et de renseigner le contexte de sécurité.
  • Le fournisseur de services WebSphere SAML donne un filtre de sélection IdP afin d'acheminer la requête vers l'IdP correct si elle ne provenait pas d'IdP.
  • Le fournisseur de services WebSphere SAML prend en charge les algorithmes de signature RSA-SHA1 et RSA-SHA256.
  • Le fournisseur de services WebSphere SAML place le jeton SAML dans l'objet du fournisseur de services pour permettre à l'application d'y accéder, et le met à disposition d'un EJB (Enterprise JavaBean) authentifié en aval ou d'un appel Web Service.
  • Le fournisseur de services WebSphere SAML permet à l'URL d'une application métier de faire office d'URL AssertionConsumerService, de sorte qu'IdP puisse directement envoyer un SAMLResponse à l'URL de l'application métier.
  • L'intercepteur de relations de confiance WebSphere SAML permet de contrôler les assertions SAML clé, y compris Issuer et NameID.
Les mises en évidence et meilleures pratiques de fonction suivantes s'appliquent aux fonctions SAML SSO :
  • Service consommateur d'assertion (ACS) du fournisseur de services WebSphere SAML :
    ACS est un servlet sécurisé qui accepte un message de protocole SAML et établit le contexte de sécurité. L'URL d'un ACS contient un ContextRoot prédéfini (samlsps, par exemple) et se présente au format suivant :
    https://<nom d’hôte>:<port>/samlsps/<masque URI>
    La SAMLResponse reçue par l'ACS est interceptée par TAI et, après validation, la requête est réacheminée vers le service d'application cible.

    Un service métier qui met en oeuvre la méthode POST peut agir comme un ACS. Il est préférable d'utiliser un servlet métier cible comme ACS, étant donné qu'il se limite à un aller-retour entre le navigateur et le serveur du fournisseur de services.

  • Prise en charge de plusieurs domaines de sécurité :
    Un ACS est déployé vers un domaine de sécurité d'application, et il est prévu que l'ACS réside sur le même domaine de sécurité que l'application métier. Si l'ACS et l'application métier cible (RelayState) se trouvent dans des domaines de sécurité différents, les options recommandées sont les suivantes :
    • Traiter SAMLResponse dans le domaine de sécurité de l'ACS.
    • Reconfigurer l'ACS pour qu'il dispose du même domaine que l'application métier.
    • Utiliser le service métier cible en tant qu'ACS.
  • Plusieurs partenaires à connexion unique :

    WebSphere TAI SAML prend en charge plusieurs ACS partenaires à connexion unique IdP (SingleSignOnService). Un partenaire à connexion unique (SSO) est défini comme une URL d'ACS et peut avoir plusieurs objets SingleSignOnService. Avec l'existence de plusieurs partenaires SSO, chaque partenariat SSO est identifié de manière unique par une URL d'ACS.

    Chaque partenaire SSO peut avoir ses propres règles de validation, règles de mappage assertion-objet ou une règle de démarrage de la connexion unique avec son IdP. Par exemple, un partenaire SSO peut gérer une vérification d'ID, qui consiste à générer un objet de plateforme WebSphere sans appel dans le registre d'utilisateurs. Un autre partenaire SSO peut procéder à une recherche dans le registre d'utilisateurs local. De même, un partenaire SSO gère la connexion unique avec un IdP, un autre partenaire SSO la gérant avec un IdP différent.

  • Connexion unique de type signet et filtre TAI :

    Soit une connexion unique de type signet entrant généralement dans le cadre d'une connexion unique initiée par SP. L'utilisateur accède à l'application métier sans préalablement s'authentifier auprès de l'IdP. WebSphere SAML TAI peut être configuré pour initier une connexion unique. Chaque configuration de partenaire SSO contient une application de connexion IdP et un filtre de routage. Chaque filtre définit une liste de règles de sélection. Ces règles constituent les conditions qui sont comparées à la requête HTTP afin de déterminer si la requête HTTP est sélectionnée ou non pour un partenaire SSO. La règle de filtrage est une combinaison d'en-tête de requête HTTP, de données de référent et du nom d'application cible. L'environnement d'exécution WebSphere SAML TAI vérifie la demande d'utilisateur en fonction de toutes les règles de filtrage afin d'identifier sans équivoque le partenaire SSO, puis réachemine la requête vers l'application de connexion IdP sélectionnée. Le filtre TAI permet à une connexion unique initiée par IdP de fournir une fonctionnalité similaire, combinant la connexion unique initiée par SP à un service de reconnaissance IdP.

  • Mappage d'identité et gestion de contexte de sécurité :
    WebSphere SAML TAI offre un mappage d'identité riche et flexible, et peut être classé comme suit :
    • Vérification d'identité : mapper l'assertion SAML à l'objet de plateforme WebSphere sans registre local. Les scénarii classiques de vérification d'ID incluent :
      • Par défaut : utiliser l'ID de nom comme principal, l'émetteur comme domaine, l'attribut sélectionné comme membres de groupe.
      • Personnalisé : configurer l'attribut SAML comme principal, domaine, ID d'accès et membres de groupe.
    • Mapper l'ID de nom de l'IdP selon le registre d'utilisateur du fournisseur de services, puis générer l'objet à partir du registre. Les scénarii suivants sont pris en charge :
      • Mapper directement l'ID de nom SAML au registre local.
      • Fournir un point de module d'extension pour le mappage personnalisé, puis utiliser un nouvel utilisateur pour générer l'objet.
      • Mapper l'ID de nom au registre d'utilisateurs, puis retourner à la vérification d'ID.
    • Combinaison de la vérification d'ID et du registre local :

      Outre la vérification d'ID, TAI recherche les groupes parent des groupes évalués dans le registre d'utilisateurs du fournisseur de services, puis les inclut dans l'objet. Par exemple, les autorisations sont accordées aux groupes parent, mais le fournisseur d'identité ne connaît pas leur nom.

WebSphere Application Server prend uniquement en charge la connexion unique Web SAML initiée par IdP.

Les spécifications ou scénarii suivants n'entrent pas dans le cadre :
  • Profil de client ou proxy (ECP) étendu
  • Profil de reconnaissance de fournisseur d'identité
  • Profil de connexion unique
  • Profil de gestion d'identificateur de nom
  • Profil de résolution d'artefact
  • Profil de demande/requête d'assertion
  • Profil de mappage d'identificateur de nom
  • Profils d'attribut SAML

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_samlssosummary
Nom du fichier : cwbs_samlssosummary.html