hochgradige Java open Source nahe Diskussion erfindet Notes Autorisierung nach:

[Marinero Atlántico]

Hi,

viele in Notes enthaltenen Konzepte wurden wirklich schlau ausgedacht.
<ich_mach_nur_spass>
Vermutlich begann Ed Brills steile Karriere in jener Zeit erst und er hatte zunächst die Aufgabe als Praktikant die Jogurt-Becher in der Kantine auszuspülen. Die anderen konnten also in Ruhe arbeiten und mussten nicht den ganzen Tag sagen: Yes. Ed. Microsoft guys are plain evil: They produce crapy technology and they tell lies about Notes whole day.
</ich_mach_nur_spass>

Zum Beispiel das Autorisierungskonzept:
Es gibt adressbuchgebundene Personen.
Diese Personen können adressbuchgebundenen Gruppen angehören.
Und pro Anwendung gibt es Rollen, weil das einfacher zu managen ist, als die sehr globalen Gruppen.
In der ACL können den Gruppen/Personen den Rollen zugewiesen werden.
In der Anwendung kann der Zugriff auf Ressourcen an Personen/Gruppen/Rollen gebunden werden.
Wir alle wissen, dass Rollen im Hinblick auf eine einfache Pflege der Autorisierungen in der Anwendung sehr gut sein können.  

Nun gibt es im Enterprise Java Forum theserverside.com eine Diskussion, die sich weitgehend um Autorisierungskonzepte dreht.
http://www.theserverside.com/news/thread.tss?thread_id=26961

Der als sehr schlau geltende Rickard Oberg erfindet quasi das Notes-Autorisierungs-Konzept 1 zu 1 nach:

I've found that mapping to permissions instead of principals is not enough. If you've got 100+ principals, and 50+ permissions (and our app do), then you're going to get problems with the overhead of the security administration.

Principals sind in Java Authentification and Authorization Service NAB LDAP gebundene Personen oder Gruppen.

Permissions sind besondere Zugriffsberechtigungen für bestimmte Ressourcen (etwa: darf mit Maske Dokument erstellen, darf Feld sehen, darf Ansicht sehen, darf Navigator sehen, darf Agent starten etc.).

The solution we're using right now is to also introduce roles, which is an aggregation of permissions. Roles can then be assigned to principals, which may be single users or groups of users. This way a security administrator can do the typically difficult work of creating roles (e.g. "Admin role may do create,update,start,assign role. User role may only do update"), and "normal" administrators can then assign these roles to principals. If the system introduces more permissions it is then simply a matter of updating the roles with these new permissions, instead of having to assign the new permissions to all principals throughout the system.

und dann noch

Overall this solution seems to minimize the overhead of doing security administration and makes it manageable even for large number of permissions, large number of principals, and a large number of objects. The task of doing security administration is often quite tedious, so effort should be spend on doing it as easily as possible, or it won't be done properly.

ja. wir wissen das.

Oberg benutzt hierfür Bleeding Edge Technologie:

We solved this problem generically by using AOP. We implemented an ACL aspect, which contains the role->principal mappings, and introduce it on all objects which we want to assign security restrictions on.

Gruß Axel