Flussi Single Sign-On SAML

Sicurezza SAML

Per capire come funzionano questi flussi SSO, è importante capire in che modo i provider utilizzano SAML per scambiare informazioni di sicurezza.

Suggerimento Per rinfrescare il vocabolario SSO, vedere Terminologia Single Sign-On nella Guida di Salesforce.

Per entrambe le variazioni del flusso SSO SAML, il provider di identità autentica l'utente, confermando che l'utente è chi dichiara di essere. Dopo aver autenticato l'utente, il provider di identità utilizza una risposta SAML per comunicare al fornitore di servizi chi è l'utente e cosa è autorizzato a fare. Memorizza le informazioni sull'identità dell'utente in una parte specifica della risposta denominata asserzione SAML.

Per segnalare che il fornitore di servizi può Trust la risposta SAML, il provider di identità firma il corpo della risposta, l'asserzione o entrambi. La firma del corpo della risposta o dell'asserzione dipende dal provider di identità.

• Se si utilizza Salesforce come provider di identità, Salesforce firma il corpo della risposta SAML e l'asserzione.
• Se si utilizza un provider di identità di terze parti, rivolgersi al provider di identità per vedere come firma le risposte SAML.

Quando il fornitore di servizi riceve la risposta SAML, convalida questa firma. La modalità di convalida della firma dipende dal fornitore di servizi.

• Se si utilizza Salesforce come provider di identità, rivolgersi al fornitore di servizi per vedere come convalida le firme. Poiché Salesforce firma il corpo della risposta e l'asserzione, è compatibile con diversi fornitori di servizi.
• Se si utilizza Salesforce come fornitore di servizi, Salesforce può convalidare le firme nel corpo della risposta o nell'asserzione. Salesforce cerca innanzitutto una firma nel corpo della risposta. Se la firma della risposta è assente o non valida, Salesforce tenta di convalidare la firma nell'asserzione SAML. Anche se un aggressore acquisisce la risposta SAML dal browser dell'utente e altera il corpo della risposta, l'accesso SSO non è a rischio finché la firma dell'asserzione è intatta.

  Se il provider di identità supporta le asserzioni SAML crittografate per una maggiore sicurezza, è anche possibile configurare Salesforce per decrittografare e convalidare queste asserzioni.

Flusso SAML avviato dal fornitore di servizi

In un flusso avviato dal fornitore di servizi, quest'ultimo avvia la procedura di accesso inviando una richiesta SAML al provider di identità. Il flusso funziona nel modo seguente.

1. L'utente richiede una sessione protetta per accedere una risorsa protetta del fornitore di servizi. Ad esempio, l'utente fa clic su un link per compilare un modulo del fornitore di servizi. Essendo il modulo una risorsa protetta, tuttavia, l'utente può accedervi solo dopo avere eseguito l'accesso.
2. Il fornitore di servizi avvia l'accesso inviando una richiesta SAML al provider di identità e chiedendo di autenticare l'utente.
3. Il provider di identità invia l'utente a una pagina di accesso.
4. L'utente inserisce le credenziali di accesso del suo provider di identità e il provider di identità lo autentica.
5. Ora il provider di identità sa chi è l'utente, e quindi invia una risposta SAML con firma crittografata al fornitore di servizi. La risposta SAML contiene un'asserzione SAML che comunica al fornitore di servizi l'identità dell'utente.
6. Il fornitore di servizi convalida la firma della risposta SAML e identifica l'utente.
7. A questo punto l'utente è connesso al fornitore di servizi e può accedere alla risorsa protetta.

Flusso SAML avviato dal provider di identità

In un flusso di accesso avviato da un provider di identità non serve la richiesta SAML, perché il provider di identità avvia il flusso con una risposta SAML. Il flusso avviato dal provider di identità è una versione abbreviata del flusso avviato dal fornitore di servizi. Il flusso funziona nel modo seguente.

