Innstillinger for enkeltpålogging med SAML

SAML-sikkerhet

For å forstå hvordan disse SSO-flytene fungerer, er det viktig å forstå hvordan leverandører bruker SAML til å utveksle sikkerhetsinformasjon.

Tips Du finner mer informasjon om SSO-ordforrådet i Terminologi for enkeltpålogging i Salesforce Hjelp.

For begge SAML SSO-flytvariantene godkjenner identitetsleverandøren brukeren – bekrefter at brukeren er den brukeren hevder å være. Når identitetsleverandøren har godkjent brukeren, bruker den et SAML-svar til å fortelle tjenesteleverandøren hvem brukeren er og hva de har tillatelse til å gjøre. Den lagrer informasjon om brukerens identitet i en bestemt del av svaret kalt SAML-deklarasjonen.

For å signalisere at tjenesteleverandøren kan Trust SAML-svaret, signerer identitetsleverandøren svarteksten, deklarasjonen eller begge deler. Om svarteksten eller deklarasjonen er signert, avhenger av identitetsleverandøren.

• Hvis du bruker Salesforce som identitetsleverandør, signerer Salesforce SAML-svarteksten og deklarasjonen.
• Hvis du bruker en tredjeparts identitetsleverandør, kontakter du identitetsleverandøren for å se hvordan de signerer SAML-svar.

Når tjenesteleverandøren mottar SAML-svaret, valideres denne signaturen. Hvordan signaturen valideres avhenger av tjenesteleverandøren.

• Hvis du bruker Salesforce som identitetsleverandør, kontakter du tjenesteleverandøren for å se hvordan de validerer signaturer. I og med at Salesforce signerer svarteksten og deklarasjonen, er den kompatibel med en rekke tjenesteleverandører.
• Hvis du bruker Salesforce som en tjenesteleverandør, kan Salesforce validere signaturer i svarteksten eller deklarasjonen. Salesforce ser først etter en signatur i svarteksten. Hvis svarsignaturen mangler eller er ugyldig, prøver Salesforce deretter å validere signaturen i SAML-deklarasjonen. Selv om en angriper fanger opp SAML-svaret fra brukerens nettleser og manipulerer svarteksten, er ikke SSO-påloggingen i fare så lenge deklarasjonssignaturen er intakt.

  Hvis identitetsleverandøren støtter krypterte SAML-deklarasjoner for ekstra sikkerhet, kan du også konfigurere Salesforce til å dekryptere og validere disse deklarasjonene.

Tjenesteleverandørinitiert SAML-flyt

I en tjenesteleverandørinitiert flyt starter tjenesteleverandøren påloggingsprosessen med en SAML-forespørsel til identitetsleverandøren. Slik fungerer flyten:

1. Brukeren ber om en sikker økt for tilgang til en beskyttet ressurs hos tjenesteleverandøren. Brukeren klikker for eksempel på en lenke for å fylle ut et skjema hos tjenesteleverandøren. Skjemaet er imidlertid en beskyttet ressurs, slik at brukeren først får tilgang til det etter å ha logget seg på.
2. Tjenesteleverandøren initierer pålogging ved å sende en SAML-forespørsel til identitetsleverandøren, der det bes om godkjenning av brukeren.
3. Identitetsleverandøren sender brukeren til en påloggingsside.
4. Brukeren oppgir påloggingslegitimasjonen for identitetsleverandøren og identitetsleverandøren godkjenner brukeren.
5. Nå vet identitetsleverandøren hvem brukeren er og sender et kryptografisk signert SAML-svar til tjenesteleverandøren. SAML-svaret inneholder en SAML-deklarasjon som forteller tjenesteleverandøren hvem brukeren er.
6. Tjenesteleverandøren validerer signaturen i SAML-svaret og identifiserer brukeren.
7. Nå er brukeren logget på hos tjenesteleverandøren og får tilgang til den beskyttede ressursen.

Identitetsleverandørinitiert SAML-flyt

I en identitetsleverandørinitiert påloggingsflyt er det ikke nødvendig med en SAML-forespørsel fordi identitetsleverandøren starter flyten med et SAML-svar. En identitetsleverandørinitiert flyt er en kortere versjon av en tjenesteleverandørinitiert flyt. Slik fungerer flyten:

1. Brukeren logger seg på hos identitetsleverandøren.
2. Brukeren klikker på en knapp eller lenke for å få tilgang til tjenesteleverandøren. Brukeren klikker for eksempel på en app på Appstarter-siden i en Salesforce-organisasjon.
3. Identitetsleverandøren initierer pålogging ved å sende et kryptografisk signert SAML-svar til tjenesteleverandøren. SAML-svaret inneholder en SAML-deklarasjon som forteller tjenesteleverandøren hvem brukeren er.
4. Tjenesteleverandøren validerer signaturen i SAML-svaret og identifiserer brukeren.
5. Nå er brukeren logget på hos tjenesteleverandøren.

Eksempel på SAML-forespørsel og -svar

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

Her er et eksempel på et SAML-svar. I en tjenesteleverandørinitiert flyt sender identitetsleverandøren et SAML-svar etter at tjenesteleverandøren har sendt en SAML-forespørsel. I en identitetsleverandørinitiert flyt starter identitetsleverandøren flyten ved å sende et SAML-svar.

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