Loading
Identification de vos utilisateurs et gestion de l’accès
Flux d'assertion du porteur SAML OAuth 2.0 pour des applications déjà autorisées

Vous êtes ici :

  1. Aide de Salesforce
  2. Documents
  3. Identification de vos utilisateurs et gestion de l’accès

Flux d'assertion du porteur SAML OAuth 2.0 pour des applications déjà autorisées

Avec le flux d'assertion du porteur SAML OAuth 2.0, un client peut utiliser une autorisation antérieure, via une application connectée, en fournissant une assertion SAML 2.0 signée pour demander un jeton d'accès OAuth. La signature numérique appliquée à l'assertion SAML authentifie l'application autorisée. Une assertion SAML est un jeton de sécurité XML émis par un fournisseur d'identité et consommé par un fournisseur de service. Le fournisseur de service s'appuie sur son contexte afin d'identifier l'objet de l'assertion pour des raisons de sécurité.

Éditions requises

Disponible avec : Salesforce Classic et Lightning Experience
Disponible avec : Toutes les éditions

Le flux d'assertion du porteur OAuth 2.0 SAML est similaire à un flux de jeton d'actualisation dans OAuth. L'assertion SAML est publiée au point de terminaison de jeton OAuth, qui traite l'assertion, puis génère un access_token basé sur l'approbation antérieure de l'application. Cependant, il n'est pas nécessaire que le client possède ou stocke un refresh_token, ni transmette un client_secret au point de terminaison de jeton.

Le flux d'assertion du porteur SAML OAuth 2.0 contient les étapes ci-dessous.

  1. Créer une application connectée et enregistrer un certificat X509. Ce certificat correspond à la clé privée de leur application. Lors de l'enregistrement de l'application connectée, une clé consommateur (OAuth client_id) est générée et attribuée à l'application.
  2. Écrire une application qui génère une assertion SAML, puis la signer avec sa clé privée.
  3. Pour implémenter le flux, l'application connectée publie l'assertion du porteur SAML au point de terminaison de jeton Salesforce.
  4. Salesforce valide la signature en utilisant le certificat enregistré pour l'application connectée. Il vérifie également l'audience, l'émetteur, l'objet et la validité de l'assertion.
  5. Si l'assertion est valide et que l'utilisateur ou l'administrateur a déjà autorisé l'application, Salesforce émet un jeton d'accès.
    Remarque
    Remarque Ce flux ne prend pas en charge les jetons d'actualisation.

Création d'une assertion du porteur SAML

Créez une assertion du porteur SAML valide qui inclut les paramètres ci-dessous.

Paramètre Description
Issuer La valeur doit être le client_id OAuth de l'application connectée dont le développeur a enregistré le certificat.
Audience La valeur doit être https://login.salesforce.com ou https://test.salesforce.com.
Recipient

La valeur doit correspondre à l'une des URL ci-dessous.

  • https://<URL_connexion_Mon_Domaine>/services/oauth2/token
  • https://login.salesforce.com/services/oauth2/token
  • https://test.salesforce.com/services/oauth2/token
  • https://<URL_site>/services/oauth2/token

    Vous trouverez votre URL de connexion Mon domaine dans la page de configuration de Mon domaine.

    Si vous implémentez ce flux pour un site Experience Cloud, saisissez l'URL du site, par exemple acme.my.site.com/customers.
Subject NameID La valeur doit être le nom de l'utilisateur de l'utilisateur Salesforce.

L'assertion du porteur SAML doit également respecter les règles ci-dessous.

Voici un exemple d'assertion :

<?xml version="1.0" encoding="UTF-8"?>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_cd3649b3639560458bc9d9b33dfee8d21378409114655" IssueInstant="2013-09-05T19:25:14.654Z" Version="2.0">
  <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">3MVG9PhR6g6B7ps45QoRvhVGGMmR_DT4kxXzVXOo6TTHF3QO1nmqOAstC92 4qSUiUeEDcuGV4tmAxyo_fV8j</saml:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
    <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <ds:Reference URI="#_cd3649b3639560458bc9d9b33dfee8d21378409114655">
      <ds:Transforms>
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
      <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds saml"/>
      </ds:Transform>
      </ds:Transforms>
    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <ds:DigestValue>N8DxylbIeNg8JDO87WIqXGkoIWA=</ds:DigestValue>
    </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>
XV0lFJrkhJykGYQbIs0JBFEHdt4pe2gBgitcXrscNVX2hKGpwQ+WqjF8EKrqV4Q3/Q4KglrXl/6s
xJr6WOmxWtIQC4oWhSvVyfag34zQoecZeunEdFSMlnvPtqBVzJu9hJjy/QDqDWfMeWvF9S50Azd0
EhJxz/Ly1i28o4aCXQQ=
    </ds:SignatureValue>
    <ds:KeyInfo>
    <ds:X509Data>
    <ds:X509Certificate>
