concepts:identityandaccesscontrol:authentication
Differences
This shows you the differences between two versions of the page.
|
concepts:identityandaccesscontrol:authentication [2013/01/02 16:57] 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 32: | Line 34: | ||
| * Die Aktion wird dann für den Mitarbeiter autorisiert | * 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.1357142229.txt.gz · Last modified: 2013/01/02 16:57 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
