In vielen technischen Notizen und Webartikeln wird über verschiedene Aspekte der anspruchsbasierten Föderation zwischen ADFS 2.0 und SharePoint 2010 gesprochen. In diesem Blog werden wir uns in erster Linie auf die Zuordnung von Ansprüchen, Einstellungen für die Authentifizierung und den Autorisierungsprozess konzentrieren.
Lassen Sie uns im Folgenden ein End-to-End-Szenario durchspielen:
1. Der Benutzer versucht, auf die auf Ansprüchen basierende Webanwendung von SharePoint 2010 zuzugreifen.
2. SharePoint leitet die Zugriffsanforderung an ADFS weiter, basierend auf der SharePoint Trusted Identity Token Provider-Konfiguration mit der Einrichtung einer Föderationsvertrauensbeziehung mit ADFS.
$Name = New-SPClaimTypeMapping "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "Anzeigename" -LocalClaimType "https://schemas.contoco.com/identity/claims/name
$Role = New-SPClaimTypeMapping "https://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFSv2" -Description "Active Directory Federation Services 2.0" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $Name, $Role -SignInUrl $signInURL -IdentifierClaim $Name.InputClaimType
Beachten Sie, dass der Anspruchstyp Name https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name von SharePoint reserviert ist. In diesem Beispiel verwenden wir -LocalClaimType, um eine Zuordnung der Fallart zu https://schemas.contoso.com /identity/claims/name vorzunehmen. Den Grund dafür werden wir später sehen. Im Sinne von SharePoint ist diese zugeordnete Fallart https://schemas.contoso.com/identity/claims/name eine so genannte benutzerdefinierte Fallart (nicht vordefinierte Fallart).
3. ADFS authentifiziert den Benutzer, generiert das Sicherheits-Token mit 2 Ansprüchen und sendet es zurück an SharePoint.
<saml:Attribute AttributeName=”role” AttributeNamespace=” https://schemas.microsoft.com/ws/2008/06/identity/claims”>
<saml:AttributeValue>SharePoint Users</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute AttributeName=“name“ AttributeNamespace=”https://schemas.xmlsoap.org/ws/2005/05/identity/claims”>
<saml:AttributeValue>Jake</saml:AttributeValue>
</saml:Attribute>
4. Der SharePoint Security Token Service validiert das Security Token, verbraucht die Claims, bildet den Name-Claim neu ab und generiert außerdem eigene Claims als Ergänzungen. Alle Ansprüche zusammen werden an die anspruchsbasierte Webanwendung weitergeleitet.
https://schemas.contoso.com/identity/claims/name = Jake
https://schemas.xmlsoap.org/ws/2005/05/identity/claims/role = SharePoint Users
https://schemas.microsoft.com/sharepoint/2009/08/claims/userid = 0ǵ.t|ADFSv2|Jake https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name = Jake
https://sharepoint.microsoft.com/claims/2009/08/isauthenticated = true
Beachten Sie, dass der erste Claim von SharePoint auf der Grundlage der Claim-Zuordnung in der Konfiguration neu zugeordnet wird.
$Name = New-SPClaimTypeMapping "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "Anzeigename" -LocalClaimType "https://schemas.contoco.com/identity/claims/name
Die letzten 3 Ansprüche mit vordefinierten Anspruchsarten werden von SharePoint generiert und die Werte werden auf der Grundlage der eingehenden Anspruchswerte berechnet. Der von SharePoint generierte Claim mit dem Typ https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name ist ebenfalls enthalten. Das ist der Grund, warum wir -LocalClaimType verwenden müssen, wenn wir den in Schritt 2 erwähnten Trusted Identity Token Issuer einrichten. Der letzte Anspruch https://sharepoint.microsoft.com/claims/2009/08/isauthenticated = true basiert auf der Authentifizierungsanweisung des eingehenden Sicherheitstokens.
5. Bevor alle Anträge an die antragsbasierte Webanwendung weitergeleitet werden, führt SharePoint eine Berechtigungsprüfung durch. Wir können People Picker verwenden, um die Berechtigung für die Berechtigungsentscheidung einzurichten. In diesem Blog möchten wir jedoch zeigen, wie man Powershell verwendet, um solche Berechtigungseinstellungen zu implementieren.
Wenn wir beispielsweise allen authentifizierten Benutzern den Zugriff auf diese Webanwendung in der SharePoint-Gruppe "SharePoint-Web-Home-Besucher" mit der Berechtigungsstufe "Lesen" gestatten möchten, können wir wie folgt vorgehen:
$web = Get-SPWeb "https://www.sharepoint.com:4443"
$Group = $web.SiteGroups["SharePoint Web Home Besucher"]
$claimPrincipal =New-SPClaimsPrincipal -EncodedClaim "c:0(.s|true"
$newUser = New-SPUser -UserAlias $claimPrincipal.ToEncodedString() -Web $web
$group.AddUser($newUser)
Beachten Sie, dass "c:0(.s|true" die kodierte Anspruchszeichenfolge für "All Authenticated Users" ist. Die kodierte Anspruchszeichenfolge basiert auf dem SharePoint-Anspruchszuordnungsformat und den Regeln wie unten:
c -> anderer Anspruch (als Identitätsanspruch)
( -> Anspruchstyp Zeichen von https://sharepoint.microsoft.com/claims/2009/08/isauthenticated
s -> lokales STS (SharePoint STS ist der Emittent für diesen Anspruch, d.h. SharePoint generiert seinen eigenen)
wahr -> Forderungswert (zur Erinnerung: https://sharepoint.microsoft.com/claims/2009/08/isauthenticated = wahr)
Um allen authentifizierten Benutzern mit der Rolle "SharePoint-Benutzer" den Zugriff auf diese Webanwendung in der SharePoint-Gruppe "SharePoint-Web-Home-Besucher" mit der Berechtigungsstufe "Lesen" zu ermöglichen, können wir Folgendes tun:
$web = Get-SPWeb "https://www.sharepoint.com:4443"
$Group = $web.SiteGroups["SharePoint Web Home Besucher"]
$sts = Get-SPTrustedIdentityTokenIssuer "ADFSv2"
$claimPrincipal = New-SPClaimsPrincipal -ClaimValue "SharePoint Users" -ClaimType "https://schemas.microsoft.com/ws/2008/06/identity/claims/role" -TrustedIdentityTokenIssuer $sts
$newUser = New-SPUser -UserAlias $claimPrincipal.ToEncodedString() -Web $web
$group.AddUser($newUser)
6. Sobald der Zugriff autorisiert ist, setzt SharePoint ein FedAuth-Cookie und leitet die Anfrage an das ursprüngliche Ziel weiter.
