Bei der durch Web-Container verwalteten Sicherheit wird die die Verantwortung für Benutzerauthentifizierung und Berechtigung auf den Container übertragen, wodurch der EGL-Entwickler sich auf die Geschäftslogik konzentrieren kann.
Die zwei gängigen Typen der JEE-Authentifizierung sind die JEE-Basisauthentifizierung und die formularbasierte Authentifizierung. Wenn bei der JEE-Basisauthentifizierung (wird auch als HTTP-Basisauthentifizierung bezeichnet) ein Client, wie beispielsweise ein Browser, eine Webseite von einem Server anfordert, ohne eine Benutzer-ID mit zugehörigem Kennwort anzugeben, sendet der Server den Antwortcode 401 zurück. Der Client fordert den Benutzer anschließend zur Angabe einer Benutzer-ID mit zugehörigem Kennwort an, indem dem Benutzer eine Standardanmeldeanzeige angezeigt wird. Der Client sendet die Anforderung erneut an den Server und schließt die Benutzer-ID und das zugehörige Kennwort im HTTP-Header ein. Wenn der Benutzer sich authentifiziert hat, gibt der Server die angeforderte Seite zurück. Wenn Benutzer-ID und Kennwort ungültig sind, gibt der Server den Antwortcode 401 zurück und der Client fordert den Benutzer erneut zur Eingabe auf. Bei der formularbasierten JEE-Authentifizierung können Sie eine angepasste Anmeldeanzeige verwenden, die die Darstellung und die Funktionsweise der Anwendung verwendet, statt die vom Browser bereitgestellte Anmeldeanzeige. Die Benutzer-ID und das zugehörige Kennwort werden in den Formulardaten und nicht im HTTP-Header der Anforderung an den Server übergeben.
Die JEE-Sicherheit verwendet Rollen, um den Zugriff auf Ressourcen zu verwalten. Für bestimmte Rollen wird der Zugriff auf bestimmte Ressourcen zugelassen. Benutzer und Gruppen sind zu geeigneten Rollen zugeordnet. Beispielsweise kann der Benutzer 'Bob' dem Rollenadministrator zugeordnet sein.
Die JEE-Berechtigung kann deklarativ oder programmorientiert sein. Die deklarative Berechtigung ist verfügbar, weil Sicherheitsinformationen in Implementierungsdeskriptoren angegeben sind. Die Anwendungsserver greifen auf diese Implementierungsdeskriptoren zu, um zu ermitteln, ob ein bestimmter Benutzer einer Rolle zugeordnet wurde und entscheiden, ob von dieser Rolle auf eine bestimmte Ressource zugegriffen werden kann. Während die JEE-Sicherheit auch die programmorientierte Berechtigung durch die Verwendung von APIs wie beispielsweise isUserInRole() einschließt, stehen diese Funktionen innerhalb einer Rich UI-Anwendung nicht zur Verfügung. Daher sollte die Berechtigung für Rich UI-Anwendungen entweder deklarativ oder mithilfe von angepasstem, vom Benutzer bereitgestellten Code erfolgen.
Benutzerregistrys wie LDAP-Verzeichnisserver (Lightweight Directory Access Protocol) oder mit JEE-Sicherheit verwendete relationale Datenbanken sind für die JEE-Umgebung extern. Ein Systemadministrator muss Verwaltungsaufgaben ausführen, wie das Hinzufügen von neuen Benutzern zum Repository.
Während die JEE-Sicherheit über WebSphere Application Server und Apache Tomcat zur Verfügung steht, ist sie über die Workbench nicht verfügbar. Sie müssen eine Rich UI-Anwendung in WebSphere oder Tomcat implementieren, um die Sicherheit anzuwenden und zu testen.
Zum Ermitteln, ob die JEE-Sicherheit für Ihre Situation geeignet ist, lesen Sie die Dokumentation in diesem Kapitel und die detailliertere Onlinedokumentation zu Ihrem Anwendungsserver.
Wenn die durch Web-Container verwaltete Sicherheit für Ihre Anforderungen nicht geeignet ist, können Sie in Ihrer Rich UI-Anwendung eine angepasste Sicherheit erstellen. Obwohl für die angepasste Sicherheit erforderlich ist, dass Sie Ihrer Rich UI-Anwendung sicherheitsrelevanten Code hinzufügen, kann damit nicht vermieden werden, dass die JEE-Sicherheit allein nicht ausreichend ist, um das Sicherheitsmodell einer Anwendung wiederzugeben. Wenn Sie möchten, können Sie beide Formen der Sicherheit kombinieren.
Die angepasste Berechtigung kann eine differenziertere Berechtigungsstufe bereitstellen, als JEE-Rollen. Möglicherweise möchten Sie die angepasste Sicherheit zum Authentifizieren von Benutzern verwenden, bevor diese auf eingeschränkte Teile Ihrer Anwendung zugreifen können.