Table des matières

 

SAML Aperçu

• Composants de SAML SSO solution.

• Cas d’utilisation.

• SAML Flux logique.

• TOOLS.

• SAML Messages.

• • SAML Demande d’authentification.

  • SAML Réponse d’authentification.

  • SAML Demande logout.

  • SAML Réponse logout.

• Métadonnées IdP XML .

• SP Métadonnées XML .

 

 

 

SAML Aperçu

 

Security Assertion Markup Language 2.0 (SAML 2.0) est une XML- norme basée pour l’échange de données d’authentification et d’autorisation entre les domaines de sécurité. SAML résout principalement deux exigences dans l’entreprise : une seule inscription sur le Web entre plusieurs entités et une identité fédérée. Single Sign-On est atteint par le partage des informations d’identité entre plusieurs organisations et applications. Une identité fédérée permet un ensemble de fournisseurs de services à s’entendre sur un moyen de faire référence à un seul utilisateur, même si cet utilisateur est connu pour les fournisseurs sous différentes formes.

 

Composants de SAML SSO solution

 

En règle générale, trois entités participent à une SAML transaction :

• Principal (utilisateur)
• Fournisseur de services ( SP )
• Fournisseur d’identité (IdP)

 

Le prestataire de services est généralement l’application ou le service qu’une entité de sécurité a demandé l’accès à, et le fournisseur d’identité est l’entité qui est branchée sur l’identité stocker qui transporte des informations d’identification de l’utilisateur. SAML ne définit pas les techniques qu’un IdP peut utiliser pour authentifier l’utilisateur - au lieu de cela, il se concentre sur la définition de l’échange d’informations entre un SP et un IdP pour indiquer l’état d’authentification et d’autorisation du principal. Cela donne à IdP la liberté d’utiliser des techniques d’authentification supplémentaires (2FA/ MFA , authentification basée sur un certificat...) pour authentifier l’utilisateur. SAML les messages utilisent XML comme format d’échange de données, et sont transportés HTTP avec une forte exigence pour sécuriser ces messages en utilisant / ( SSL TLS HTTPS )

 

SAML Assertion contient des informations sur l’authentification et l’utilisateur. L’affirmation contient des informations, le récepteur peut utiliser pour prendre une décision de contrôle d’accès. Il existe 3 types d’instructions d’Assertion :

 

• L’instruction d’authentification contient des informations telles que le temps et la méthode utilisés pour assurer l’identité de l’utilisateur.

 

• L’instruction attribut contient des informations sur l’utilisateur telles que le nom d’utilisateur, numéro de téléphone, adresse ... Etc.

 

• L’instruction de décision d’autorisation confirme si l’utilisateur est autorisé à accéder à une ressource spécifiée.

 

SAML utilise des jetons de sécurité contenant des affirmations pour transmettre des informations sur un mandant (généralement un utilisateur final) entre une SAML autorité, c’est-à-dire un fournisseur d’identité, et SAML un consommateur, c’est-à-dire un fournisseur de services. Par exemple, le fournisseur d’identité affirme que cet utilisateur a été authentifié et a donné des attributs associés. Dans SAML , Fournisseurs d’identité sont également connus comme SAML les autorités et les parties affirmant. Les fournisseurs de services sont également connus sous le nom de parties qui comptent – en raison du fait qu’ils « s’appuient » sur les renseignements fournis par un fournisseur d’identité (partie qui affirme). Le fournisseur d’identité fait passer des affirmations au Service des consommateurs assertions ( ) et ce service valide les ACS URL affirmations pour s’assurer que l’utilisateur final est autorisé à accéder à l’application et à d’autres ressources. ACS URL est important parce que c’est URL là que le fournisseur de services recevra et consommera les affirmations.

 

