Federation med SAML/WS-Fed-identitetsprovidrar för gästanvändare (förhandsversion)

Anteckning

I den här artikeln beskrivs hur du ställer in federation med en organisation vars identitetsprovider (IdP) stöder SAML 2.0 WS-Fed-protokollet. När du ställer in federation med en partners IdP kan nya gästanvändare från den domänen använda sitt eget IdP-hanterade organisationskonto för att logga in på din Azure AD-klient och börja samarbeta med dig. Gästanvändaren behöver inte skapa ett separat Azure AD-konto.

Viktigt

  • Vi har tagit bort begränsningen som krävde att autentiserings-URL-domänen matchar måldomänen eller från en tillåten IdP. Mer information finns i Steg 1: Avgör om partnern behöver uppdatera sina DNS-textposter.
  • Vi rekommenderar nu att partnern ställer in målgruppen för SAML eller WS-Fed IdP till en klientorganisations publik. Se avsnitten om obligatoriska attribut och anspråk för SAML 2.0 och WS-Fed nedan.

När autentiseras en gästanvändare med SAML/WS-Fed IdP-federation?

När du har ställt in federation med en organisations SAML/WS-Fed IdP autentiseras alla nya gästanvändare som du bjuder in med hjälp av SAML/WS-Fed IdP. Observera att federationsinställningen inte ändrar autentiseringsmetoden för gästanvändare som redan har löst in en inbjudan från dig. Här är några exempel:

  • Om gästanvändare redan har löst in inbjudningar från dig och du därefter har ställt in federation med organisationens SAML/WS-Fed IdP fortsätter dessa gästanvändare att använda samma autentiseringsmetod som de använde innan du konfigurerade federation.
  • Om du ställer in federation med en organisations SAML/WS-Fed IdP och bjuder in gästanvändare, och sedan partnerorganisationen senare flyttar till Azure AD, fortsätter gästanvändare som redan har löst in inbjudningar att använda den federerade SAML/WS-Fed IdP, så länge federationsprincipen i din klientorganisation finns.
  • Om du tar bort federation med en organisations SAML/WS-Fed IdP kommer gästanvändare som för närvarande använder SAML/WS-Fed IdP inte att kunna logga in.

I något av dessa scenarier kan du uppdatera en gästanvändares autentiseringsmetod genom att återställa deras inlösningsstatus.

SAML/WS-Fed IdP-federation är kopplad till domännamnsrymder, till exempel contoso.com och fabrikam.com. När du upprättar federation AD FS eller en IdP från tredje part associerar organisationer en eller flera domännamnsrymder med dessa IDE:er.

Slutanvändarens upplevelse

Med SAML/WS-Fed IdP-federation loggar gästanvändare in på din Azure AD-klientorganisation med sitt eget organisationskonto. När de får åtkomst till delade resurser och uppmanas att logga in omdirigeras användarna till sin IdP. Efter en lyckad inloggning kommer användarna tillbaka till Azure AD för att få åtkomst till resurser. Deras uppdateringstoken är giltiga i 12 timmar, standardlängden för uppdateringstoken för genomströmning i Azure AD. Om den federerade IdP:n har enkel inloggning aktiverat får användaren enkel inloggning och ser ingen inloggningsuppfråga efter den första autentiseringen.

Inloggningsslutpunkter

SAML/WS-Fed IdP-federationsgästanvändare kan nu logga in på dina appar för flera klienter eller Microsofts förstapart med hjälp av en gemensam slutpunkt (med andra ord en allmän app-URL som inte innehåller din klientkontext). Under inloggningsprocessen väljer gästanvändaren Inloggningsalternativ och väljer sedan Logga in på en organisation. Användaren skriver sedan namnet på din organisation och fortsätter att logga in med sina egna autentiseringsuppgifter.

GÄSTanvändare för SAML/WS-Fed IdP-federation kan också använda programslutpunkter som innehåller din klientinformation, till exempel:

  • https://myapps.microsoft.com/?tenantid=<your tenant ID>
  • https://myapps.microsoft.com/<your verified domain>.onmicrosoft.com
  • https://portal.azure.com/<your tenant ID>