MIICOzCCAaSgAwIBAgIGAR7RRteKMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYTAlVTMQswCQYD
VQQIEwJDQTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzENMAsGA1UEChMEUEFDUzENMAsGA1UECxME
U0ZEQzEPMA0GA1UEAxMGU0FNTDIwMB4XDTA5MDExMzE4MzUyN1oXDTE0MDExMTE4MzUyN1owYTEL
MAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMQ0wCwYDVQQK
EwRQQUNTMQ0wCwYDVQQLEwRTRkRDMQ8wDQYDVQQDEwZTQU1MMjAwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAJNGcu8nW6xq2l/dAgbJmSfHLGRn+vCuKWY+LAELw+Kerjaj5Dq3ZGW38HR4BmZk
sG3g4eA1RXn1hiZGI1Q6Ei59QE/OZQx2zVSTb7+oIwRcDHEB1+RraYT3LJuh4JwUDVfEj3WgDnTj
E5vD46l/CR5EXf4VL8uo8T40FkA51AhTAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAehxggY6tBl8x
1SSvCUyUIHvxssAn1AutgZLKWuR1+FXfJzdVdE2F77nrV9YifIERUwhONiS82mBOkKqZZPL1hcKh
KSnFZN2iWmm1sspL73I/eAwVsOUj+bS3v9POo4ceAD/QCCY8gUAInTH0Mq1eOdJMhYKnw/blUyqj
Zn9rajY=
    </ds:X509Certificate>
    </ds:X509Data>
    </ds:KeyInfo>
  </ds:Signature>
<saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">test@example.org</saml:NameID>
  <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml:SubjectConfirmationData NotOnOrAfter="2013-09-05T19:30:14.654Z" Recipient="https://login.salesforce.com/services/oauth2/token"/>
  </saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2013-09-05T19:25:14.654Z" NotOnOrAfter="2013-09-05T19:30:14.654Z" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:AudienceRestriction xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Audience>https://login.salesforce.com/services/oauth2/token</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2013-09-05T19:25:14.655Z" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml:AuthnContext xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
</saml:Assertion>

Demander un jeton d'accès

L'application connectée publie les assertions du porteur SAML au point de terminaison de jeton Salesforce.

Voici un exemple de demande de jeton :

POST /services/oauth2/token HTTP/1.1
Host: login.salesforce.com
Content-Type: application/x-www-form-urlencoded

grant_type= urn:ietf:params:oauth:grant-type:saml2-bearer&
assertion=PHNhbWxwOl...[omitted for brevity]...ZT

Une fois publiés, les paramètres ci-dessous doivent être fournis.

Important
Important Lors du développement d'intégrations OAuth, transmettez toujours des informations confidentielles dans le corps d'une requête POST ou dans un en-tête de requête. N'utilisez pas les paramètres GET dans la chaîne de requête URL pour transmettre des informations confidentielles. Les informations confidentielles comprennent, sans s'y limiter, les noms d'utilisateur, les mots de passe, les jetons OAuth, les secrets clients et toute information d'identification personnelle. Pour plus d'informations sur les meilleures pratiques de sécurité, consultez Stockage des données confidentielles dans le Secure Coding Guide.
Paramètre Description
grant_type Le type d'autorisation d'accès OAuth 2.0 que demande l'application connectée. La valeur doit être urn:ietf:params:oauth:grant-type:saml2-bearer.
assertion L'assertion du porteur SAML, codée en base64url telle que définie si : http://tools.ietf.org/html/rfc4648#page-7.

Vous pouvez également inclure les paramètres standard ci-dessous.

Paramètre Description
format

S'il n'est pas inclus dans l'en-tête de la requête, vous pouvez spécifier le format de retour attendu. Le paramètre format est prioritaire sur l'en-tête l'en-tête de demande. Les formats suivants sont pris en charge :

  • urlencoded
  • json (par défaut)
  • xml
scope Vous ne pouvez pas spécifier d'étendues dans un flux d'assertion du porteur SAML. À la place, la valeur de ce paramètre est la combinaison des étendues émises par les jetons d'accès précédents.

Salesforce accorde un jeton accès

Une fois la demande vérifiée, Salesforce envoie une réponse au client. Les réponses de jeton du flux de jeton du porteur OAuth 2.0 SAML respectent le même format que les flux authorization_code, bien qu'aucun refresh_token d'actualisation refresh_token ne soit émis.

Remarque
Remarque Les requêtes de flux de porteur JWT et de porteur d'assertion SAML OAuth 2.0 examinent toutes les approbations précédentes de l'utilisateur qui contiennent un jeton d'actualisation. Si Salesforce renvoie des approbations correspondantes, les valeurs des étendues approuvées son combinées. Salesforce émet ensuite un jeton d'accès. Si Salesforce ne trouve aucune approbation précédente contenant un jeton d'actualisation ni d'étendues approuvées disponibles, la demande échoue et n'est pas autorisée.

Voir également :

 
Chargement
Salesforce Help | Article