Dela via


Lägga till AD FS som en SAML-identitetsprovider med anpassade principer i Azure Active Directory B2C

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.

Kommentar

I Azure Active Directory B2C är anpassade principer främst utformade för att hantera komplexa scenarier. I de flesta scenarier rekommenderar vi att du använder inbyggda användarflöden. Om du inte har gjort det kan du läsa mer om startpaketet för anpassad princip i Kom igång med anpassade principer i Active Directory B2C.

Den här artikeln visar hur du aktiverar inloggning för ett AD FS-användarkonto med hjälp av anpassade principer i Azure Active Directory B2C (Azure AD B2C). Du aktiverar inloggning genom att lägga till en SAML-identitetsprovider i en anpassad princip.

Förutsättningar

Skapa ett självsignerat certifikat

Om du inte redan har ett certifikat kan du använda ett självsignerat certifikat. Ett självsignerat certifikat är ett säkerhetscertifikat som inte är signerat av en certifikatutfärdare (CA) och som inte tillhandahåller säkerhetsgarantierna för ett certifikat som signerats av en certifikatutfärdare.

I Windows använder du cmdleten New-SelfSignedCertificate i PowerShell för att generera ett certifikat.

  1. Kör följande PowerShell-kommando för att generera ett självsignerat certifikat. -Subject Ändra argumentet efter behov för ditt program och Azure AD B2C-klientnamn, till exempel contosowebapp.contoso.onmicrosoft.com. Du kan också justera -NotAfter datumet för att ange ett annat förfallodatum för certifikatet.

    New-SelfSignedCertificate `
        -KeyExportPolicy Exportable `
        -Subject "CN=yourappname.yourtenant.onmicrosoft.com" `
        -KeyAlgorithm RSA `
        -KeyLength 2048 `
        -KeyUsage DigitalSignature `
        -NotAfter (Get-Date).AddMonths(12) `
        -CertStoreLocation "Cert:\CurrentUser\My"
    
  2. På Windows-datorn söker du efter och väljer Hantera användarcertifikat

  3. Under Certifikat – aktuell användare väljer du Personliga>certifikat>yourappname.yourtenant.onmicrosoft.com.

  4. Välj certifikatet och välj sedan Åtgärd>alla uppgifter>Exportera.

  5. Välj Nästa>Ja, exportera den privata nyckeln>Nästa.

  6. Acceptera standardinställningarna för Exportera filformat och välj sedan Nästa.

  7. Aktivera alternativet Lösenord , ange ett lösenord för certifikatet och välj sedan Nästa.

  8. Om du vill ange en plats för att spara certifikatet väljer du Bläddra och navigerar till valfri katalog.

  9. I fönstret Spara som anger du ett filnamn och väljer sedan Spara.

  10. Välj Nästa>Slutför.

För att Azure AD B2C ska acceptera .pfx-fillösenordet måste lösenordet krypteras med alternativet TripleDES-SHA1 i exportverktyget för Windows Certificate Store, till skillnad från AES256-SHA256.

Skapa en principnyckel

Du måste lagra certifikatet i din Azure AD B2C-klientorganisation.

  1. Logga in på Azure-portalen.
  2. Om du har åtkomst till flera klienter väljer du ikonen Inställningar på den översta menyn för att växla till din Azure AD B2C-klient från menyn Kataloger + prenumerationer.
  3. Välj Alla tjänster på menyn högst upp till vänster i Azure-portalen och sök efter och välj Azure AD B2C.
  4. På sidan Översikt väljer du Identity Experience Framework.
  5. Välj Principnycklar och välj sedan Lägg till.
  6. För Alternativ väljer du Upload.
  7. Ange ett Namn för principnyckeln. Exempel: SAMLSigningCert Prefixet B2C_1A_ läggs automatiskt till i namnet på din nyckel.
  8. Bläddra till och välj din .pfx-certifikatfil med den privata nyckeln.
  9. Klicka på Skapa.

Lägga till en anspråksprovider

Om du vill att användarna ska logga in med ett AD FS-konto måste du definiera kontot som en anspråksprovider som Azure AD B2C kan kommunicera med via en slutpunkt. Slutpunkten innehåller en uppsättning anspråk som används av Azure AD B2C för att verifiera att en viss användare har autentiserats.

Du kan definiera ett AD FS-konto som en anspråksprovider genom att lägga till det i elementet ClaimsProviders i tilläggsfilen för principen. Mer information finns i definiera en SAML-identitetsprovider.

  1. Öppna TrustFrameworkExtensions.xml.

  2. Hitta elementet ClaimsProviders . Om den inte finns lägger du till den under rotelementet.

  3. Lägg till en ny ClaimsProvider på följande sätt:

    <ClaimsProvider>
      <Domain>contoso.com</Domain>
      <DisplayName>Contoso</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Contoso-SAML2">
          <DisplayName>Contoso</DisplayName>
          <Description>Login with your AD FS account</Description>
          <Protocol Name="SAML2"/>
          <Metadata>
            <Item Key="WantsEncryptedAssertions">false</Item>
            <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SAMLSigningCert"/>
          </CryptographicKeys>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name"/>
            <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name"/>
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email"/>
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name"/>
            <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication"/>
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-idp"/>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    
  4. Ersätt your-AD-FS-domain med namnet på din AD FS-domän och ersätt värdet för utdataanspråket identityProvider med din DNS (godtyckligt värde som anger din domän).

  5. Leta upp avsnittet <ClaimsProviders> och lägg till följande XML-kodfragment. Om principen redan innehåller den SM-Saml-idp tekniska profilen går du vidare till nästa steg. Mer information finns i Sessionshantering för enkel inloggning.

    <ClaimsProvider>
      <DisplayName>Session Management</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="SM-Saml-idp">
          <DisplayName>Session Management Provider</DisplayName>
          <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
          <Metadata>
            <Item Key="IncludeSessionIndex">false</Item>
            <Item Key="RegisterServiceProviders">false</Item>
          </Metadata>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    
  6. Spara filen.

Lägga till en användarresa

I det här läget har identitetsprovidern konfigurerats, men den är ännu inte tillgänglig på någon av inloggningssidorna. Om du inte har en egen anpassad användarresa skapar du en dubblett av en befintlig mallanvändarresa, annars fortsätter du till nästa steg.

  1. Öppna filen TrustFrameworkBase.xml från startpaketet.
  2. Hitta och kopiera hela innehållet i elementet UserJourney som innehåller Id="SignUpOrSignIn".
  3. Öppna TrustFrameworkExtensions.xml och leta upp elementet UserJourneys. Om elementet inte finns lägger du till ett.
  4. Klistra in hela innehållet i elementet UserJourney som du kopierade som underordnat elementet UserJourneys .
  5. Byt namn på ID:t för användarresan. Exempel: Id="CustomSignUpSignIn"

Lägga till identitetsprovidern i en användarresa

Nu när du har en användarresa lägger du till den nya identitetsprovidern i användarresan. Du lägger först till en inloggningsknapp och länkar sedan knappen till en åtgärd. Åtgärden är den tekniska profil som du skapade tidigare.

  1. Leta reda på orkestreringsstegelementet som innehåller Type="CombinedSignInAndSignUp", eller Type="ClaimsProviderSelection" i användarresan. Det är vanligtvis det första orkestreringssteget. Elementet ClaimsProviderSelections innehåller en lista över identitetsprovidrar som en användare kan logga in med. Ordningen på elementen styr ordningen på de inloggningsknappar som visas för användaren. Lägg till ett ClaimsProviderSelection XML-element. Ange värdet för TargetClaimsExchangeId till ett eget namn.

  2. I nästa orkestreringssteg lägger du till ett ClaimsExchange-element . Ange ID:t till värdet för målanspråkets utbytes-ID. Uppdatera värdet för TechnicalProfileReferenceId till ID:t för den tekniska profil som du skapade tidigare.

Följande XML visar de två första orkestreringsstegen för en användarresa med identitetsprovidern:

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    ...
    <ClaimsProviderSelection TargetClaimsExchangeId="ContosoExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="ContosoExchange" TechnicalProfileReferenceId="Contoso-SAML2" />
  </ClaimsExchanges>
</OrchestrationStep>

Konfigurera principen för förlitande part

Principen för förlitande part, till exempel SignUpSignIn.xml, anger den användarresa som Azure AD B2C ska köra. Hitta elementet DefaultUserJourney i den förlitande parten. Uppdatera ReferenceId så att det matchar användarens rese-ID, där du lade till identitetsprovidern.

I följande exempel CustomSignUpSignIn för användarresan är ReferenceId inställt på CustomSignUpSignIn:

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  ...
</RelyingParty>

Ladda upp den anpassade principen

  1. Logga in på Azure-portalen.
  2. Välj ikonen Katalog + prenumeration i portalens verktygsfält och välj sedan den katalog som innehåller din Azure AD B2C-klientorganisation.
  3. I Azure-portalen söker du efter och väljer Azure AD B2C.
  4. Under Principer väljer du Identity Experience Framework.
  5. Välj Överför anpassad princip och ladda sedan upp de två principfilerna som du ändrade i följande ordning: tilläggsprincipen, till exempel TrustFrameworkExtensions.xml, och sedan den förlitande partprincipen, till exempel SignUpSignIn.xml.

Konfigurera ett AD FS-förlitande partförtroende

Om du vill använda AD FS som identitetsprovider i Azure AD B2C måste du skapa ett AD FS-förlitande partförtroende med Azure AD B2C SAML-metadata. I följande exempel visas en URL-adress till SAML-metadata för en teknisk Azure AD B2C-profil:

https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/your-policy/samlp/metadata?idptp=your-technical-profile

Använd följande format när du använder en anpassad domän:

https://your-domain-name/your-tenant-name.onmicrosoft.com/your-policy/samlp/metadata?idptp=your-technical-profile

Ersätt följande värden:

  • ditt klientnamn med ditt klientnamn, till exempel your-tenant.onmicrosoft.com.
  • ditt domännamn med ditt anpassade domännamn, till exempel login.contoso.com.
  • din-princip med ditt principnamn. Till exempel B2C_1A_signup_signin_adfs.
  • din tekniska profil med namnet på din tekniska profil för SAML-identitetsprovidern. Till exempel Contoso-SAML2.

Öppna en webbläsare och navigera till URL:en. Kontrollera att du skriver rätt URL och att du har åtkomst till XML-metadatafilen. Utför följande procedur på en federationsserver för att lägga till ett nytt förtroende för förlitande part med hjälp av snapin-modulen AD FS-hantering och konfigurera inställningarna manuellt. Medlemskap i administratörer eller motsvarande på den lokala datorn är det minsta som krävs för att slutföra den här proceduren.

  1. I Serverhanteraren, välj Verktyg och välj sedan AD FS-hantering.

  2. Välj Lägg till beroende parts förtroende.

  3. På sidan Välkommen väljer du Anspråksmedveten och sedan Start.

  4. På sidan Välj datakälla väljer du Importera data om den förlitande parten som publicerar online eller i ett lokalt nätverk, anger url:en för Azure AD B2C-metadata och väljer sedan Nästa.

  5. På sidan Ange visningsnamn anger du ett Visningsnamn under Anteckningar, anger en beskrivning för det förlitande partförtroendet och väljer sedan Nästa.

  6. På sidan Välj åtkomstkontrollprincip väljer du en princip och väljer sedan Nästa.

  7. På sidan Redo att lägga till förtroende granskar du inställningarna och väljer sedan Nästa för att spara förtroendeinformationen för den förlitande parten.

  8. På sidan Slutför väljer du Stäng. Den här åtgärden visar automatiskt dialogrutan Redigera anspråksregler .

  9. Välj Lägg till regel.

  10. I Mall för anspråksregel väljer du Skicka LDAP-attribut som anspråk.

  11. Ange ett namn på anspråksregeln. För attributarkivet väljer du Välj Active Directory, lägger till följande anspråk och väljer sedan Slutför och OK.

    LDAP-attribut Utgående anspråkstyp
    Användarens huvudnamn userPrincipalName
    Surname family_name
    Angivet namn given_name
    E-postadress E-post
    Visningsnamn name

    Observera att några av namnen inte visas i listrutan för utgående anspråkstyp. Du måste skriva in dem manuellt. (Listrutan kan redigeras).

  12. Baserat på certifikattypen kan du behöva ange HASH-algoritmen. I egenskapsfönstret för förlitande partförtroende (B2C Demo) väljer du fliken Avancerat och ändrar algoritmen För säker hash till SHA-256och väljer Ok.

  13. I Serverhanteraren, välj Verktyg och välj sedan AD FS-hantering.

  14. Välj det förlitande partförtroendet som du skapade, välj Uppdatera från federationsmetadata och välj sedan Uppdatera.

Testa din anpassade princip

  1. Logga in på Azure-portalen.
  2. Om du har åtkomst till flera klienter väljer du ikonen Inställningar på den översta menyn för att växla till din Azure AD B2C-klient från menyn Kataloger + prenumerationer.
  3. I Azure-portalen söker du efter och väljer Azure AD B2C.
  4. Under Principer väljer du Identity Experience Framework
  5. Välj din princip för förlitande part, till exempel B2C_1A_signup_signin.
  6. För Program väljer du ett webbprogram som du registrerade tidigare. Svars-URL :en ska visa https://jwt.ms.
  7. Välj knappen Kör nu.
  8. På registrerings- eller inloggningssidan väljer du Contoso AD FS för att logga in med Contoso AD FS-identitetsprovidern.

Om inloggningsprocessen lyckas omdirigeras webbläsaren till https://jwt.ms, som visar innehållet i token som returneras av Azure AD B2C.

Felsöka AD FS-tjänsten

AD FS har konfigurerats för att använda Windows-programloggen. Om du har problem med att konfigurera AD FS som en SAML-identitetsprovider med hjälp av anpassade principer i Azure AD B2C kanske du vill kontrollera AD FS-händelseloggen:

  1. I fältet Windows Search skriver du Loggboken och väljer sedan den Loggboken skrivbordsappen.
  2. Om du vill visa loggen för en annan dator högerklickar du på Loggboken (lokal). Välj Anslut till en annan dator och fyll i fälten för att slutföra dialogrutan Välj dator.
  3. Öppna program- och tjänstloggarna i Loggboken.
  4. Välj AD FS och välj sedan Admin.
  5. Om du vill visa mer information om en händelse dubbelklickar du på händelsen.

SAML-begäran är inte signerad med förväntad signaturalgoritmhändelse

Det här felet anger att SAML-begäran som skickas av Azure AD B2C inte är signerad med den förväntade signaturalgoritmen som konfigurerats i AD FS. Till exempel signeras SAML-begäran med signaturalgoritmen rsa-sha256, men den förväntade signaturalgoritmen är rsa-sha1. Åtgärda problemet genom att kontrollera att både Azure AD B2C och AD FS har konfigurerats med samma signaturalgoritm.

Alternativ 1: Ange signaturalgoritmen i Azure AD B2C

Du kan konfigurera hur du signerar SAML-begäran i Azure AD B2C. XmlSignatureAlgorithm-metadata styr värdet för parametern SigAlg (frågesträng eller postparameter) i SAML-begäran. I följande exempel konfigureras Azure AD B2C för att använda signaturalgoritmen rsa-sha256 .

<Metadata>
  <Item Key="WantsEncryptedAssertions">false</Item>
  <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
  <Item Key="XmlSignatureAlgorithm">Sha256</Item>
</Metadata>

Alternativ 2: Ange signaturalgoritmen i AD FS

Du kan också konfigurera den förväntade SAML-begärandesignaturalgoritmen i AD FS.

  1. I Serverhanteraren, välj Verktyg och välj sedan AD FS-hantering.
  2. Välj det förlitande partförtroende som du skapade tidigare.
  3. Välj Egenskaper och välj sedan Avancera
  4. Konfigurera algoritmen för säker hash och välj OK för att spara ändringarna.

HTTP-omdirigeringsbegäran innehåller inte den obligatoriska parametern Signatur för en signerad begäran (AADB2C90168)

Alternativ 1: Ange ResponsesSigned till false i Azure AD B2C

Du kan inaktivera kravet på signerat meddelande i Azure AD B2C. I följande exempel konfigureras Azure AD B2C för att inte kräva parametern Signatur för den signerade begäran.

<Metadata>
  <Item Key="WantsEncryptedAssertions">false</Item>
  <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
  <Item Key="ResponsesSigned">false</Item>
</Metadata>

Alternativ 2: Ställ in den förlitande parten i AD FS för att signera både meddelande och försäkran

Du kan också konfigurera den förlitande parten i AD FS enligt nedan:

  1. Öppna PowerShell som administratör och kör Set-AdfsRelyingPartyTrust -TargetName <RP Name> -SamlResponseSignature MessageAndAssertion cmdlet för att signera både meddelande och försäkran.
  2. Kör Set-AdfsRelyingPartyTrust -TargetName <RP Name> och bekräfta att egenskapen SamlResponseSignature har angetts som MessageAndAssertion.