Du kan också ge gästanvändare en direktlänk till ett program eller en resurs genom att inkludera din klientinformation, till exempel https://myapps.microsoft.com/signin/Twitter/<application ID?tenantId=<your tenant ID> .

Vanliga frågor och svar

Kan jag konfigurera SAML/WS-Fed IdP-federation med Azure AD-verifierade domäner?

Nej, vi blockerar SAML/WS-Fed IdP-federation för Azure AD-verifierade domäner och använder inbyggda funktioner för Azure AD-hanterade domäner. Om du försöker konfigurera SAML/WS-Fed IdP-federation med en domän som är DNS-verifierad i Azure AD visas ett fel i Azure Portal eller PowerShell.

Kan jag konfigurera SAML/WS-Fed IdP-federation med en domän där det finns en ohanterad (e-postverifierad) klient?

Ja, du kan konfigurera SAML/WS-Fed IdP-federation med domäner som inte är DNS-verifierade i Azure AD, inklusive ohanterade (e-postverifierade eller "virala") Azure AD-klienter. Sådana klienter skapas när en användare löser in en B2B-inbjudan eller utför självbetjäningsregistrering för Azure AD med hjälp av en domän som för närvarande inte finns. Om domänen inte har verifierats och klientorganisationen inte har genomgått ett administratörsupptagande kandu konfigurera federation med den domänen.

Hur många federationsrelationer kan jag skapa?

För närvarande stöds högst 1 000 federationsrelationer. Den här gränsen omfattar både interna federationer och SAML/WS-Fed IdP-federationer.

Kan jag konfigurera federation med flera domäner från samma klientorganisation?

Vi stöder för närvarande inte SAML/WS-Fed IdP-federation med flera domäner från samma klientorganisation.

Måste jag förnya signeringscertifikatet när det upphör att gälla?

Om du anger metadata-URL:en i IdP-inställningarna förnyar Azure AD automatiskt signeringscertifikatet när det upphör att gälla. Men om certifikatet roteras av någon anledning före förfallotiden, eller om du inte anger en metadata-URL, kan Azure AD inte förnya det. I det här fallet måste du uppdatera signeringscertifikatet manuellt.

Vilken metod har företräde om både SAML/WS-Fed IdP-federation och autentisering med e-post med ett enda lösenord är aktiverat?

När SAML/WS-Fed IdP-federation upprättas med en partnerorganisation prioriteras autentisering med e-postkod vid en enda tidpunkt för nya gästanvändare från den organisationen. Om en gästanvändare löste in en inbjudan med hjälp av autentisering med ett lösenord innan du konfigurerade SAML/WS-Fed IdP-federation fortsätter de att använda autentisering med ett lösenord.

Åtgärdar SAML/WS-Fed IdP-federation inloggningsproblem på grund av en delvis synkroniserad innehavare?

Nej, funktionen för e-postkoder för en gång ska användas i det här scenariot. Ett "delvis synkroniserat innehav" avser en Azure AD-partnerklientorganisation där lokala användaridentiteter inte är helt synkroniserade till molnet. En gäst vars identitet ännu inte finns i molnet men som försöker lösa in din B2B-inbjudan kan inte logga in. Funktionen för ett lösenord gör att den här gästen kan logga in. Federationsfunktionen SAML/WS-Fed IdP åtgärdar scenarier där gästen har ett eget IdP-hanterat organisationskonto, men organisationen inte har någon Azure AD-närvaro alls.

När SAML/WS-Fed IdP-federation har konfigurerats med en organisation, måste varje gäst skickas och lösa in en enskild inbjudan?

Att konfigurera SAML/WS-Fed IdP-federation ändrar inte autentiseringsmetoden för gästanvändare som redan har löst in en inbjudan från dig. Du kan uppdatera en gästanvändares autentiseringsmetod genom att återställa deras inlösningsstatus.