Les protocoles de communication ou de messagerie de niveau inférieur (tels HTTP que ou ) que les messages peuvent être SOAP SAML transportés sont définis par liaisons. SAML Les fixations sont des crochets sur un point final qui dictent la façon SP dont un idp communiquer. Avec HTTP comme transport, les fixations typiques incluent REDIRECT ( HTTP 302) et POST ( HTTP POST ). HTTP Liaison de redirection: Définit la façon dont les SAML messages de protocole peuvent être transportés à l’aide de messages de HTTP redirection (réponses au code d’état 302).  SAML les requêtes ou réponses transmises via Redirect ont respectivement un paramètre de chaîne de requête HTTP SAMLRequest ou SAMLResponse. Avant d’être envoyé, le message est dégonflé (sans en-tête et sans contrôle), codé et URL- codé 64, dans cet ordre. Dès réception, le processus est inversé pour récupérer le message d’origine. Les PS et les personnes déplacées peuvent transmettre et recevoir des messages à l’aide de redirections ou POST de liaisons. En raison de la limitation des URL longueurs dans certains scénarios, HTTP Redirect est généralement utilisé lors de la transmission de messages courts, et HTTP POST est utilisé lors de la transmission de messages plus longs.

 

HTTP POST Reliure: Définit comment les SAML messages de protocole peuvent être transportés dans le contenu codé de base64 d’un contrôle de HTML formulaire.

Les points de terminaison de Palo Alto Networks SP ne peuvent accepter les messages que SAML lorsqu’ils sont transportés à l’aide HTTP POST .

Une SAML autre terminologie à connaître est métadonnées. Il contient des informations sur les schémas et les points de terminaison sur l’IdP et le SP . Chaque IdP et chacun SP devrait avoir ses propres métadonnées. Personnes déplacées et SPs enregistrent généralement entre eux à l’aide de métadonnées. En règle générale, les métadonnées contiennent SSO URL des informations telles que le nom de l’émetteur et le certificat contenant la clé PKI « publique ». Par exemple, un SP utilisateur peut utiliser ces informations pour faire confiance à une affirmation provenant d’un IdP et vice-versa. SAML 2.0 fournit un format de métadonnées bien défini et interopérable que les entités peuvent tirer parti pour démarrer le processus de fiducie. Métadonnées fournies par l’IdP pour SP contient des informations sur idp (comme entité , / ID SSO SLO URL ... etc.) et vice-versa.

 

 

Cas d'utilisation

 

SSO pour Captive Portal:

Les clients aimeraient utiliser notre capacité à lancer un portail captif lorsqu’un utilisateur tente d’accéder à des HTTP- ressources spécifiques. Pour atténuer la nécessité pour un utilisateur de se connecter plusieurs fois, les clients comptent SAML- sur SSO basé, où, l’utilisateur se connecte une fois avec leur IdP, et est ensuite autorisé l’accès à tout fournisseur de services qui est enregistré avec le même IdP aussi longtemps que l’utilisateur passe toutes les vérifications d’autorisation requises. En outre, ces clients utilisent également le portail captif pour identifier de manière transparente les utilisateurs (Utilisateur- ID ), si la cartographie IP utilisateur/utilisateur a expiré. Portail captif peut également être utilisé pour authentifier un utilisateur connu qui tente d’accéder à une ressource protégée. Cette fonctionnalité fournit le niveau de garantie de sécurité requis pour les administrateurs et fournit une interface simple et sans tracas pour les utilisateurs finaux. Dans une organisation, plusieurs applications peuvent utiliser la même PDI pour authentifier les utilisateurs. À condition que les applications utilisent et SAML le même IdP pour authentifier les utilisateurs, l’utilisateur obtenir une expérience cohérente quand ils accèdent à ces applications et authentifier.

 

SSO pour GlobalProtect :

Les clients aimeraient utiliser basé SAML pour . permet à ces entreprises SSO GlobalProtect SAML d’utiliser une architecture unique pour toutes SSO les applications, et pour tous les utilisateurs sur toutes les plates-formes d’appareils. Depuis GlobalProtect fonctionne sur plusieurs plates-formes, et depuis est SAML agnostique SAML plate-forme, est un choix parfait pour simple sign-on. GP Gateways and Portals agira à titre de fournisseur SAML de services, reportant le processus d’affirmation d’identité à un fournisseur d’identité SAML tiers.

 

