J'ai le plugin SAML de OneLogin en Java. Lors de la tentative de traitement de la réponse de connexion, l'API requiert les mêmes paramètres que ceux utilisés lors de la demande de connexion. Cependant, plusieurs instances de mon serveur Web sont en cours d'exécution, la réponse peut donc être envoyée sur un serveur différent de celui de la demande. Si la réponse n'est pas chiffrée, je peux utiliser l'attribut InResponseTo pour suivre les paramètres entre les instances du serveur Web. Mais si la réponse est cryptée, il n'y a aucun moyen pour moi de suivre les paramètres.
Auth auth = new Auth(settings, request, response);
// This settings object is needed to decrypt the response
auth.processResponse();
if (!auth.isAuthenticated()) {
out.println("Not authenticated");
}
Comment est-il possible d'identifier la configuration du fournisseur d'identité à la réception de la réponse? Toute aide serait appréciée.
InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"
3 Réponses :
Si toute la réponse SAML est chiffrée, il n'y a aucun moyen de trouver l'émetteur. Sinon, l'élément 'Issuer' de la réponse SAML vous indiquera l'ID d'entité de l'IdP SAML.
Dans le cas où un fournisseur de services contacte plusieurs fournisseurs d'identité, comment le fournisseur de services saura-t-il quel fournisseur d'identité a envoyé la réponse si la réponse entière est chiffrée?
Pas du tout, mais du point de vue SAML, il n'a pas à s'en soucier car il a une confiance avec tous ces IdP. Peu importe quel IdP a envoyé l'assertion sur le sujet authentifié.
Convenu. Mais différents fournisseurs d'identité ont des clés de chiffrement différentes. Alors, comment le SP saura-t-il avec quelle clé déchiffrer à moins qu'il ne sache quel IdP a envoyé la réponse?
En fait, la "réponse SAML entière" n'est pas chiffrée. Sur l'assertion ou / et le NameID et les attributs sont chiffrés. Veuillez vérifier les XSD SAML.
J'ai essayé les outils de développement en ligne de OneLogin. Si vous leur fournissez une réponse SAML et une clé, ils chiffrent l'intégralité de la réponse. Si la réponse n'est pas entièrement chiffrée et que je suis capable d'obtenir l'ID d'entité ou l'attribut InResponseTo, cela résoudrait mon problème.
Il s'agit alors d'une fonctionnalité propriétaire de OneLogin, qui n'est pas conforme à la spécification SAML. Potentiellement, vous l'avez mal fait. Comme vous pouvez le voir sur developer.onelogin.com/saml/examples/response , il y a seulement une assertion chiffrée. En plus de cela, il est également possible de chiffrer les attributs et / ou le NameID au lieu de l'assertion entière.
Après avoir parcouru plusieurs forums, je suis d'accord avec vous. L'outil de chiffrement en ligne fourni par OneLogin n'est qu'un outil de chiffrement générique. Selon le schéma Saml, Issuer, EntityID et InResponseTo ne seront pas chiffrés afin de pouvoir être utilisés pour déchiffrer la réponse.
Si je comprends bien, lors du traitement de la réponse, vous devez être en mesure d'identifier l'origine de la demande?
Je pense que vous devriez pouvoir le faire avec RelayState. Dans leurs documents (à https://github.com/onelogin/java-saml ), ils comment la méthode login () peut prendre les informations RelayState:
Nous pouvons définir un paramètre d'url 'returnTo' pour la fonction de connexion et qui sera converti en paramètre 'RelayState'
String relayState = request.getParameter("RelayState");
//do whatever you want based on this request parameter
L'appel du paramètre returnTo est trompeur à mon avis car cela implique un comportement qui n'existe pas. Il aurait dû s'appeler "relayState".
Quand cela revient dans la réponse, c'est juste un paramètre de requête supplémentaire. Dans la documentation, ils montrent un exemple d'utilisation de la valeur RelayState pour acheminer la réponse, mais vous pouvez faire tout ce que vous voulez avec ces informations:
String targetUrl = 'https://example.com'; auth.login(returnTo=targetUrl)
Pas exactement. Le problème est que la réponse peut être retournée par n'importe quel IDP. Et chaque IDP a des clés de cryptage et de signature différentes. Je ne pourrai obtenir les détails de la réponse, y compris l'état du relais, que si je déchiffre le message avec la bonne clé. Et j'ai besoin de trouver un moyen de suivre à quel IDP la demande va sans l'utilisation de session.
Ah ok, oui. Je vois le problème. Désolé info incorrecte alors!
Question : Si la réponse n'est pas chiffrée, je peux utiliser l'attribut InResponseTo pour suivre les paramètres entre les instances du serveur Web.
Mais si la réponse est chiffrée, je n'ai aucun moyen de suivre les paramètres.
Comment est-il possible d'identifier la configuration du fournisseur d'identité à la réception de la réponse?
Et j'ai besoin de trouver un moyen de savoir à quel IDP la demande va sans l'utilisation de session.
Réponse :
(1) Chaque IdP doit publier la réponse SAML au point de terminaison AttributeConsumingService tel que https : //sp.example.org/Shibboleth.sso/SAML2/POST
(2) Un IdP différent doit avoir un ID d'entité différent.
(3) SAML 2 prend en charge le chiffrement des assertions, des NameID et des attributs.
(4) Citation "Comment est-il possible d'identifier la configuration du fournisseur d'identité à la réception de la réponse?"
Le fait que l'IdP crypte les assertions, les NameID ou / et les attributs est déterminé par SP. Diffferent SAML SP peut avoir des exigences différentes, telles que l'assertion de signe ou la réponse de signe ou crypter les assertions, les NameID ou / et les attributs.
L'IdP SAML doit fournir la configuration correspondante pour répondre aux exigences de SAML SP. La configuration de la partie de confiance / SP de l'IdP Shibboleth dans le référentiel GitHub fournit un exemple de configuration pour les SP SAML sélectionnés.
Le SP utilise l'ID d'entité de l'IdP pour identifier la configuration du fournisseur d'identité à la réception de la réponse si le SP a des exigences différentes pour différents IdP.
(5) Plusieurs IdP peuvent envoyer la réponse au même ACS. Habituellement, à chaque connexion du SP, un seul IdP envoie la réponse SAML à l'ACS. Ensuite, SP utilise sa propre clé privée pour déchiffrer les assertions, les NameID ou les attributs.
Résolution (certains SP SAML commerciaux adoptent cette solution):
Créez différents points de terminaison AttributeConsumingService pour différents IdP, c'est-à-dire
https://your-sp.com/SAML2/POST/idp1
https://your-sp.com/SAML2/POST/idp2
https://your-sp.com/SAML2/POST/idp3
Ensuite, différents IdP publient la réponse SAML à différents points de terminaison AttributeConsumingService.
Le SP utilise sa propre clé privée / certificat pour déchiffrer les assertions, les NameID ou les attributs, puis suit à quel IDP la demande va sans utiliser de session.
Notez que SP doit fournir différentes métadonnées SP avec différentes URL ACS à différents IdP.
Il existe des cas où plusieurs IdP peuvent envoyer la réponse au même ACS. L'ACS a juste besoin de savoir quel Idp l'a envoyé. Cela peut être fait à partir des attributs InResponseTo ou Entity ID. Ils ne sont jamais chiffrés. Seuls les assertions, le NameID et les attributs peuvent être chiffrés.
Plusieurs IdP peuvent envoyer la réponse au même ACS. Habituellement, à chaque fois que le SP se connecte, un seul IdP envoie la réponse SAML à l'ACS. Ensuite, SP utilise sa propre clé privée pour déchiffrer les assertions, les NameID ou les attributs. J'ai mis à jour ma réponse.