Clientidentitätswechsel und -delegierung
Unter bestimmten Umständen muss eine Serveranwendung die Identität eines Clients für Ressourcen bereitstellen, auf die sie im Auftrag des Clients zugreift, in der Regel, um Zugriffsprüfungen oder Authentifizierungen für die Identität des Clients durchzuführen. Bis zu einem bestimmten Grad kann der Server unter der Identität des Clients handeln– eine Aktion, die als Identitätswechsel des Clients bezeichnet wird.
Identitätswechsel ist die Fähigkeit eines Threads, in einem anderen Sicherheitskontext als der Prozess, der den Thread besitzt, auszuführen. Der Serverthread verwendet ein Zugriffstoken, das die Anmeldeinformationen des Clients darstellt, und kann damit auf Ressourcen zugreifen, auf die der Client zugreifen kann.
Durch den Identitätswechsel wird sichergestellt, dass der Server genau das tun kann, was der Client tun kann. Der Zugriff auf Ressourcen kann entweder eingeschränkt oder erweitert werden, je nachdem, wofür der Client über die Berechtigung verfügt.
Sie können wählen, dass ein Server beim Herstellen einer Verbindung mit einer Datenbank die Identität eines Clients angibt, damit die Datenbank den Client authentifizieren und autorisieren kann. Wenn Ihre Anwendung auf Dateien zugreift, die mit einer Sicherheitsbeschreibung geschützt sind, und damit der Client autorisierten Zugriff auf Informationen in diesen Dateien erhalten kann, kann die Anwendung vor dem Zugriff auf die Dateien die Identität des Clients annehmen.
Implementieren eines Identitätswechsels
Der Identitätswechsel erfordert die Teilnahme von Client und Server (und in einigen Fällen auch von Systemadministratoren). Der Client muss seine Bereitschaft angeben, den Server seine Identität verwenden zu lassen, und der Server muss explizit die Identität des Clients programmgesteuert annehmen. Ausführliche Informationen finden Sie in den Themen Clientseitige Anforderungen für Identitätswechsel und serverseitige Anforderungen für identitätswechsel.
Verwaltungsanforderungen für Delegate-Level Identitätswechsel
Um die mächtigste Form des Identitätswechsels effektiv zu verwenden, müssen die Client- und Serverbenutzerkonten im Active Directory-Dienst ordnungsgemäß konfiguriert sein, um sie zu unterstützen (zusätzlich zur Clientberechtigung für den Identitätswechsel auf Delegatebene):
- Die Serveridentität muss im Active Directory-Dienst als "Vertrauenswürdig für delegierung" gekennzeichnet werden.
- Die Clientidentität darf im Active Directory-Dienst nicht als "Konto ist vertraulich und kann nicht delegiert werden" gekennzeichnet werden.
Diese Konfigurationsfeatures geben dem Domänenadministrator ein hohes Maß an Kontrolle über die Delegierung, was angesichts der Vertrauenswürdigkeit (und damit des Sicherheitsrisikos) wünschenswert ist. Weitere Informationen zur Delegierung finden Sie unter Delegierung und Identitätswechsel.
Cloaking
Zusammen mit der Autorität, die ein Client einem Server über die Identitätswechselebene gewährt, bestimmt die Ummantelungsfunktion des Servers weitgehend, wie sich der Identitätswechsel verhält. Das Cloaking wirkt sich darauf aus, welche Identität tatsächlich vom Server angezeigt wird, wenn er Aufrufe im Namen des Clients durchführt – seine eigene oder die des Clients. Weitere Informationen finden Sie unter Cloaking.
Folgen für die Leistung
Der Identitätswechsel kann sich erheblich auf die Leistung und Skalierung auswirken. Es ist in der Regel teurer, bei einem Anruf die Identität eines Clients zu annehmen, als den Anruf direkt zu tätigen. Im Folgenden sind einige der zu berücksichtigenden Probleme aufgeführt:
- Der Rechenaufwand für die Weitergabe von Identitäten in komplizierten Mustern, insbesondere wenn die dynamische Ummantelung aktiviert ist.
- Die allgemeine Komplexität der Erzwingung redundanter Sicherheitsüberprüfungen an zahlreichen Stellen, anstatt nur zentral auf der mittleren Ebene.
- Ressourcen wie Datenbankverbindungen können beim Öffnen der Identität eines Clients nicht über mehrere Clients hinweg wiederverwendet werden – ein sehr großer Hindernis für eine gute Skalierung.
Manchmal besteht die einzige effektive Lösung für ein Problem darin, identitätswechsel zu verwenden, aber diese Entscheidung sollte sorgfältig abgewogen werden. Weitere Informationen zu diesen Problemen finden Sie unter Mehrschichtige Anwendungssicherheit.
Komponenten in Warteschlange
In Warteschlange befindliche Komponenten unterstützen keinen Identitätswechsel. Wenn ein Client ein Objekt in der Warteschlange aufruft, erfolgt der Aufruf tatsächlich an den Rekorder, der es als Teil einer Nachricht an den Server packt. Der Listener liest dann die Nachricht aus der Warteschlange und übergibt sie an den Player, der die eigentliche Serverkomponente aufruft und denselben Methodenaufruf ausgibt. Wenn also der Server den Anruf empfängt, ist das ursprüngliche Clienttoken durch Identitätswechsel nicht verfügbar. Rollenbasierte Sicherheit gilt jedoch weiterhin, und die programmgesteuerte Sicherheit über die ISecurityCallContext-Schnittstelle funktioniert. Weitere Informationen finden Sie unter Sicherheit von Komponenten in Warteschlange.
Zugehörige Themen