web-dev-qa-db-fra.com

SAML 2.0: Comment configurer l'URL du service consommateur d'assertion

J'implémente un fournisseur de services SAML 2.0 utilisant Okta comme fournisseur d'identité. Je souhaite configurer l'URL du service consommateur d'assertion (ACS) afin que le SAML 2.0 de l'application du fournisseur de services soit reflété dans l'assertion.

Cependant, je remarque que le fournisseur d’identité Okta envoie à la place le noeud final SSO configuré dans la configuration d’Okta et ignore l’ACS effectivement envoyé. De plus, j'obtiens une erreur. Peut-être que l'ACS de SP ne correspond pas aux méta-données.

Si l'URL ACS n'est pas le bon moyen d'envoyer un ID court à IDP afin qu'il soit reflété dans l'assertion, quel autre mécanisme peut être utilisé à cette fin.

Exemple:

Le SAML 2.0 de SAML 2.0 envoyé par l'application SP est:

assertion_consumer_service_url: https: //Host.com:port/saml/consume? entityId = N & myName = nom d'utilisateur

La configuration sur le fournisseur d'identité a les méta-données:

URL de connexion unique: Https: //Host.com:port/saml/consume?entityId=N

Notez que le nom myName change d’une requête à l’autre, car c’est notre façon de vérifier que la réponse a name_id qui correspond au nom d’utilisateur original envoyé.

De plus, s’il existe un moyen pour le fournisseur de services de laisser le fournisseur d’identité affirmer qu’un nom géré par le fournisseur de service (tel que le nom d’utilisateur), nous répondrons à nos besoins. Comment on spécifie cela?

Merci

single-sign-onsaml
15
Venkat Rangan

Dans SAML, l'ACS est supposé statique pour un SP. Pour corréler la réponse avec l'AuthnRequest d'origine, sauvegardez l'ID de l'AuthnRequest sortant, puis utilisez la variable InResponseTo de la réponse reçue.

Le SP peut ajouter un objet à AuthnRequest, en indiquant au fournisseur d'identité le nom d'utilisateur que vous souhaitez authentifier. Il est défini à la section 3.4.1 du SAML2 Core spec .

11
Anders Abel

Comme Anders Abel l'a souligné, l'ACS est supposé statique. Toutefois, dans un environnement de développement, il se peut qu’une réponse plus dynamique à différents systèmes de test soit nécessaire. 

C'est mon saml20-sp-remote.php que j'utilise pour répondre à chaque SP qui demande une authentification SSO, en utilisant l'attribut AssertionConsumerService de ses demandes. Je suppose que ce n’est pas sans danger pour la production. 

simplesamlphp/metadata/saml20-sp-remote.php:

<?php
/**
 * SAML 2.0 remote SP metadata for SimpleSAMLphp.
 *
 * See: https://simplesamlphp.org/docs/stable/simplesamlphp-reference-sp-remote
 */
$acs = \SAML2\Binding::getCurrentBinding()->receive()->getAssertionConsumerServiceURL();
if (!$acs) $acs = 'some_fallback_url';

$metadata['idp_identifier'] = array(
    'AssertionConsumerService' => $acs,
    'simplesaml.nameidattribute' => 'uid'
);
0
Rokus