Går det att skicka en signerad begäran till SAML-identitetsprovidern?

För närvarande stöder inte federationsfunktionen Azure AD SAML/WS-Fed att skicka en signerad autentiseringstoken till SAML-identitetsprovidern.

Steg 1: Avgör om partnern behöver uppdatera sina DNS-textposter

Beroende på partnerns IdP kan partnern behöva uppdatera sina DNS-poster för att aktivera federation med dig. Använd följande steg för att avgöra om DNS-uppdateringar behövs.

  1. Om partnerns IdP är en av dessa tillåtna IDE:er behövs inga DNS-ändringar (den här listan kan komma att ändras):

    • accounts.google.com
    • pingidentity.com
    • login.pingone.com
    • okta.com
    • oktapreview.com
    • okta-emea.com
    • my.salesforce.com
    • federation.exostar.com
    • federation.exostartest.com
    • idaptive.app
    • idaptive.qa
  2. Om IdP:n inte är en av de tillåtna leverantörerna som anges i föregående steg kontrollerar du partnerns IDP-autentiserings-URL för att se om domänen matchar måldomänen eller en värd i måldomänen. Med andra ord, när du ställer in federation för fabrikam.com :

    • Om autentiserings-URL:en https://fabrikam.com https://sts.fabrikam.com/adfs är eller (en värd i samma domän) behövs inga DNS-ändringar.
    • Om autentiserings-URL:en är eller matchar domänen inte fabrikam.com-domänen, så partnern måste lägga till en textpost för autentiserings-URL:en i https://fabrikamconglomerate.com/adfs    https://fabrikam.com.uk/adfs dns-konfigurationen.

    Viktigt

    Det finns ett känt problem med följande steg. Om du lägger till en DNS-textpost till den federerande IdP:ns domän avblockerar du för närvarande inte autentiseringen. Vi arbetar aktivt med att åtgärda problemet.

  3. Om DNS-ändringar krävs baserat på föregående steg ber du partnern att lägga till en TXT-post i domänens DNS-poster, som i följande exempel:

    fabrikam.com.  IN   TXT   DirectFedAuthUrl=https://fabrikamconglomerate.com/adfs

Steg 2: Konfigurera partnerorganisationens IdP

Därefter måste din partnerorganisation konfigurera sin IdP med nödvändiga anspråk och förtroenden för förlitande part.

Anteckning

För att illustrera hur du konfigurerar en SAML/WS-Fed IdP för federation använder vi Active Directory Federation Services (AD FS) (AD FS) som exempel. Se artikeln Configure SAML/WS-Fed IdP federation with AD FS (Konfigurera SAML/WS-Fed IdP-federationmed AD FS) som ger exempel på hur du konfigurerar AD FS som en SAML 2.0- eller WS-Fed IdP som förberedelse för federation.

SAML 2.0-konfiguration

Azure AD B2B kan konfigureras för att federera med IP:er som använder SAML-protokollet med specifika krav som anges nedan. Mer information om hur du ställer in ett förtroende mellan din SAML IdP och Azure AD finns i Använda en SAML 2.0-identitetsprovider (IdP)för enkel inloggning.

Anteckning

Måldomänen för SAML/WS-Fed IdP-federation får inte vara DNS-verifierad i Azure AD. Mer information finns i avsnittet Vanliga frågor och svar.

Obligatoriska SAML 2.0-attribut och anspråk

Följande tabeller visar krav för specifika attribut och anspråk som måste konfigureras på IdP från tredje part. För att konfigurera federation måste följande attribut tas emot i SAML 2.0-svaret från IdP:n. Dessa attribut kan konfigureras genom att länka till XML-filen för onlinesäkerhetstokentjänsten eller genom att ange dem manuellt.

Obligatoriska attribut för SAML 2.0-svaret från IdP:n:

Attribut Värde
AssertionConsumerService https://login.microsoftonline.com/login.srf
Målgrupp https://login.microsoftonline.com/<tenant ID>/ (Rekommenderad klientorganisations målgrupp.) Ersätt <tenant ID> med klientorganisations-ID:t för den Azure AD-klientorganisation som du ställer in federation med.

