Relying Party-toepassingen
Bijgewerkt: 19 juni 2015
Van toepassing op: Azure
Een relying party-toepassing (ook wel claimbewuste toepassing of op claims gebaseerde toepassing genoemd) is een toepassing of service die afhankelijk is van claims voor verificatie. In Microsoft Azure Active Directory Access Control (ook wel bekend als Access Control Service of ACS), is een relying party-toepassing een website, een toepassing of een service die gebruikmaakt van ACS om federatieve verificatie te implementeren.
U kunt relying party-toepassingen handmatig maken en configureren met behulp van de ACS-beheerportal of programmatisch met behulp van de ACS Management Service.
In de ACS-beheerportal is de relying party-toepassing die u toevoegt en configureert, een logische weergave van uw website, toepassing of service die een specifieke Access Control naamruimte vertrouwt. U kunt veel relying party-toepassingen toevoegen en configureren in elke Access Control naamruimte.
Configureren in de ACS-beheerportal
U kunt de ACS-beheerportal gebruiken om de volgende eigenschappen van een relying party-toepassing te configureren:
Modus
Realm en retour-URL
Fout-URL (optioneel)
Tokenindeling
Tokenversleutelingsbeleid
Levensduur van token
Id-providers
Regelgroepen
Tokenondertekening
Tokenversleuteling
Modus
De eigenschap Mode bepaalt of u de instellingen van de relying party-toepassing handmatig configureert of een WS-Federation metagegevensdocument opgeeft waarmee de toepassingsinstellingen worden gedefinieerd.
Een WS-Federation metagegevensdocument bevat doorgaans het realm van een toepassing en retour-URL. Het kan ook een optioneel versleutelingscertificaat bevatten dat wordt gebruikt om de tokens te versleutelen die ACS-problemen met de toepassing uitgeven. Als een WS-Federation document is opgegeven en de metagegevens een versleutelingscertificaat bevatten, wordt de instelling Voor tokenversleutelingsbeleid standaard ingesteld op Versleuteling vereisen. Als de waarde van de instelling tokenversleutelingsbeleidversleuteling vereisen is, maar het WS-Federation metagegevensdocument geen versleutelingscertificaat bevat, moet u handmatig een versleutelingscertificaat uploaden.
Als uw relying party-toepassing is geïntegreerd met Windows Identity Foundation (WIF), maakt WIF automatisch een WS-Federation metagegevensdocument voor uw toepassing.
Realm en retour-URL
De eigenschap Realm definieert de URI waarin de tokens die zijn uitgegeven door ACS geldig zijn. De retour-URL (ook wel het ReplyTo-adres genoemd) definieert de URL waarnaar de door ACS uitgegeven tokens worden verzonden. Wanneer een token wordt aangevraagd voor toegang tot de relying party-toepassing, geeft ACS het token alleen uit wanneer de realm in de tokenaanvraag overeenkomt met het realm van de relying party-toepassing.
Belangrijk
In ACS zijn realmwaarden hoofdlettergevoelig.
In de ACS-beheerportal kunt u slechts één realm en één retour-URL configureren in elke Access Control naamruimte. In het eenvoudigste geval zijn de realm en de retour-URL identiek. Als de hoofd-URI van uw toepassing bijvoorbeeld is https://contoso.com, zijn https://contoso.comrealm en retour-URL van de relying party-toepassing.
Als u meer dan één retour-URL (ReplyTo-adres) wilt configureren voor een relying party-toepassing, gebruikt u de entiteit RelyingPartyAddress in de ACS Management Service.
Wanneer een token wordt aangevraagd bij ACS of een token wordt geplaatst bij ACS van een id-provider, vergelijkt ACS de realmwaarde in de tokenaanvraag met de realmwaarden voor de relying party-toepassingen. Als de tokenaanvraag WS-Federation protocol gebruikt, gebruikt ACS de realmwaarde in de parameter wtrealm . Als het token gebruikmaakt van het OAuth WRAP-protocol, gebruikt ACS de realmwaarde in de parameter applies_to . Als ACS een overeenkomende realm vindt in de configuratie-instellingen voor een relying party-toepassing, wordt er een token gemaakt waarmee de gebruiker wordt geverifieerd bij de relying party-toepassing en het token wordt verzonden naar de retour-URL.
Het proces is vergelijkbaar wanneer de relying party meer dan één retour-URL heeft. ACS haalt de omleidings-URL op van de wreply-parameter . Als de omleidings-URL een van de retour-URL's is voor de relying party-toepassing, stuurt ACS het antwoord naar die URL.
Realm-waarden zijn hoofdlettergevoelig. Het token wordt alleen uitgegeven als de realm-waarden identiek zijn of als de realmwaarde voor de relying party-toepassing een voorvoegsel is van de realm in de tokenaanvraag. De realmwaarde van de relying party-toepassing komt bijvoorbeeld overeen met de realmwaarde van http://www.fabrikam.comhttp://www.fabrikam.com/billingeen tokenaanvraag, maar komt niet overeen met een tokenaanvraagrealm v van https://fabrikam.com.
Fout-URL (optioneel)
De fout-URL geeft een URL op waarnaar ACS gebruikers omleidt als er een fout optreedt tijdens het aanmeldingsproces. Het is een optionele eigenschap van de relying party-toepassing.
De waarde van de fout-URL kan een aangepaste pagina zijn die wordt gehost door de relying party-toepassing, zoals http://www.fabrikam.com/billing/error.aspx. Als onderdeel van de omleiding levert ACS details over de fout aan de relying party-toepassing als een met JSON gecodeerde HTTP-URL-parameter. De aangepaste foutpagina kan worden gemaakt om de JSON-gecodeerde foutinformatie te interpreteren, het werkelijke foutbericht weer te geven en/of statische Help-tekst weer te geven.
Zie Codevoorbeeld: ASP.NET Simple MVC 2 voor meer informatie over het gebruik van de fout-URL.
Tokenindeling
De eigenschap Token-indeling bepaalt de indeling van de tokens die DOOR ACS worden uitgevoerd voor de relying party-toepassing. ACS kan SAML 2.0-, SAML 1.1-, SWT- of JWT-tokens uitgeven. Zie Tokenindelingen die worden ondersteund in ACS voor meer informatie over tokenindelingen.
ACS maakt gebruik van standaardprotocollen om de tokens te retourneren naar een webtoepassing of -service. Wanneer meer dan één protocol wordt ondersteund voor een tokenindeling, gebruikt ACS hetzelfde protocol dat is gebruikt voor de tokenaanvraag. ACS ondersteunt de volgende combinaties van tokenindeling/protocol:
ACS kan SAML 2.0-tokens retourneren met behulp van WS-Trust- en WS-Federation-protocollen.
ACS kan SAML 1.1-tokens retourneren met behulp van WS-Federation en gerelateerde WS-Trust protocollen.
ACS kan SWT-tokens retourneren met behulp van WS-Federation-, WS-Trust-, OAuth-WRAP- en OAuth 2.0-protocollen.
ACS kan JWT-tokens uitgeven en retourneren met behulp van WS-Federation-, WS-Trust- en OAuth 2.0-protocollen.
Zie Protocollen die worden ondersteund in ACS voor meer informatie over standaardprotocollen die door ACS worden gebruikt.
Wanneer u een tokenindeling kiest, kunt u overwegen hoe uw Access Control naamruimte de tokens ondertekent die hiermee worden uitgevoerd. Alle door ACS uitgegeven tokens moeten zijn ondertekend. Zie Token-ondertekening voor meer informatie.
Overweeg ook of u wilt dat de tokens worden versleuteld.. Zie Tokenversleutelingsbeleid voor meer informatie.
Tokenversleutelingsbeleid
Het tokenversleutelingsbeleid bepaalt of de tokens die ACS-problemen met de relying party-toepassing ondervinden, worden versleuteld. Als u versleuteling wilt vereisen, selecteert u de waarde Versleuteling vereisen .
In ACS kunt u alleen een versleutelingsbeleid configureren voor SAML 2.0- of SAML 1.1-tokens. ACS biedt geen ondersteuning voor versleuteling van de SWT- of JWT-tokens.
ACS versleutelt SAML 2.0- en SAML 1.1-tokens met behulp van een X.509-certificaat met een openbare sleutel (.cer-bestand). Deze versleutelde tokens worden vervolgens ontsleuteld met behulp van een persoonlijke sleutel die wordt gebruikt door de relying party-toepassing. Zie Certificaten en sleutels voor meer informatie over het ophalen en gebruiken van versleutelingscertificaten.
Het configureren van een versleutelingsbeleid op uw door ACS uitgegeven tokens is optioneel. Een versleutelingsbeleid moet echter worden geconfigureerd wanneer uw relying party-toepassing een webservice is die gebruik maakt van proof-of-possession-tokens via het WS-Trust protocol. Dit specifieke scenario werkt niet goed zonder versleutelde tokens.
Levensduur van token
De eigenschap Levensduur van het token geeft het tijdsinterval (in seconden) aan waarin het beveiligingstoken dat ACS aan de relying party-toepassing geeft, geldig is. De standaardwaarde is 600 (10 minuten). In ACS moet de levensduur van het token tussen nul (0) en 86400 (24 uur) inclusief zijn.
Id-providers
De eigenschap Id-providers specificeert de id-providers die claims kunnen verzenden naar de relying party-toepassing. Deze id-providers worden weergegeven op de ACS-aanmeldingspagina voor uw webtoepassing of -service. Alle id-providers die zijn geconfigureerd in de sectie Id-providers van de ACS-portal, worden weergegeven in de lijst met id-providers. Als u een id-provider aan de lijst wilt toevoegen, klikt u op Id-providers.
Elke relying party-toepassing kan worden gekoppeld aan nul of meer id-providers. De relying party-toepassingen in een Access Control naamruimte kunnen worden gekoppeld aan dezelfde id-provider of verschillende id-providers. Als u geen id-providers selecteert voor een relying party-toepassing, moet u een directe verificatie met ACS configureren voor de relying party-toepassing. U kunt bijvoorbeeld service-identiteiten gebruiken om een directe verificatie te configureren. Zie Service-identiteiten voor meer informatie.
Regelgroepen
De eigenschap Regelgroepen bepaalt welke regels de relying party-toepassing gebruikt bij het verwerken van claims.
Elke ACS Relying Party-toepassing moet worden gekoppeld aan ten minste één regelgroep. Als een tokenaanvraag overeenkomt met een relying party-toepassing zonder regelgroepen, geeft ACS geen token uit aan de webtoepassing of -service.
Alle regelgroepen die zijn geconfigureerd in de sectie Regelgroepen van de ACS-portal, worden weergegeven in de lijst met regelgroepen. Als u een regelgroep aan de lijst wilt toevoegen, klikt u op Regelgroepen.
Wanneer u een nieuwe relying party-toepassing toevoegt in de ACS-beheerportal, wordt de optie Nieuwe regelgroep maken standaard geselecteerd. Het wordt sterk aanbevolen om een nieuwe regelgroep te maken voor uw nieuwe relying party-toepassing. U kunt uw relying party-toepassing echter koppelen aan een bestaande regelgroep. Hiervoor schakelt u de optie Nieuwe regelgroep maken uit en selecteert u de gewenste regelgroep.
U kunt een relying party-toepassing koppelen aan meer dan één regelgroep (en een regelgroep koppelen aan meer dan één relying party-toepassing). Als een relying party-toepassing is gekoppeld aan meer dan één regelgroep, evalueert ACS recursief de regels in alle regelgroepen alsof ze regels in één regelgroep waren.
Zie Regelgroepen en regels voor meer informatie over regels en regelgroepen.
Tokenondertekening
De eigenschap Token-ondertekeningsinstellingen geeft aan hoe de beveiligingstokens die ACS-problemen ondervinden, zijn ondertekend. Alle DOOR ACS uitgegeven tokens moeten zijn ondertekend.
De opties voor tokenondertekening die beschikbaar zijn, zijn afhankelijk van de tokenindeling van de relying party-toepassing. (Zie Token-indeling voor meer informatie over tokenindelingen.)
SAML-tokens: gebruik een X.509-certificaat om tokens te ondertekenen.
SWT-tokens: gebruik een symmetrische sleutel om tokens te ondertekenen.
JWT-tokens: gebruik een X.509-certificaat of een symmetrische sleutel om tokens te ondertekenen.
X.509-certificaatopties. De volgende opties zijn beschikbaar voor tokens die zijn ondertekend met een X.509-certificaat.
Gebruik servicenaamruimtecertificaat (standaard):als u deze optie selecteert, gebruikt ACS het certificaat voor de Access Control naamruimte om SAML 1.1- en SAML 2.0-tokens voor de relying party-toepassing te ondertekenen. Gebruik deze optie als u van plan bent om de configuratie van uw webtoepassing of -service te automatiseren met behulp van WS-Federation metagegevens, omdat de openbare naamruimtesleutel wordt gepubliceerd in de WS-Federation metagegevens voor uw Access Control naamruimte. De URL van het document WS-Federation Metagegevens wordt weergegeven op de pagina Toepassingsintegratie van de ACS-beheerportal.
Gebruik toegewezen certificaat: als u deze optie selecteert, gebruikt ACS een toepassingsspecifiek certificaat om SAML 1.1- en SAML 2.0-tokens te ondertekenen voor de relying party-toepassing. Het certificaat wordt niet gebruikt voor andere relying party-toepassingen. Nadat u deze optie hebt geselecteerd, bladert u naar een X.509-certificaat met een persoonlijke sleutel (PFX-bestand) en voert u het wachtwoord voor het PFX-bestand in.
Notitie
JWT-tokens. Wanneer u een relying party-toepassing configureert voor het gebruik van het X.509-certificaat voor de Access Control naamruimte om JWT-tokens te ondertekenen voor een relying party-toepassing, worden koppelingen naar het Access Control naamruimtecertificaat en de Access Control naamruimtesleutel weergegeven op de pagina voor de relying party-toepassing in de ACS-beheerportal. ACS gebruikt echter alleen het naamruimtecertificaat om tokens te ondertekenen voor de relying party-toepassing.
Beheerde naamruimten. Wanneer u een relying party-toepassing toevoegt aan een beheerde naamruimte, zoals een Service Bus naamruimte, voert u geen toepassingsspecifieke (toegewezen) certificaten of sleutels in. Selecteer in plaats daarvan de opties waarmee ACS wordt geleid om de certificaten en sleutels te gebruiken die zijn geconfigureerd voor alle toepassingen in de beheerde naamruimte. Zie Managed Namespaces voor meer informatieZie Certificaten en sleutels voor meer informatie over gedeelde en toegewezen certificaten en sleutels.
Opties voor symmetrische sleutels
Als best practice voor beveiliging maakt u bij het gebruik van symmetrische sleutels een toegewezen sleutel voor elke relying party-toepassing in plaats van de gedeelde symmetrische sleutel te gebruiken voor de Access Control naamruimte. Als u een toegewezen sleutel invoert of genereert, gebruikt ACS een toegewezen sleutel om tokens te ondertekenen voor de relying party-toepassing zolang de toegewezen sleutel geldig is. Als de toegewezen sleutel echter verloopt en niet wordt vervangen, gebruikt ACS de gedeelde naamruimtesleutel om tokens te ondertekenen voor de relying party-toepassing.
Als u ervoor kiest om de gedeelde symmetrische sleutel te gebruiken, kopieert u de waarden voor de servicenaamruimtesleutel van de pagina Certificaten en sleutels en plakt u deze in de velden in de sectie Token Signing van de pagina Relying Party-toepassingen .
De volgende opties zijn beschikbaar voor tokens die zijn ondertekend met symmetrische sleutels.
Ondertekeningssleutel voor tokens: voer een 256-bits symmetrische sleutel in of klik op Genereren om een 256-bits symmetrische sleutel te genereren.
Effectieve datum: hiermee geeft u de begindatum van het datumbereik op waarin de symmetrische sleutel geldig is. Vanaf deze datum gebruikt ACS de symmetrische sleutel om tokens te ondertekenen voor de relying party-toepassing. De standaardwaarde van ACS is de huidige datum.
Vervaldatum: hiermee geeft u de einddatum van het datumbereik op waarin de symmetrische sleutel geldig is. Vanaf deze datum gebruikt ACS de symmetrische sleutel niet om tokens te ondertekenen voor de relying party-toepassing. Er is geen standaardwaarde. Als best practice voor beveiliging moeten symmetrische sleutels elk jaar of elke twee jaar worden vervangen, afhankelijk van de vereisten van de toepassing.
Tokenversleuteling
Met de optie tokenversleutelingscertificaat wordt het X.509-certificaat (CER-bestand) opgegeven dat wordt gebruikt voor het versleutelen van tokens voor de relying party-toepassing. In ACS kunt u alleen SAML 2.0- of SAML 1.1-tokens versleutelen. ACS biedt geen ondersteuning voor versleuteling van SWT- of JWT-tokens.
U geeft certificaten op voor tokenversleuteling in de sectie Certificaten en sleutels van de ACS-portal. Wanneer u op de koppeling Klik hier klikt in de sectie Tokenversleutelingsbeleid van de toepassingspagina van relying party, wordt de pagina Tokenversleutelingscertificaat toevoegen van certificaten en sleutels geopend. Op deze pagina kunt u een certificaatbestand opgeven.
Zie Tokenversleutelingsbeleid voor meer informatie. Zie Certificaten en sleutels voor meer informatie over het ophalen en toevoegen van versleutelingscertificaten.