1. L'utente accede al provider di identità.
2. L'utente fa clic su un pulsante o un link per accedere al fornitore di servizi, ad esempio fa clic su un'app nella pagina Programma di avvio app in un'organizzazione Salesforce.
3. Il provider di identità avvia la procedura di accesso inviando una risposta SAML con firma crittografata al fornitore di servizi. La risposta SAML contiene un'asserzione SAML che comunica al fornitore di servizi l'identità dell'utente.
4. Il fornitore di servizi convalida la firma della risposta SAML e identifica l'utente.
5. Ora l'utente è connesso al fornitore di servizi.

Esempio di richiesta e di risposta SAML

<samlp:AuthnRequest ID="bndkmeemcaamihajeloilkagfdliilbhjjnmlmfo" Version="2.0" 
   IssueInstant="2010-05-24T22:57:19Z" 
   ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
   ProviderName="google.com" IsPassive="false" 
   AssertionConsumerServiceURL="https://www.google.com/a/resp.info/acs">
   <saml:Issuer>google.com</saml:Issuer>
   <samlp:NameIDPolicy AllowCreate="true" 
   Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
</samlp:AuthnRequest>

Ecco un esempio di risposta SAML. In un flusso avviato dal fornitore di servizi, il provider di identità invia una risposta SAML dopo che il fornitore di servizi ha inviato una richiesta SAML. In un flusso avviato dal provider di identità, quest'ultimo avvia il flusso inviando una risposta SAML.

<samlp:Response Destination="https://MyDomainName.my.salesforce.com?so=00Dx00000000001"
  ID="_0f551f9288c8b76f21c3d4d15c9cd1df1290476801091"
  InResponseTo="_2INwHuINDJTvjo8ohcM.Fpw_uLukYi0WArVx2IJD569kZYL
    osBwuiaSbzzxOPQjDtfw52tJB10VfgPW2p5g7Nlv5k1QDzR0EJYGgn0d0z8
    CIiUOY31YBdk7gwEkTygiK_lb46IO1fzBFoaRTzwvf1JN4qnkGttw3J6L4b
    opRI8hSQmCumM_Cvn3DHZVN.KtrzzOAflcMFSCY.bj1wvruSGQCooTRSSQ"
  IssueInstant="2010-11-23T01:46:41.091Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
>https://myidp.my.salesforce.com</saml:Issuer>
−
<ds:Signature>
−
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
−
<ds:Reference URI="#_0f551f9288c8b76f21c3d4d15c9cd1df1290476801091">
−
<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 PrefixList="ds saml samlp xs"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>4NVTbQ2WavD+ZBiyQ7ufc8EhtZw=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
−
<ds:SignatureValue>

ExampleSamlSignature</ds:SignatureValue>
−
<ds:KeyInfo>
−
<ds:X509Data>
−
<ds:X509Certificate>ExampleX509 Certificate</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
−
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
−
<saml:Assertion ID="_e700bf9b25a5aebdb9495fe40332ef081290476801092" IssueInstant="2010-11-23T01:46:41.092Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://exampleidp.com</saml:Issuer>
−
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">exampleuser@salesforce.com</saml:NameID>
−
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2010-11-23T01:51:41.093Z" Recipient="https://MyDomainName.my.salesforce.com?so=00Dx00000000001"/>
</saml:SubjectConfirmation>
</saml:Subject>
−
<saml:Conditions NotBefore="2010-11-23T01:46:41.093Z" NotOnOrAfter="2010-11-23T01:51:41.093Z">
−
<saml:AudienceRestriction>
<saml:Audience>https://exampleserviceprovider.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
−
<saml:AuthnStatement AuthnInstant="2010-11-23T01:46:41.092Z">
−
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
−
<saml:AttributeStatement>
−
<saml:Attribute Name="userId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">005D0000001Ayzh</saml:AttributeValue>
</saml:Attribute>
−
<saml:Attribute Name="username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">admin@identity.org</saml:AttributeValue>
</saml:Attribute>
−
<saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">exampleuser@salesforce.com</saml:AttributeValue>
</saml:Attribute>
−
<saml:Attribute Name="is_portal_user" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">false</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>