SSO pour Firewall / Panorama GUI :

Firewall et Panorama les administrateurs cherchent à accéder à GUI l’administrateur sans avoir à s’y connecter manuellement. Permettre aux administrateurs autorisés d’accéder directement à notre au sein GUI d’une entreprise qui SAML s’est déployée comme sa norme réduit SSO l’effort de l’utilisateur requis pour logon, et permet firewall à la / de s’appuyer sur un moteur Panorama d’authentification centralisé aux fins de l’affirmation d’identité.

 

 

 

SAML Flux logique

 

Dans l’exemple suivant, nous mettrons en évidence l’écoulement de l’authentification d’un utilisateur à l’aide de portail captif. Il met en évidence l’interaction entre l’utilisateur, firewall la ressource (fournisseur de services) et l’IdP. Le flux d’authentification est similaire SP pour les autres paramètres (Admin , Portal / UI GlobalProtect Gateway, GlobalProtect Clientless SSL VPN )

 

 Flux d’authentification

 

1. L’utilisateur fait une demande à une ressource (soit sur un fournisseur de services, comme Firewall / ou sur un autre serveur Web - comme Panorama GUI bing.com )
2. Si une demande à une ressource n’est pas Firewall à / et si une règle Panorama GUI d’authentification Policy existe, il est exécuté et l’utilisateur est redirigé vers un portail captif URL .
3. Le navigateur de l’utilisateur accède au portail captif URL
4. Le fournisseur de services crée un objet AuthnRequest, qui indique comment l’utilisateur SP veut authentifier. L’AuthnRequest est codé et est envoyé au fournisseur d’identité via ou la HTTP POST méthode HTTP redirection via le navigateur de l’utilisateur. Détails SAML sur AuthnRequest, Response etc... sera expliquée dans la seconde moitié du document.
5. Si IdP n’a précédemment a authentifié l’utilisateur, le PDI envoie un cookie qui identifie l’utilisateur. Ce cookie est stocké dans le navigateur. Dans le prolongement de l’étape précédente (étape 4), si l’utilisateur a déjà authentifié avec le PCI, ainsi que de la AuthnRequest, cookie stocké dans le navigateur est également envoyé à la PDI via le navigateur de l’utilisateur. IdP vérifie si c’est un cookie valide. Si un cookie valide n’existe pas, ou si un cookie n’existe pas, le PDI authentifie l’utilisateur. IdP présentera la demande de connexion au navigateur et basé sur le mécanisme d’authentification configuré, l’utilisateur sera authentifiée. Par exemple, une authentification simple basée sur le formulaire peut être configurée et LDAP un serveur peut être interrogé pour effectuer la recherche de l’utilisateur. L’utilisateur sera présenté avec une demande de connexion et dans le navigateur, l’utilisateur saisit des informations d’identification et les publie sur IdP. L’IdP soumet les informations d’identification de connexion au LDAP serveur. LDAP le serveur vérifie les informations d’identification et renvoie l’état de validation à l’IdP.
6. L’IdP crée une SAML assertion, la signe avec sa clé privée et redirige l’utilisateur vers le fournisseur de services via la méthode HTTP POST incluant SAML l’assertion. En utilisant les informations fournies dans l’affirmation, le SP prendra les décisions appropriées telles que fournir à l’utilisateur l’accès à la ressource protégée.
7. Le fournisseur de services valide SAML l’assertion et XML la signature fournies par l’IdP. Il extrait le nom d’utilisateur de SAML l’assertion via les attributs du nom d’utilisateur et vérifie l’utilisateur et le groupe d’utilisateurs par rapport à la liste de permis. Si les vérifications d’accès pass, la ressource est ensuite retournée au navigateur. Navigateur complète la connexion à des ressources telles que bing.com

 

TOOLS

 

Il ya quelques DevTools qui peuvent être chargés sur le navigateur (comme Chrome), qui peut aider à débogage des SAML messages. Certaines des extensions chrome populaires sont :

