Alternativ för att registrera ett SAML-program i Azure AD B2C
Den här artikeln beskriver de konfigurationsalternativ som är tillgängliga när du ansluter Azure Active Directory B2C (Azure AD B2C) med ditt SAML-program (Security Assertion Markup Language).
Innan du börjar använder du väljaren Välj en principtyp för att välja den typ av princip som du konfigurerar. Azure Active Directory B2C erbjuder två metoder för att definiera hur användare interagerar med dina program: via fördefinierade användarflöden eller genom fullständigt konfigurerbara anpassade principer. De steg som krävs i den här artikeln skiljer sig åt för varje metod.
Den här funktionen är endast tillgänglig för anpassade principer. För installationssteg väljer du Anpassad princip i föregående väljare.
Ange en SAML-svarssignatur
Du kan ange ett certifikat som ska användas för att signera SAML-meddelanden. Meddelandet är elementet <samlp:Response>
i SAML-svaret som skickas till programmet.
Om du inte redan har en principnyckel skapar du en. Konfigurera SamlMessageSigning
sedan metadataobjektet i den tekniska profilen för SAML Token Issuer. StorageReferenceId
måste referera till principnyckelnamnet.
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<!-- SAML Token Issuer technical profile -->
<TechnicalProfile Id="Saml2AssertionIssuer">
<DisplayName>Token Issuer</DisplayName>
<Protocol Name="SAML2"/>
<OutputTokenFormat>SAML2</OutputTokenFormat>
...
<CryptographicKeys>
<Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
...
</CryptographicKeys>
...
</TechnicalProfile>
Signaturalgoritm
Du kan konfigurera signaturalgoritmen som används för att signera SAML-försäkran. Möjliga värden är Sha256
, Sha384
, Sha512
eller Sha1
. Kontrollera att den tekniska profilen och programmet använder samma signaturalgoritm. Använd endast den algoritm som certifikatet stöder.
Konfigurera signaturalgoritmen med hjälp av metadatanyckeln XmlSignatureAlgorithm
i det förlitande partelementet Metadata
.
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="XmlSignatureAlgorithm">Sha256</Item>
</Metadata>
..
</TechnicalProfile>
</RelyingParty>
Kontrollera SAML-försäkransignaturen
När programmet förväntar sig att SAML-kontrollavsnittet ska signeras kontrollerar du att SAML-tjänstleverantören har angett WantAssertionsSigned
till true
. Om den är inställd på false
eller inte finns, signeras inte kontrollavsnittet.
I följande exempel visas metadata för en SAML-tjänstprovider med WantAssertionsSigned
värdet true
.
<EntityDescriptor ID="id123456789" entityID="https://samltestapp2.azurewebsites.net" validUntil="2099-12-31T23:59:59Z" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<SPSSODescriptor WantAssertionsSigned="true" AuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
...
</SPSSODescriptor>
</EntityDescriptor>
Signaturcertifikat
Principen måste ange ett certifikat som ska användas för att signera avsnittet SAML-försäkran i SAML-svaret. Om du inte redan har en principnyckel skapar du en. Konfigurera SamlAssertionSigning
sedan metadataobjektet i den tekniska profilen för SAML Token Issuer. StorageReferenceId
måste referera till principnyckelnamnet.
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<!-- SAML Token Issuer technical profile -->
<TechnicalProfile Id="Saml2AssertionIssuer">
<DisplayName>Token Issuer</DisplayName>
<Protocol Name="SAML2"/>
<OutputTokenFormat>SAML2</OutputTokenFormat>
...
<CryptographicKeys>
<Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
...
</CryptographicKeys>
...
</TechnicalProfile>
Aktivera kryptering i SAML-försäkran
När ditt program förväntar sig att SAML-försäkran ska vara i ett krypterat format kontrollerar du att kryptering är aktiverat i Azure AD B2C-principen.
Azure AD B2C använder tjänstleverantörens offentliga nyckelcertifikat för att kryptera SAML-försäkran. Den offentliga nyckeln måste finnas i SAML-programmets metadataslutpunkt med KeyDescriptor
use
värdet inställt på Encryption
, enligt följande exempel:
<KeyDescriptor use="encryption">
<KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>valid certificate</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
Om du vill göra det möjligt för Azure AD B2C att skicka krypterade intyg anger du WantsEncryptedAssertion
metadataobjektet till true
i den förlitande partens tekniska profil. Du kan också konfigurera algoritmen som används för att kryptera SAML-försäkran.
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="WantsEncryptedAssertions">true</Item>
</Metadata>
..
</TechnicalProfile>
</RelyingParty>
Krypteringsmetod
Om du vill konfigurera krypteringsmetoden som används för att kryptera SAML-kontrolldata anger du metadatanyckeln DataEncryptionMethod
inom den förlitande parten. Möjliga värden är Aes256
(standard), Aes192
, Sha512
, eller Aes128
. Metadata styr värdet för elementet <EncryptedData>
i SAML-svaret.
Om du vill konfigurera krypteringsmetoden för att kryptera kopian av nyckeln som användes för att kryptera SAML-kontrolldata anger du KeyEncryptionMethod
metadatanyckeln inom den förlitande parten. Möjliga värden är:
Rsa15
(standard): algoritmen RSA Public Key Cryptography Standard (PKCS) version 1.5.RsaOaep
: RSA Optimal Asymmetrisk krypteringsutfyllnadsalgoritm (OAEP).
Metadata styr värdet för elementet <EncryptedKey>
i SAML-svaret.
I följande exempel visas avsnittet i EncryptedAssertion
en SAML-försäkran. Den krypterade datametoden är Aes128
, och den krypterade nyckelmetoden är Rsa15
.
<saml:EncryptedAssertion>
<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Type="http://www.w3.org/2001/04/xmlenc#Element">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
<dsig:KeyInfo>
<xenc:EncryptedKey>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<xenc:CipherData>
<xenc:CipherValue>...</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedKey>
</dsig:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>...</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</saml:EncryptedAssertion>
Du kan ändra formatet för de krypterade försäkran. Konfigurera krypteringsformatet genom att ange metadatanyckeln UseDetachedKeys
inom den förlitande parten. Möjliga värden: true
eller false
(standard). När värdet är inställt på true
lägger de frånkopplade nycklarna till den krypterade försäkran som underordnad EncryptedAssertion
i stället för EncryptedData
.
Konfigurera krypteringsmetoden och formatet med hjälp av metadatanycklarna i den förlitande partens tekniska profil:
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="DataEncryptionMethod">Aes128</Item>
<Item Key="KeyEncryptionMethod">Rsa15</Item>
<Item Key="UseDetachedKeys">false</Item>
</Metadata>
..
</TechnicalProfile>
</RelyingParty>
Konfigurera IdP-initierat flöde
När ditt program förväntar sig att få en SAML-försäkran utan att först skicka en SAML AuthN-begäran till identitetsprovidern (IdP) måste du konfigurera Azure AD B2C för IdP-initierat flöde.
I IdP-initierat flöde startar identitetsprovidern (Azure AD B2C) inloggningsprocessen. Identitetsprovidern skickar ett oönskat SAML-svar till tjänstleverantören (ditt förlitande partprogram).
Vi stöder för närvarande inte scenarier där den initierande identitetsprovidern är en extern identitetsprovider federerad med Azure AD B2C, till exempel Active Directory Federation Services (AD FS) eller Salesforce. IdP-initierat flöde stöds endast för lokal kontoautentisering i Azure AD B2C.
Om du vill aktivera IdP-initierat flöde anger du IdpInitiatedProfileEnabled
metadataobjektet till true
i den förlitande partens tekniska profil.
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="IdpInitiatedProfileEnabled">true</Item>
</Metadata>
..
</TechnicalProfile>
</RelyingParty>
Om du vill logga in eller registrera en användare via IdP-initierat flöde använder du följande URL:
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/generic/login?EntityId=<app-identifier-uri>&RelayState=<relay-state>
Ersätt följande värden:
- Ersätt
<tenant-name>
med ditt klientnamn. - Ersätt
<policy-name>
med namnet på din SAML-förlitande partprincip. - Ersätt
<app-identifier-uri>
medidentifierUris
värdet i metadatafilen, till exempelhttps://contoso.onmicrosoft.com/app-name
. - [Valfritt] ersätt
<relay-state>
med ett värde som ingår i auktoriseringsbegäran som också returneras i tokensvaret. Parameternrelay-state
används för att koda information om användarens tillstånd i appen innan autentiseringsbegäran inträffade, till exempel sidan de var på.
Exempel-princip
Du kan använda en fullständig exempelprincip för testning med SAML-testappen:
- Ladda ned den SAML-SP-initierade inloggningsexempelprincipen.
- Uppdatera
TenantId
för att matcha klientorganisationens namn. Den här artikeln använder exemplet contoso.b2clogin.com. - Behåll principnamnet B2C_1A_signup_signin_saml.
Konfigurera livslängden för SAML-svar
Du kan konfigurera hur lång tid SAML-svaret förblir giltigt. Ange livslängden TokenLifeTimeInSeconds
med hjälp av metadataobjektet i den tekniska profilen för SAML Token Issuer. Det här värdet är det antal sekunder som kan förflutit från NotBefore
tidsstämpeln, beräknat vid tokenutfärdingstiden. Standardlivslängden är 300 sekunder (fem minuter).
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="Saml2AssertionIssuer">
<DisplayName>Token Issuer</DisplayName>
<Protocol Name="SAML2"/>
<OutputTokenFormat>SAML2</OutputTokenFormat>
<Metadata>
<Item Key="TokenLifeTimeInSeconds">400</Item>
</Metadata>
...
</TechnicalProfile>
Konfigurera tidsförskjutning för ett SAML-svar
Du kan konfigurera tidsförskjutning som tillämpas på SAML-svarstidsstämpeln NotBefore
. Den här konfigurationen säkerställer att om tiderna mellan två plattformar inte är synkroniserade anses SAML-försäkran fortfarande vara giltig när den är inom den här tiden skev.
Ange tidsförskjutning med hjälp TokenNotBeforeSkewInSeconds
av metadataobjektet i den tekniska profilen för SAML Token Issuer. Snedställningsvärdet anges i sekunder med standardvärdet 0. Det maximala värdet är 3600 (en timme).
Till exempel när TokenNotBeforeSkewInSeconds
är inställt på 120
sekunder:
- Token utfärdas kl. 13:05:10 UTC.
- Token är giltig från 13:03:10 UTC.
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="Saml2AssertionIssuer">
<DisplayName>Token Issuer</DisplayName>
<Protocol Name="SAML2"/>
<OutputTokenFormat>SAML2</OutputTokenFormat>
<Metadata>
<Item Key="TokenNotBeforeSkewInSeconds">120</Item>
</Metadata>
...
</TechnicalProfile>
Ta bort millisekunder från datum och tid
Du kan ange om millisekunder ska tas bort från datum- och tidsvärden i SAML-svaret. (Dessa värden inkluderar IssueInstant
, NotBefore
, NotOnOrAfter
och AuthnInstant
.) Om du vill ta bort millisekunderna anger du metadatanyckeln RemoveMillisecondsFromDateTime
inom den förlitande parten. Möjliga värden: false
(standard) eller true
.
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2" />
<Metadata>
<Item Key="RemoveMillisecondsFromDateTime">true</Item>
</Metadata>
<OutputClaims>
...
</OutputClaims>
<SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true" />
</TechnicalProfile>
</RelyingParty>
Använda ett utfärdar-ID för att åsidosätta en utfärdar-URI
Om du har flera SAML-program som är beroende av olika entityID
värden kan du åsidosätta IssuerUri
värdet i den förlitande partfilen. Om du vill åsidosätta utfärdarens URI kopierar du den tekniska profilen med Saml2AssertionIssuer
ID:t från basfilen och åsidosätter IssuerUri
värdet.
Dricks
<ClaimsProviders>
Kopiera avsnittet från basen och bevara dessa element i anspråksprovidern: <DisplayName>Token Issuer</DisplayName>
, <TechnicalProfile Id="Saml2AssertionIssuer">
och <DisplayName>Token Issuer</DisplayName>
.
Exempel:
<ClaimsProviders>
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="Saml2AssertionIssuer">
<DisplayName>Token Issuer</DisplayName>
<Metadata>
<Item Key="IssuerUri">customURI</Item>
</Metadata>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
</ClaimsProviders>
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpInSAML" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2" />
<Metadata>
…
Hantera en session
Du kan hantera sessionen mellan Azure AD B2C och det SAML-förlitande partprogrammet med hjälp av elementet UseTechnicalProfileForSessionManagement
och SamlSSOSessionProvider.
Tvinga användare att autentisera igen
Om du vill tvinga användare att autentisera igen kan programmet inkludera ForceAuthn
attributet i SAML-autentiseringsbegäran. Attributet ForceAuthn
är ett booleskt värde. När den är inställd true
på kommer användarens session att ogiltigförklaras i Azure AD B2C och användaren tvingas autentisera igen.
Följande SAML-autentiseringsbegäran visar hur du anger ForceAuthn
attributet till true
.
<samlp:AuthnRequest
Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_SAML2_signup_signin/samlp/sso/login"
ForceAuthn="true" ...>
...
</samlp:AuthnRequest>
Signera Azure AD B2C IdP SAML-metadata
Du kan instruera Azure AD B2C att signera dess metadatadokument för SAML-identitetsprovidern om programmet kräver det. Om du inte redan har en principnyckel skapar du en. Konfigurera MetadataSigning
sedan metadataobjektet i den tekniska profilen för SAML Token Issuer. StorageReferenceId
måste referera till principnyckelnamnet.
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<!-- SAML Token Issuer technical profile -->
<TechnicalProfile Id="Saml2AssertionIssuer">
<DisplayName>Token Issuer</DisplayName>
<Protocol Name="SAML2"/>
<OutputTokenFormat>SAML2</OutputTokenFormat>
...
<CryptographicKeys>
<Key Id="MetadataSigning" StorageReferenceId="B2C_1A_SamlMetadataCert"/>
...
</CryptographicKeys>
...
</TechnicalProfile>
Felsöka SAML-protokollet
För att konfigurera och felsöka integreringen med tjänstleverantören kan du använda ett webbläsartillägg för SAML-protokollet. Webbläsartillägg inkluderar SAML DevTools-tillägget för Chrome, SAML-tracer för Firefox och Utvecklarverktyg för Edge eller Internet Explorer.
Genom att använda dessa verktyg kan du kontrollera integreringen mellan ditt program och Azure AD B2C. Till exempel:
- Kontrollera om SAML-begäran innehåller en signatur och avgör vilken algoritm som används för att logga in auktoriseringsbegäran.
- Kontrollera om Azure AD B2C returnerar ett felmeddelande.
- Kontrollera om kontrollavsnittet är krypterat.
Nästa steg
- Mer information om SAML-protokollet finns på OASIS webbplats.
- Hämta SAML-testwebbappen från Azure AD B2C GitHub Community-lagringsplatsen.