urn:federation:MicrosoftOnline (Det här värdet kommer att bli inaktuellt.)
Utfärdare Utfärdarens URI för partner-IdP, till exempel http://www.example.com/exk10l6w90DHM0yi...

Obligatoriska anspråk för SAML 2.0-token som utfärdats av IdP:n:

Attribut Värde
NameID-format urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

WS-Fed konfiguration

Azure AD B2B kan konfigureras för att federera med IP:er som använder WS-Fed-protokollet med vissa specifika krav enligt listan nedan. För närvarande har de WS-Fed leverantörerna testats för kompatibilitet med Azure AD, bland annat AD FS Shibboleth. Mer information om hur du etablerar ett förtroende för förlitande part mellan en WS-Fed-kompatibel provider med Azure AD finns i "STS-integrationsdokument med WS-protokoll" som finns i Kompatibilitetsdokument för Azure AD-identitetsprovider.

Anteckning

Måldomänen för federation får inte vara DNS-verifierad i Azure AD. Mer information finns i avsnittet Vanliga frågor och svar.

Obligatoriska WS-Fed attribut och anspråk

Följande tabeller visar krav för specifika attribut och anspråk som måste konfigureras på tredjepartsleverantören WS-Fed IdP. För att federation ska kunna konfigureras måste följande attribut tas emot i WS-Fed från IdP:n. Dessa attribut kan konfigureras genom att länka till XML-filen för onlinesäkerhetstokentjänsten eller genom att ange dem manuellt.

Obligatoriska attribut i WS-Fed från IdP:n:

Attribut Värde
PassiveRequestorEndpoint https://login.microsoftonline.com/login.srf
Målgrupp https://login.microsoftonline.com/<tenant ID>/ (Rekommenderad klientorganisations målgrupp.) Ersätt <tenant ID> med klientorganisations-ID:t för den Azure AD-klient som du federerar med.

urn:federation:MicrosoftOnline (Det här värdet kommer att bli inaktuellt.)
Utfärdare Utfärdarens URI för partner-IdP, till exempel http://www.example.com/exk10l6w90DHM0yi...

Obligatoriska anspråk för den WS-Fed token som utfärdats av IdP:n:

Attribut Värde
ImmutableID http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID
emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Steg 3: Konfigurera SAML/WS-Fed IdP-federation i Azure AD

Därefter konfigurerar du federation med IdP:n som konfigurerades i steg 1 i Azure AD. Du kan använda antingen Azure AD-portalen eller PowerShell. Det kan ta 5–10 minuter innan federationsprincipen börjar gälla. Under den här tiden ska du inte försöka lösa in en inbjudan till federationsdomänen. Följande attribut krävs:

  • Utfärdar-URI för partner-IdP
  • Passiv autentiseringsslutpunkt för partner-IdP (endast https stöds)
  • Certifikat

Så här konfigurerar du federation i Azure AD-portalen

  1. Gå till Azure-portalen. Välj Azure Active Directory i den vänstra rutan.

  2. Välj External Identities Alla > identitetsproviders.

  3. Välj Ny SAML/WS-Fed IdP.

    Skärmbild som visar knappen för att lägga till en ny SAML eller WS-Fed IdP

  4. På sidan New SAML/WS-Fed IdP (Ny SAML/WS-Fed IdP) under Identity Provider Protocol(Protokoll för identitetsprovider) väljer du SAML eller WS-FED.

    Skärmbild som visar parsning-knappen på SIDAN SAML WS-Fed IdP

  5. Ange partnerorganisationens domännamn, som ska vara måldomännamnet för federation

  6. Du kan ladda upp en metadatafil för att fylla i metadatainformation. Om du väljer att mata in metadata manuellt anger du följande information:

    • Domännamn för partner-IdP
    • Entitets-ID för partner-IdP
    • Passiv begärandeslutpunkt för partner-IdP
    • Certifikat

    Anteckning

    Metadata-URL är valfritt, men vi rekommenderar det starkt. Om du anger metadata-URL:en kan Azure AD förnya signeringscertifikatet automatiskt när det upphör att gälla. Om certifikatet roteras av någon anledning före förfallotiden eller om du inte anger en metadata-URL kan Azure AD inte förnya det. I det här fallet måste du uppdatera signeringscertifikatet manuellt.

  7. Välj Spara.

