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 refresh_token ni necesita pasar client_secret al extremo de tokens.
El flujo de afirmaciĆ³n del soporte SAML de OAuth 2.0 implica estos pasos.
- 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_idde OAuth) se genera y asigna a la aplicaciĆ³n. - Escriba una aplicaciĆ³n que genere una afirmaciĆ³n SAML y fĆrmela con la clave privada.
- Para implementar el flujo, la aplicaciĆ³n conectada publica la afirmaciĆ³n de soporte SAML en el extremo de tokens de Salesforce.
- 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.
- 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 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 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.
|
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.
- La afirmaciĆ³n debe firmarse segĆŗn la especificaciĆ³n de firma XML, usando RSA y SHA-1 o SHA-256.
- La afirmaciĆ³n SAML debe cumplir las reglas generales de formato especificadas aquĆ: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer.
- Cuando se publica en el extremo del token, la afirmaciĆ³n debe codificarse con codificaciĆ³n base64url como se define aquĆ: http://tools.ietf.org/html/rfc4648#page-7
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.
| 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
|
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.
