web-dev-qa-db-fra.com

Comment devenir un fournisseur de services SAML

Mon entreprise développe actuellement une Java. Quelques-uns de nos clients ont des serveurs SAML internes (fournisseurs d'identité?) Et ont demandé que nous nous intégrions à eux. Alors récemment, j'ai lu sur et en jouant avec OpenAM. Après environ 3 jours, j'ai une compréhension générale, mais il y a encore des lacunes dans mes connaissances. J'espère que quelqu'un pourra éclaircir cela pour moi.

Voici donc comment j'imagine le flux de travail d'un utilisateur qui se connecte.

Définissons le serveur SAML de nos clients comme https://their.samlserver.com . Ainsi, un utilisateur vient à notre application Web pour une ressource qui est protégée. Disons que l'URL est http://my.app.com/something .

Donc, si j'ai raison, my.app.com est ce que SAML définit comme un fournisseur de services . Notre application se rend compte que cet utilisateur doit se connecter. Nous présentons ensuite une page comme celle-ci à l'utilisateur ...

<script>JQuery Script to auto submit this form on ready</script>
<form method="post" action="https://their.samlserver.com/Post/Servlet">
    <input type="hidden" name="SAMLRequest" value="someBase64Data" />
    <input type="submit" value="Submit" />
</form>

Et cela someBase64Data devrait être base64 version codée de cette ...

<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_1"
  Version="2.0"
  IssueInstant="2004-12-05T09:21:59Z"
  AssertionConsumerServiceIndex="0">
 <saml:Issuer>http://my.app.com</saml:Issuer>
 <samlp:NameIDPolicy
   AllowCreate="true"
   Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>

Donc mes deux premières questions.

Quelle est la valeur [~ # ~] id [~ # ~] supposée être?

Et pourquoi puis-je me déclarer émetteur ?

Le fournisseur d'identité est-il au courant de moi? Peut-être que c'est Cercle de confiance que j'ai vu sur OpenAM . Et s'il me connaît, comment le sait-il et que doit-il savoir?

Ainsi, après que l'utilisateur a transmis cette page, ils sont dirigés vers une page fournie par l'IDP https://their.samlserver.com . Ils s'authentifient sur cette page et l'IDP fait sa magie pour valider l'authentification et rechercher l'utilisateur. Une fois l'authentification réussie, l'IDP renvoie un <samlp:Response> défini ici .

Encore quelques questions.

Tout d'abord, comment fonctionne le <samlp:Response> revenir à mon application web pour pouvoir la vérifier?

Et que dois-je rechercher dans cette réponse pour valider qu'elle a réussi? À quoi ressemble un échec?

Nous utilisons actuellement l'adresse e-mail (LDAP) pour identifier les utilisateurs, nous allons donc probablement récupérer cela dans la réponse et l'utiliser de la même manière que maintenant. Autre chose que je devrais garder à l'esprit dans cette réponse?

Maintenant que nous avons vérifié la validité de cette réponse, nous pouvons accorder à l'utilisateur une session comme nous le faisons actuellement. Mais quand ils veulent se déconnecter, existe-t-il un flux de travail pour cela? Dois-je informer l'IDP du départ de l'utilisateur?

Et enfin, il y a quelques sujets qui ont été évoqués dans ma lecture et je ne sais pas comment ils s'intègrent dans ce flux de travail. Ce sont Cercle de confiance , Jetons , et Artefacts .

Merci pour toute aide à tous. J'ai trouvé beaucoup d'informations ces derniers jours, et il est possible que je puisse les rassembler après avoir joué un peu plus. Mais je n'ai pas encore trouvé d'article de workflow simple "Voici la publication". C'est peut-être parce que je me trompe sur la façon dont cela fonctionne. C'est peut-être parce que ce n'est pas si populaire. Mais je voulais vraiment m'assurer d'avoir le flux de travail afin de ne pas manquer une étape cruciale dans quelque chose d'aussi important que l'authentification des utilisateurs.

securityauthenticationsaml
78
Staros

En réponse à vos questions spécifiques:

1.) Quelle est la valeur "ID" supposée être?

  • Il doit s'agir d'un identifiant unique pour la demande SAML. La spécification SAML 2.0 indique que la mise en œuvre est vraiment spécifique à l'implémentation, mais formule les recommandations suivantes:

Le mécanisme par lequel une entité système SAML garantit que l'identifiant est unique est laissé à l'implémentation. Dans le cas où une technique aléatoire ou pseudo-aléatoire est utilisée, la probabilité que deux identifiants choisis au hasard soient identiques DOIT être inférieure ou égale à 2 ^ -128 et DEVRAIT être inférieure ou égale à 2 ^ -160 de longueur. Cette exigence PEUT être satisfaite en codant une valeur choisie au hasard entre 128 et 160 bits.

2.) Comment l'IDP vous connaît-il?

  • Votre SP doit être enregistré auprès de l'IdP. Pour ce faire, la spécification SAML définit un format pour les "métadonnées SAML" qui indique à l'IdP où se trouvent vos récepteurs SAML, quels sont vos certificats, attributs vous échangez, etc. OpenAM dicte probablement certaines exigences minimales pour la configuration d'un SP de confiance. Cela varie selon chaque produit.