Så här konfigurerar du SAML/WS-Fed IdP-federation i Azure AD med hjälp av PowerShell

  1. Installera den senaste versionen av Azure AD PowerShell för Graph modulen (AzureADPreview). Om du behöver detaljerade steg innehåller snabbstarten vägledningen, PowerShell-modulen.

  2. Kör följande kommando:

    Connect-AzureAD
    
  3. Logga in med det hanterade globala administratörskontot i inloggningsuppmaning.

  4. Kör följande kommandon och ersätt värdena från federationsmetadatafilen. För AD FS Server och Okta är federationsfilen federationmetadata.xml, till exempel: https://sts.totheclouddemo.com/federationmetadata/2007-06/federationmetadata.xml .

    $federationSettings = New-Object Microsoft.Open.AzureAD.Model.DomainFederationSettings
    $federationSettings.PassiveLogOnUri ="https://sts.totheclouddemo.com/adfs/ls/"
    $federationSettings.LogOffUri = $federationSettings.PassiveLogOnUri
    $federationSettings.IssuerUri = "http://sts.totheclouddemo.com/adfs/services/trust"
    $federationSettings.MetadataExchangeUri="https://sts.totheclouddemo.com/adfs/services/trust/mex"
    $federationSettings.SigningCertificate= <Replace with X509 signing cert’s public key>
    $federationSettings.PreferredAuthenticationProtocol="WsFed" OR "Samlp"
    $domainName = <Replace with domain name>
    New-AzureADExternalDomainFederation -ExternalDomainName $domainName  -FederationSettings $federationSettings
    

Steg 4: Testa SAML/WS-Fed IdP-federation i Azure AD

Testa federationskonfigurationen genom att bjuda in en ny B2B-gästanvändare. Mer information finns i Lägga till Azure AD B2B-samarbetsanvändare i Azure Portal.

Hur gör jag för att redigera en SAML/WS-Fed IdP-federationsrelation?

  1. Gå till Azure-portalen. Välj Azure Active Directory i den vänstra rutan.
  2. Välj External Identities.
  3. Välj Alla identitetsproviders
  4. Under SAML/WS-Fed-identitetsproviders väljer du providern.
  5. Uppdatera värdena i informationsfönstret för identitetsprovidern.
  6. Välj Spara.

Hur gör jag för att federation?

Du kan ta bort federationskonfigurationen. Om du gör det kan federationsgästanvändare som redan har löst in sina inbjudningar inte logga in. Men du kan ge dem åtkomst till dina resurser igen genom att återställa deras inlösningsstatus. Så här tar du bort federation med en IdP i Azure AD-portalen:

  1. Gå till Azure-portalen. Välj Azure Active Directory i den vänstra rutan.
  2. Välj External Identities.
  3. Välj Alla identitetsproviders.
  4. Välj identitetsprovidern och välj sedan Ta bort.
  5. Bekräfta borttagningen genom att välja Ja.

Så här tar du bort federation med en identitetsprovider med hjälp av PowerShell:

  1. Installera den senaste versionen av Azure AD PowerShell för Graph modulen (AzureADPreview).

  2. Kör följande kommando:

    Connect-AzureAD
    
  3. Logga in med det hanterade globala administratörskontot i inloggningsuppmaning.

  4. Ange följande kommando:

    Remove-AzureADExternalDomainFederation -ExternalDomainName  $domainName
    

Nästa steg

Läs mer om inlösningsupplevelsen när externa användare loggar in med olika identitetsproviders.