• SAML Panneau Chrome
• SAML DevTools Extension

 SAML Extension DevTools

 

 

 

SAML Messages

 

SAML Demande d’authentification

 

AuthnRequest est un SAML message qui envoie à SP IdP afin d’initier l’authentification. Ce message est codé en Base64 et envoyés à la PDI. Avec l’Authnrequest codé par Base64, SAML un jeton Relaystate est envoyé à IdP. Le jeton Relaystate est un identificateur opaque qui fait référence aux informations d’état maintenues au fournisseur de services. Ce jeton est repris par le PDI dans son message de réponse.

 

 

SAML AuthnRequest (en)

Les éléments importants dans le AuthnRequest ci-dessus sont :

• Assertion Consumer Service URL
• Destination URL
• Moment de la demande (question instantanée)
• ID de la demande
• Émetteur

 

Assertion Consumer Service estURL l’adresse du fournisseur de services où le message de réponse sera envoyé par l’IdP une fois l’authentification terminée.

 

Destination est URL vérifiée par l’IdP pour valider que la demande d’authentification est effectivement destinée à elle. Ceci est utile pour empêcher malveillante transmission des requêtes aux destinataires non intentionnelles.

 

L’heure de la demande est vérifiée par l’IdP pour vérifier si la demande faite n’était pas trop ancienne.

IDde la demande est un nombre aléatoire généré et il est important qu’il corresponde à la réponse de la demande.

 

L’émetteur identifie l’entité qui a généré le message de demande. En règle générale, chaque demande et réponse contient une ID entité de l’expéditeur.

 

Autres éléments à noter sont les suivants :

 

• Liaison de protocole
• Signature
• Valeur Digest
• Certificat de x509

 

Protocol Binding est la référence qui identifie un protocole URI SAML liant à utiliser lors du retour du message de réponse.

 

La valeur signature et digeste sont utilisées pour assurer l’intégrité des messages de demande et de réponse. Cette valeur sera recoupée et validée du côté de réception à l’aide de la même méthode Digest (par exemple SHA1) pour assurer l’intégrité du message

 

Certificat X509 : In SAML , the and SP IdP exchange public certificate key with each other. Les certificats puis installés et explicitement approuvés. Pour établir l’approbation de l’origine de la clé, autorité de certification peut être utilisée. La clé publique, incluse dans le message AuthnRequest ou réponse doit indiquer au partenaire que les messages signés de l’entité avec la clé privée correspondante. Simplement, il détermine que la clé appartienne à l’autre partie.

 

Fig: SAML AuthnRequest ( FW GUI et Chrome Dev Tool)

 

SAML AuthnRequest (en)

Fig: RelayState

 

RelayState

 

SAML Réponse d’authentification

 

Une fois que l’IdP authentifie l’utilisateur, il crée une réponse codée Base64 SAML et la transmettre au fournisseur de services.

En réponse à l’AuthnRequest, l’IdP envoie à SP , état et affirmations de sécurité. La réponse contient état des succès et des assertions dans le cas où l’utilisateur est authentifié avec succès par le PDI. Dans le cas de toute autre défaillance, la réponse contient l’état indiquant les raisons de l’échec et il ne contiendra pas les affirmations. IdP authentifie l’utilisateur et le SP n’est pas impliqué dans ce processus. SP reçoit juste le statut de l’authentification.

 

SAML Réponse 

 

La majorité des éléments de la SAML Réponse sont semblables à ceux discutés dans le cadre d’AuthnRequest. Ceux qui n’est pas couverts en AuthnRequest est examinés ci-dessous.

 

• Statut
• Name ID
• Index de la session
• Déclaration de l’attribut et la valeur de l’attribut
• Instruction d’authentification

 

L’élément statut décrit si l’utilisateur a été authentifié avec succès ou non

 

NameID est un identifiant unique créé par IdP pour gérer le cycle de vie de la session de sécurité/principal d’utilisateur après une authentification réussie (dans ce cas, IdP est considérée comme autorité de session)

 

