concepts:identityandaccesscontrol:authentication
Differences
This shows you the differences between two versions of the page.
|
concepts:identityandaccesscontrol:authentication [2013/01/02 16:48] rtavassoli |
concepts:identityandaccesscontrol:authentication [2013/06/26 16:33] (current) rtavassoli [Authentifizierung] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Authentifizierung ====== | ====== Authentifizierung ====== | ||
| Das ist gar kein so leichtes Thema. Wenn wir uns P.A.C.((Vorgänger von PRO•M)), bzw. PRO•M 1.0 angucken, dann wird einiges vermischt, ohne es explizit zu machen, was dort vermischt wird. | Das ist gar kein so leichtes Thema. Wenn wir uns P.A.C.((Vorgänger von PRO•M)), bzw. PRO•M 1.0 angucken, dann wird einiges vermischt, ohne es explizit zu machen, was dort vermischt wird. | ||
| + | ===== Key Koncepts ===== | ||
| + | siehe [[http://msdn.microsoft.com/en-us/library/z164t8hs.aspx]] | ||
| ===== Benutzerkonten ===== | ===== Benutzerkonten ===== | ||
| Es gibt das Benutzerkonto. Ein Konto wird einer Rechtegruppe zugeordnet, über die das Konto bestimme Zugriffsrechte erhält. Zudem kann das Konto einer Adresse((Mitarbeiter, Debitor, Kreditor, Organisationseinheit)) zugeordnet werden: | Es gibt das Benutzerkonto. Ein Konto wird einer Rechtegruppe zugeordnet, über die das Konto bestimme Zugriffsrechte erhält. Zudem kann das Konto einer Adresse((Mitarbeiter, Debitor, Kreditor, Organisationseinheit)) zugeordnet werden: | ||
| Line 25: | Line 27: | ||
| === Impersonierung explizit machen === | === Impersonierung explizit machen === | ||
| Man müsste am Modell nichts ändern. Authentifiziert wird weiterhin nur das Benutzerkonto. Nach der Anmeldung wird zudem((wie auch jetzt)) abgefragt, wen das Benutzerkonto impersonieren darf. Wenn dann z.B. //eigene// Zeitdatensätze erfasst werden, schickt das Front-End die ID des Mitarbeiters mit, für den die Zeitdatensätze gelten. Die Autorisierungsstelle für Zeitdaten benötigt den Mitarbeiter als Ressource, d.h. sie muss prüfen, ob die authentifizierte Ressource((in diesem Fall der Mitarbeiter)), die den Befehl sendet, dem Mitarbeiter entspricht, für den der Zeitdatensatz gilt. Die authentifizierte Ressource ist aber ein Benutzerkonto, und kein Mitarbeiter. Daher müsste erst geprüft werden, ob das Benutzerkonto den Mitarbeiter impersonieren kann((es wird implizit davon ausgegangen, dass das Konto auch den Mitarbeiter impersonieren möchte, für den der Zeitdatensatz gilt, und nicht für einen anderen)). Danach kann die Aktion für den Mitarbeiter autorisiert werden. | Man müsste am Modell nichts ändern. Authentifiziert wird weiterhin nur das Benutzerkonto. Nach der Anmeldung wird zudem((wie auch jetzt)) abgefragt, wen das Benutzerkonto impersonieren darf. Wenn dann z.B. //eigene// Zeitdatensätze erfasst werden, schickt das Front-End die ID des Mitarbeiters mit, für den die Zeitdatensätze gelten. Die Autorisierungsstelle für Zeitdaten benötigt den Mitarbeiter als Ressource, d.h. sie muss prüfen, ob die authentifizierte Ressource((in diesem Fall der Mitarbeiter)), die den Befehl sendet, dem Mitarbeiter entspricht, für den der Zeitdatensatz gilt. Die authentifizierte Ressource ist aber ein Benutzerkonto, und kein Mitarbeiter. Daher müsste erst geprüft werden, ob das Benutzerkonto den Mitarbeiter impersonieren kann((es wird implizit davon ausgegangen, dass das Konto auch den Mitarbeiter impersonieren möchte, für den der Zeitdatensatz gilt, und nicht für einen anderen)). Danach kann die Aktion für den Mitarbeiter autorisiert werden. | ||
| + | \\ \\ | ||
| + | Zusammengefasst((Zurzeit gibt es eine Autorisierungsstelle für Aktionen im Kontext des Benutzerkontos und im Kontext des Mitarbeiters. Das ist ein //big ball of mud//, und es ist //schöner// das in mehrere Kontexte aufzuteilen, daher diese komplexe Analyse)): | ||
| + | * Ein Zeitdatensatz für einen Mitarbeiter darf nur von dem Mitarbeiter selbst erfasst werden, | ||
| + | * Authentifiziert ist ein Benutzerkonto, | ||
| + | * Die Mitarbeiterauthentifizierungsstelle prüft nun, ob das Benutzerkonto den Mitarbeiter impersonieren darf((Hier werden die 2 getrennten Kontexte wieder zusammengeführt, d.h. es muss eine Schnittstelle geben, die diese Impersonation vom Benutzerkonto-Kontext zum Mitarbeiterkontext herstellt)), | ||
| + | * Die Aktion wird dann für den Mitarbeiter autorisiert | ||
| === Mehrfachauthentifizierung === | === Mehrfachauthentifizierung === | ||
| + | Für manche Rechteprüfungen muss //ich// wissen, welches Benutzerkonto Urheber der Aktion ist, für andere muss ich wissen, welcher Mitarbeiter Urheber der Aktion ist. Es gibt sogar Fälle, in denen eine Aktion von beiden Autorisierungsstellen geprüft wird. Ein Benutzerkonto kann z.B. allgemeine Rechte haben((z.B. //darf Alles genehmigen//)), ein Mitarbeiter Projektspezifische. Die Autorisierung der Aktion wird in diesem Fall verkettet. Dafür muss es zwei authentifizierte Ressourcen geben. | ||
| + | \\ \\ | ||
| + | Die Applikation meldet sich hierfür zunächst mit dem Benutzerkonto an. Dann wird das Benutzerkonto dazu verwendet, dass sie sich mit dem Mitarbeiter anmeldet. Dafür gibt es eine eigene Mitarbeiter-Authentifizierungsstelle, die einfach die authentifizierten Daten eines Benutzerkontos verwendet, um den Mitarbeiter zu authentifizieren. | ||
| + | \\ \\ | ||
| + | Die zweite Authentifizierungsstelle muss somit der ersten vertrauen. Über ein einfaches Mapping((wie z.B. zurzeit, eine einfache Referenz vom Benutzerkonto zum Mitarbeiter)) kann definiert werden, welcher Mitarbeiter mit welchem Benutzerkonto authentifiziert werden kann. | ||
| === Benutzerkonto und Person zusammenführen === | === Benutzerkonto und Person zusammenführen === | ||
| - | + | Das scheint am sinnvollsten. Die Diskussion der ersten beiden Möglichkeiten hat gezeigt, dass die aktuelle Trennung recht künstlich ist. | |
| - | + | ||
| - | + | ||
concepts/identityandaccesscontrol/authentication.1357141700.txt.gz · Last modified: 2013/01/02 16:48 by rtavassoli
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
