Loading
Identificar sus usuarios y gestionar el acceso
Flujo de afirmaciĆ³n de soporte SAML de OAuth 2.0 para aplicaciones autorizadas previamente

Usted estĆ” aquĆ­:

  1. Ayuda de Salesforce
  2. Documentos
  3. Identificar sus usuarios y gestionar el acceso

Flujo de afirmaciĆ³n de soporte SAML de OAuth 2.0 para aplicaciones autorizadas previamente

Con el flujo de afirmaciĆ³n de soporte SAML de OAuth 2.0, un cliente (a travĆ©s de una aplicaciĆ³n conectada) puede utilizar autorizaciĆ³n previa suministrando una afirmaciĆ³n SAML 2.0 firmada para solicitar un token de acceso OAuth. La firma digital aplicada a la afirmaciĆ³n SAML autentica la aplicaciĆ³n autorizada. Una afirmaciĆ³n de SAML es un token de seguridad XML emitido por un proveedor de identidad y consumido por un proveedor de servicio. El proveedor de servicio se basa en su contenido para identificar al asunto de la afirmaciĆ³n para fines relacionados con la seguridad.

Ediciones necesarias

Disponible en: Salesforce Classic y Lightning Experience
Disponible en: Todas las ediciones

El flujo de afirmaciĆ³n de soporte SAML de OAuth 2.0 es similar al flujo de un token de actualizaciĆ³n dentro de OAuth. La afirmaciĆ³n SAML se publica en el extremo del token de OAuth, que a su vez procesa la afirmaciĆ³n y emite un access_token basĆ”ndose en la aprobaciĆ³n anterior de la aplicaciĆ³n. Sin embargo, el cliente no necesita tener o almacenar un refresh_token ni necesita pasar un client_secret al extremo de tokens.

El flujo de afirmaciĆ³n del soporte SAML de OAuth 2.0 implica estos pasos.

  1. Cree una aplicaciĆ³n conectada y registre un certificado X509. Este certificado se corresponde con la clave privada de la aplicaciĆ³n. Cuando se guarda la aplicaciĆ³n conectada, la clave del consumidor (client_id de OAuth) se genera y asigna a la aplicaciĆ³n.
  2. Escriba una aplicaciĆ³n que genere una afirmaciĆ³n SAML y fĆ­rmela con la clave privada.
  3. Para implementar el flujo, la aplicaciĆ³n conectada publica la afirmaciĆ³n de soporte SAML en el extremo de tokens de Salesforce.
  4. Salesforce valida la firma utilizando el certificado registrado para la aplicaciĆ³n conectada. AdemĆ”s, valida la audiencia, el emisor, el asunto y la validez de la afirmaciĆ³n.
  5. Suponiendo que la afirmaciĆ³n es vĆ”lida y que el usuario o administrador autorizĆ³ la aplicaciĆ³n anteriormente, Salesforce emite un token de acceso.
    Nota
    Nota Este flujo no admite tokens de actualizaciĆ³n.

Crear una afirmaciĆ³n de soporte SAML

Cree una afirmaciĆ³n de soporte SAML vĆ”lida que incluya estos parĆ”metros.

ParĆ”metro DescripciĆ³n
Issuer El valor debe ser el client_id OAuth de la aplicaciĆ³n conectada para la que el desarrollador registrĆ³ su certificado.
Audience El valor debe ser https://login.salesforce.com o https://test.salesforce.com.
Recipient

El valor debe ser una de estas URL.

  • https://<URL_Inicio_SesiĆ³n_Mi_Dominio>/services/oauth2/token
  • https://login.salesforce.com/services/oauth2/token
  • https://test.salesforce.com/services/oauth2/token
  • https://<site_URL>/services/oauth2/token

    PodrĆ” encontrar su URL de inicio de sesiĆ³n de Mi dominio en la pĆ”gina ConfiguraciĆ³n de Mi dominio.

    Si estĆ” implementando este flujo para un sitio de Experience Cloud, introduzca la URL del sitio, como acme.my.site.com/customers.
Subject NameID Este valor debe ser el nombre de usuario del usuario de Salesforce.

La afirmaciĆ³n de soporte SAML debe ajustarse tambiĆ©n a estas reglas.

A continuaciĆ³n se incluye una afirmaciĆ³n de muestra.

<?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>

Solicitar un token de acceso

La aplicaciĆ³n conectada publica afirmaciones de soporte SAML en el extremo de tokens de Salesforce.

A continuaciĆ³n se incluye una solicitud de token de muestra.

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

Cuando se publique, deberƔn proporcionarse estos parƔmetros.

Importante
Importante Cuando desarrolle integraciones de OAuth, pase siempre informaciĆ³n confidencial en el cuerpo de una solicitud POST o en un encabezado de solicitud. No utilice parĆ”metros GET en la cadena de consulta de URL para pasar informaciĆ³n confidencial. La informaciĆ³n confidencial incluye, entre otros, nombres de usuario, contraseƱas, tokens de OAuth, secretos de cliente y cualquier informaciĆ³n de identificaciĆ³n personal. Para obtener mĆ”s informaciĆ³n sobre las prĆ”cticas recomendadas de seguridad, consulte Almacenamiento de datos confidenciales en la GuĆ­a de codificaciĆ³n segura.
ParĆ”metro DescripciĆ³n
grant_type El tipo de otorgamiento de OAuth 2.0 que solicita la aplicaciĆ³n conectada. El valor debe ser urn:ietf:params:oauth:grant-type:saml2-bearer
assertion La afirmaciĆ³n de soporte SAML, con codificaciĆ³n base64url como se define aquĆ­: http://tools.ietf.org/html/rfc4648#page-7.

TambiƩn puede incluir estos parƔmetros estƔndar.

ParĆ”metro DescripciĆ³n
format

Si no se incluye en el encabezado de la solicitud, puede especificar el formato de devoluciĆ³n esperado. El parĆ”metro format tiene preferencia sobre el encabezado de la solicitud. Se admiten estos formatos.

  • urlencoded
  • json predeterminados
  • xml
scope No puede especificar Ć”mbitos en un flujo de afirmaciĆ³n de soporte SAML. En su lugar, el valor de este parĆ”metro es la combinaciĆ³n de los Ć”mbitos emitidos de tokens de acceso anteriores.

Salesforce otorga un token de acceso

DespuĆ©s de verificar la solicitud, Salesforce envĆ­a una respuesta al cliente. Las respuestas para los tokens del flujo del token de soporte SAML de OAuth 2.0 siguen el mismo formato que los flujos authorization_code, aunque nunca se emite ningĆŗn refresh_token.

Nota
Nota Las solicitud de flujo de soporte de afirmaciĆ³n de SAML y de soporte JWT de OAuth 2.0 comprueban todas las aprobaciones anteriores para el usuario que incluyan un token de actualizaciĆ³n. Si Salesforce encuentra aprobaciones coincidentes, combina los valores de los Ć”mbitos aprobados. Salesforce emite a continuaciĆ³n un token de acceso. Si Salesforce no encuentra aprobaciones previas que incluĆ­an un token de actualizaciĆ³n o ningĆŗn Ć”mbito aprobado disponible, la solicitud falla como no autorizada.

Consulte tambiƩn:

 
Cargando
Salesforce Help | Article