.) Où est la réponse et que vérifier?

  • La réponse ira à l'URL de votre ACS (Assertion Consumer Service) généralement définie dans les métadonnées SAML que vous échangez à partir de votre SP avec l'IdP pour la configuration initiale. Lorsque vous recevez une réponse SAML, vous devez vérifiez beaucoup de choses - mais surtout, le code d'état SAML doit être "succès", les ID inResponseTo doivent correspondre à ceux envoyés par la demande et vous devez valider la signature numérique sur l'assertion. Pour cela, vous devrez faire confiance au public de l'IdP certificat de vérification, et vous voudrez probablement aussi faire une vérification de révocation.

4.) Qu'en est-il de la déconnexion?

  • SAML 2.0 définit également un profil pour Single LogOut (SLO). Cela vous déconnectera non seulement du SP, mais également de l'IdP et potentiellement de tout autre SP avec lequel vous avez établi une session. Il a un flux de demande/réponse similaire à l'authentification unique (SSO), et donc des choses similaires à configurer et à vérifier (codes d'état, signatures, etc.).

Donc, en bref - cela peut être assez complexe à mettre en œuvre à partir de zéro. Il est préférable d'utiliser des bibliothèques et/ou des produits éprouvés comme le suggère Ian. Des entreprises comme la sienne ont investi des centaines d'heures de développement pour mettre en œuvre conformément aux spécifications et tester l'interopérabilité avec d'autres fournisseurs.

45
Scott T.

Si vous essayez simplement de définir une seule application Java en tant que fournisseur de services, vous devriez envisager d'utiliser un Fedlet depuis Oracle (en tant que autonome) ou - ForgeRock (fourni avec OpenAM). Le Fedlet ForgeRock a quelques problèmes d'interaction avec Shibboleth 2.2.1 en tant que fournisseur d'identité, mais je trouve qu'il est un peu plus simple à configurer et plus informatif.

Chacun contient des instructions explicites contenues dans le README pour vous aider à déployer. Une fois le Fedlet configuré et communiquant avec l'IDP, la page de réussite vous montre tout le code dont vous avez besoin pour intégrer l'authentification unique fédérée dans votre application. Il fait le travail d'arrière-plan de l'envoi et de la réception des demandes et réponses Authn.

La réponse de Scott répond assez bien aux questions que vous vous posiez, mais je pense qu'essayer d'écrire vous-même du code qui génère le SAML réinvente la roue. Le Fedlet a été conçu précisément dans ce cas d'utilisation.

2
user538917