L’index de session est l’identificateur unique créé par IdP pour garder une trace de ce SP que fait l’utilisateur/principal SAML SSO (dans ce cas, SP est considéré comme participant à la session)

 

L’instruction attribut contient des attributs associés à un utilisateur. Dans l’exemple ci-dessus, samAccountName de l’utilisateur est envoyé par l’IdP à SP .

 

L’instruction d’authentification contient des informations telles que le temps et la méthode utilisés pour assurer l’identité de l’utilisateur

 

Fig: SAML Réponse ( et Chrome FW GUI Dev Tool)

 

SAMLRéponse Fig: RelayState

 

RelayState

 

SAML Demande logout

 

Lorsque l’utilisateur se connecte à Firewall GUI partir de , le fournisseur de services crée une SAML demande Logout pour mettre fin à la session utilisateur. La SLO demande est envoyée à l’IdP. NameID et l’index de session sont utilisés par l’IdP et SP pour mettre fin à la session utilisateur. L’IdP enverrait idéalement SLO une demande à toutes les autres applications sur qui SP l’utilisateur s’est connecté. Ainsi, lorsque l’utilisateur se déconnecte d’une application, le PDI essaie de déconnecter l’utilisateur toutes les autres applications.

 

SAML LogoutRequest

 

Si Redirect est choisi comme SAML HTTP reliure SLO pour , alors vous verrez la signature de la demande SAML Logout que le signé dans la SP URL GET demande

 

Fig: SAML LogoutRequest ( FW GUI et Chrome Dev Tool)

 

SAML LogoutRequest

SAML Réponse logout

 

Pour la SLO demande envoyée à IdP par le , SP IdP envoie une réponse Logout indiquant le succès ou l’échec. La réponse sera signée par le PDI. Le SP fait les nettoyages nécessaires avant de connecter l’utilisateur. Le SP permettra d’éclaircir les cookies de session qu’il a pour l’utilisateur. La prochaine fois, lorsque l’utilisateur tente de se connecter, l’ensemble du processus SAML redémarre. SPL’utilisateur peut également effacer les cookies de session en fonction du délai d’attente inactif de la session et redémarrer le processus SAML d’authentification lorsque l’utilisateur tente d’accéder à nouveau à l’application.

 

SAML LogoutResponse

 

Fig: SAML LogoutResponse FW GUI (et Chrome Dev Tool)

 

SAML LogoutResponse

 

Métadonnées IdP XML

 

Le partage de la confiance entre IdP SP et peut être facilement facilité par les métadonnées.

Dans le SP ( ou ), le profil du serveur Firewall Panorama IdP peut être construit à l’aide du fichier De métadonnées IdP XML fourni. Les informations fournies dans les métadonnées sont parsed et enregistrées dans le Panaroma ou la Firewall configuration. IdP métadonnées peuvent contenir les informations suivantes :

 

• Entité IdP ID
• IdP (IdP) SSO URL
• SSO format de liaison ( SAML HTTP Binding – POST /Redirect)
• IdP (IdP) SLO URL
• SLO bind format ( SAML HTTP Binding – POST /Redirection)
• SAML Attributs
  • Nom d’attribut de nom d’utilisateur
  • Nom de l’attribut UserGroup
  • Nom de l’attribut rôle admin
  • Nom de l’attribut domain Access
• Certificat de signature de PDI
• Drapeau de l’IdP WantAuthnRequestsSigned

 EntityDescriptor (en)

 

SP Métadonnées XML

 

SP métadonnées peuvent être exportées à partir du profil SAML d’authentification Panorama à partir de / Firewall .Si IdP donne la possibilité de télécharger SP des données remplies,les SP métadonnées exportées peuvent être téléchargées dans IdP SAML et l’application peut être facilement créée. Comme mentionné précédemment, les métadonnées peuvent être exploitées pour démarrer le processus de confiance.

 

Les SP métadonnées peuvent contenir les éléments suivants :

 

• ACS URL
• ACS format contraignant
• SLO URL
• SLO format contraignant
• Entité ID
• Certificat de signature

 

EntityDescriptor