Identitätsdelegierungsszenario mit AD FS
[Ab .NET Framework 4.5 ist Windows Identity Foundation (WIF) vollständig in das .NET Framework integriert. Die in diesem Thema behandelte WIF 3.5-Version ist veraltet und sollte nur bei der Entwicklung für .NET Framework 3.5 SP1 oder .NET Framework 4 verwendet werden. Weitere Informationen zu WIF im .NET Framework 4.5, auch bekannt als WIF 4.5, finden Sie in der Windows Identity Foundation-Dokumentation im .NET Framework 4.5-Entwicklungshandbuch.]
In diesem Szenario wird eine Anwendung beschrieben, die auf Back-End-Ressourcen zugreifen muss, die die Identitätsdelegierungskette erfordern, um Zugriffssteuerungsprüfungen durchzuführen. Eine einfache Identitätsdelegierungskette besteht in der Regel aus den Informationen zum ersten Aufrufer und der Identität des unmittelbaren Aufrufers.
Mit dem Kerberos-Delegierungsmodell auf der Windows-Plattform haben die Back-End-Ressourcen heutzutage nur Zugriff auf die Identität des unmittelbaren Aufrufers und nicht auf die des ersten Aufrufers. Dieses Modell wird häufig als vertrauenswürdiges Subsystemmodell bezeichnet. WIF verwaltet die Identität des ersten Aufrufers sowie des unmittelbaren Aufrufers in der Delegierungskette mithilfe der „Actor“-Eigenschaft (Akteur).
Das folgende Diagramm veranschaulicht ein typisches Identitätsdelegierungsszenario, in dem ein Fabrikam-Mitarbeiter auf Ressourcen zugreift, die in einer Contoso.com-Anwendung verfügbar gemacht werden.
Die fiktiven Benutzer in diesem Szenario sind:
- Frank: Ein Fabrikam-Mitarbeiter, der auf Contoso-Ressourcen zugreifen möchte.
- Daniel: Ein Contoso-Anwendungsentwickler, der die notwendigen Änderungen in der Anwendung implementiert.
- Adam: Der IT-Administrator von Contoso.
In diesem Szenario sind die folgenden Komponenten beteiligt:
- web1: Eine Webanwendung mit Links zu Back-End-Ressourcen, für die die delegierte Identität des ersten Aufrufers erforderlich ist. Diese Anwendung wurde mit ASP.NET erstellt.
- Ein Webdienst, der auf einen SQL Server zugreift, der die delegierte Identität des ersten Aufrufers zusammen mit der des unmittelbaren Aufrufers erfordert. Dieser Dienst wurde mit WCF erstellt.
- sts1: Ein STS, der die Rolle des Anspruchsanbieters übernimmt und Ansprüche ausgibt, die von der Anwendung (web1) erwartet werden. Er hat eine Vertrauensstellung mit „Fabrikam.com“ sowie mit der Anwendung eingerichtet.
- sts2: Ein STS, der die Rolle des Identitätsanbieters für „Fabrikam.com“ übernimmt und einen Endpunkt bereitstellt, den der Fabrikam-Mitarbeiter zur Authentifizierung verwendet. Er hat eine Vertrauensstellung mit „Contoso.com“ eingerichtet, sodass Fabrikam-Mitarbeiter auf Ressourcen auf „Contoso.com“ zugreifen dürfen.
Hinweis
Der Begriff „ActAs-Token“, der in diesem Szenario häufig verwendet wird, bezieht sich auf ein Token, das von einem STS ausgestellt wird und die Identität des Benutzers enthält. Die Actor-Eigenschaft enthält die Identität des STS.
Wie im vorherigen Diagramm gezeigt, ist der Ablauf in diesem Szenario wie folgt:
- Die Contoso-Anwendung ist so konfiguriert, dass Sie ein ActAs-Token abruft, das sowohl die Identität des Fabrikam-Mitarbeiters als auch die Identität des unmittelbaren Aufrufers in der Actor-Eigenschaft enthält. Daniel hat diese Änderungen an der Anwendung implementiert.
- Die Contoso-Anwendung ist so konfiguriert, dass das ActAs-Token an den Back-End-Dienst übergibt. Daniel hat diese Änderungen an der Anwendung implementiert.
- Der Contoso-Webdienst ist so konfiguriert, dass er das ActAs-Token durch Aufrufen von sts1 überprüft. Adam hat auf sts1 die Verarbeitung von Delegierungsanforderungen aktiviert.
- Fabrikam-Benutzer Frank greift auf die Contoso-Anwendung zu und erhält Zugriff auf die Back-End-Ressourcen.
Einrichten des Identitätsanbieters
Dem „Fabrikam.com“-Administrator Frank stehen drei Optionen zur Verfügung:
- Kaufen und Installieren eines STS-Produkts, z. B. Active Directory-Verbunddienste® (AD FS).
- Abonnieren eines Cloud-STS-Produkts, z. B. LiveID STS.
- Erstellen eines benutzerdefinierten STS mithilfe von WIF.
Für dieses Beispielszenario wird davon ausgegangen, dass Frank Option 1 auswählt und AD FS als Identitätsanbieter-STS installiert. Außerdem konfiguriert er einen Endpunkt namens „\windowsauth“, um die Benutzer zu authentifizieren. Unter Zuhilfenahme der AD FS-Produktdokumentation und durch Gespräche mit Adam, dem IT-Administrator von Contoso, richtet Frank die Vertrauensstellung mit der Domäne „Contoso.com“ ein.
Einrichten des Anspruchsanbieters
Die Optionen, die dem „Contoso.com“-Administrator Adam zur Verfügung stehen, sind dieselben, wie die zuvor für den Identitätsanbieter beschriebenen. Für dieses Beispielszenario wird davon ausgegangen, dass Adam Option 1 auswählt und AD FS 2.0 als Ressourcenanbieter-STS installiert.
Einrichten der Vertrauensstellung mit dem Identitätsanbieter und der Anwendung
Unter Zuhilfenahme der AD FS-Dokumentation richtet Adam eine Vertrauensstellung zwischen „Fabrikam.com“ und der Anwendung ein.
Einrichten der Delegierung
AD FS bietet Delegierungsverarbeitung. Unter Zuhilfenahme der AD FS-Dokumentation aktiviert Adam die Verarbeitung von ActAs-Token.
Anwendungsspezifische Änderungen
Die folgenden Änderungen müssen vorgenommen werden, um einer vorhandenen Anwendung Unterstützung für die Identitätsdelegierung hinzuzufügen. Daniel verwendet WIF, um diese Änderungen vorzunehmen.
- Zwischenspeichern des Bootstraptokens, das web1 von sts1 empfangen hat.
- Verwenden von CreateChannelActingAs mit dem ausgestellten Token, um einen Kanal zum Back-End-Webdienst zu erstellen.
- Aufrufen der Methode des Back-End-Diensts.
Zwischenspeichern des Bootstraptokens
Das Bootstraptoken ist das erste Token, das vom STS ausgegeben wird, und die Anwendung extrahiert daraus Ansprüche. In diesem Beispielszenario wird dieses Token von sts1 für den Benutzer Frank ausgegeben, und die Anwendung speichert es zwischen. Im folgenden Codebeispiel wird gezeigt, wie Sie ein Bootstraptoken in einer ASP.NET-Anwendung abrufen:
// Get the Bootstrap Token
SecurityToken bootstrapToken = null;
IClaimsPrincipal claimsPrincipal = Thread.CurrentPrincipal as IClaimsPrincipal;
if ( claimsPrincipal != null )
{
IClaimsIdentity claimsIdentity = (IClaimsIdentity)claimsPrincipal.Identity;
bootstrapToken = claimsIdentity.BootstrapToken;
}
WIF stellt die Methode CreateChannelActingAs bereit, die einen Kanal des angegebenen Typs erstellt, der Tokenausstellungsanforderungen mit dem angegebenen Sicherheitstoken als ActAs-Element ergänzt. Sie können das Bootstraptoken an diese Methode übergeben und dann die erforderliche Dienstmethode für den zurückgegebenen Kanal aufrufen. In diesem Beispielszenario ist für Franks Identität die Actor-Eigenschaft auf die Identität von web1 festgelegt.
Der folgende Codeausschnitt zeigt, wie Sie den Webdienst mit CreateChannelActingAs aufrufen und dann eine der Methoden des Diensts (ComputeResponse) im zurückgegebenen Kanal aufrufen:
// Get the channel factory to the backend service from the application state
ChannelFactory<IService2Channel> factory = (ChannelFactory<IService2Channel>)Application[Global.CachedChannelFactory];
// Create and setup channel to talk to the backend service
IService2Channel channel;
lock (factory)
{
// Setup the ActAs to point to the caller's token so that we perform a
// delegated call to the backend service
// on behalf of the original caller.
channel = factory.CreateChannelActingAs<IService2Channel>(callerToken);
}
string retval = null;
// Call the backend service and handle the possible exceptions
try
{
retval = channel.ComputeResponse(value);
channel.Close();
} catch (Exception exception)
{
StringBuilder sb = new StringBuilder();
sb.AppendLine("An unexpected exception occurred.");
sb.AppendLine(exception.StackTrace);
channel.Abort();
retval = sb.ToString();
}
Webdienstspezifische Änderungen
Da der Webdienst mit WCF erstellt wurde und für WIF aktiviert ist, wird die Validierung von ActAs automatisch von WIF verarbeitet, sobald die Bindung mit „IssuedSecurityTokenParameters“ mit der richtigen Ausstelleradresse konfiguriert wurde.
Der Webdienst macht die spezifischen Methoden verfügbar, die von der Anwendung benötigt werden. Es sind keine spezifischen Codeänderungen am Dienst erforderlich. Im folgenden Codebeispiel wird die Konfiguration des Webdiensts mit „IssuedSecurityTokenParameters“ veranschaulicht:
// Configure the issued token parameters with the correct settings
IssuedSecurityTokenParameters itp = new IssuedSecurityTokenParameters( "http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1" );
itp.IssuerMetadataAddress = new EndpointAddress( "http://localhost:6000/STS/mex" );
itp.IssuerAddress = new EndpointAddress( "http://localhost:6000/STS" );
// Create the security binding element
SecurityBindingElement sbe = SecurityBindingElement.CreateIssuedTokenForCertificateBindingElement( itp );
sbe.MessageSecurityVersion = MessageSecurityVersion.WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10;
// Create the HTTP transport binding element
HttpTransportBindingElement httpBE = new HttpTransportBindingElement();
// Create the custom binding using the prepared binding elements
CustomBinding binding = new CustomBinding( sbe, httpBE );
using ( ServiceHost host = new ServiceHost( typeof( Service2 ), new Uri( "http://localhost:6002/Service2" ) ) )
{
host.AddServiceEndpoint( typeof( IService2 ), binding, "" );
host.Credentials.ServiceCertificate.SetCertificate( "CN=localhost", StoreLocation.LocalMachine, StoreName.My );
// Enable metadata generation via HTTP GET
ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
smb.HttpGetEnabled = true;
host.Description.Behaviors.Add( smb );
host.AddServiceEndpoint( typeof( IMetadataExchange ), MetadataExchangeBindings.CreateMexHttpBinding(), "mex" );
// Configure the service host to use WIF
ServiceConfiguration configuration = new ServiceConfiguration();
configuration.IssuerNameRegistry = new TrustedIssuerNameRegistry();
FederatedServiceCredentials.ConfigureServiceHost( host, configuration );
host.Open();
Console.WriteLine( "Service2 started, press ENTER to stop ..." );
Console.ReadLine();
host.Close();
}