Kann jemand auf Beispielcode verweisen, um aktiv ein RequestSecurityToken unter Verwendung der NT-Anmeldeinformationen von Thread.CurrentPrincipal as ClaimsPrincipal ? zu erstellen?
Das Szenario ist eine asp.net-Webanwendung mit aktivierter Windows-Authentifizierung (es gibt also eine authentifizierte WindowsIdentity). Mein Wunsch ist es, den STS aktiv aufzurufen, anstatt passiveRedirect zu aktivieren, und dies mithilfe der .Net 4.5-Identitätsbibliotheken zu tun.
Die meisten Codebeispiele, z. B. Claims Helper für Windows Phone oder Verwenden Sie einen Active STS , um die Anmeldeinformationen mit einem Benutzernamen / pwd-Eingang und UserNameWSTrustBinding zu versehen.
Ich dachte, die Lösung könnte einen Identitätswechsel oder einen Aufruf von channelFactory.CreateChannelWithActAsToken() mit einem aus der Windows-Identität erstellten Token beinhalten.
- Der folgende .Net4.5-Code erhält einen GenericXmlSecurityToken, wenn er auf einen / adfs / services / trust / 13 / windowsmixed-Endpunkt trifft. Die Ansprüche beziehen sich jedoch auf das Domänenkonto, unter dem die Site ausgeführt wird, und nicht auf das Domänenkonto des authentifizierten Benutzers. Wenn ich den Endpunkt nach / adfs / services / trust / 13 / kerberossmixed umschalte, bekomme ich Fehler "kann nicht verhandeln", wie in mehreren Fragen und Foren dokumentiert, aber ich kann keine angebotenen Lösungen mit .Net 4.5 anwenden. Eine der Klassen, die von Microsoft.IdentityModel nicht portiert wurde, ist KerberosWSTrustBinding ...
%Vor%Für den @leastprivilege-Vorschlag füge ich diesen Code hinzu:
%Vor%Dies schlägt fehl mit "Der Anrufer wurde vom Dienst nicht authentifiziert". Dieselbe STS authentifiziert mein Domänenkonto in einem passiven Umleitungsszenario ... also obwohl ich weiß, dass ich etwas falsch mache, sollte das Konto selbst erkannt werden.
Aktualisierung:
Ich habe eine Benachrichtigung erhalten, dass diese Frage eine beachtliche Anzahl von Ansichten erhalten hat. Daher werde ich Folgendes als eine Umgehungslösung anbieten: Obwohl wir unsere Server für Delegation konfiguriert haben (wie Dominick unten vorgeschlagen hat), haben wir das Double-Hop-Problem immer noch nicht überwunden. Wenn ich mich recht erinnere, haben wir eine Blockade durch einfache Netzwerkmanagement-Richtlinien über unserer lokalen IT, die auch jedes Unternehmen treffen könnte. Während die Identitätsübernahme über einen Double-Hop gegen einen Server mit Windows-Authentifizierung nicht zulässig ist, können Anmeldeinformationen über einen doppelten Hop mit der Standardauthentifizierung imitiert werden. Dies kann eine akzeptable Situation sein oder auch nicht (Intranet für unseren Fall). Wenn Sie dies tun, würden Sie
hinzufügen %Vor%zur obigen ChannelBinding-Konfiguration.
Nun - das ist eigentlich nicht trivial. Sie müssen Kerberos-Identitätswechsel und Delegierung dafür durchführen.
Vor allem Identitätswechsel. Sie müssen Impersonate () auf der WindowsIdentity aufrufen, die Sie von Thread.CurrentPrincipal erhalten.
Sie können sicherstellen, dass Sie sich imitieren, indem Sie WindowsIdentity.GetCurrent aufrufen. Diese Identität muss dann auf den Client verweisen (im Gegensatz zur Serveridentität).
Dann müssen Sie während der Identitätsübernahme die WS-Trust-Anfrage stellen. Dies ist höchstwahrscheinlich nicht standardmäßig erlaubt. Daher muss der Netzwerkadministrator die Delegierung für die Serveridentität an den STS konfigurieren.