Damit lässt sich bereits vieles recht einfach ausdrücken. Will man jedoch bei der Entscheidung über den Zugriff auf eine Methode deren Parameter einbeziehen („Ein Kassierer darf maximal 10.000 Euro überweisen“) oder den Zustand der Bean-Instanz („Ein Kunde darf nur den Kontostand seines eigenen Kontos sehen“), muss man die entsprechenden Tests in den Programmcode einfügen. J2EE standardisiert dazu eine Schnittstelle, die Zugriffe auf die Identität des Aufrufers und seine Zugehörigkeit zu Rollen erlaubt. Diese Tests sind dann allerdings bei der Installation nicht konfigurierbar.

Neben Vertraulichkeit auch Integrität prüfen

Neben Authentifizierung und Autorisierung spielt die Sicherung der Daten beim Transport eine wesentliche Rolle. J2EE verwendet hier den Standard SSL, um die Kommunikation zwischen Client und Server zu verschlüsseln. Per Konfiguration lässt sich wählen, ob nur Vertraulichkeit oder auch Integrität der Daten sichergestellt werden sollen. Für zukünftige Fassungen des J2EE-Standards sind Verbesserungen in den Bereichen Instanz-basierende Zugriffskontrolle, Auditing, Management und dynamische Benutzerregistrierung geplant.

Diese Betrachtungen zeigen, dass Authentisierung, Autorisierung und Transportsicherheit bis zu einem gewissen Umfang konfiguriert werden können. Die Web- beziehungsweise EJB-Container sorgen zur Laufzeit dafür, dass die konfigurierten Restriktionen auch tatsächlich eingehalten werden. Dies führt zu einem recht einfachen Programmiermodell und zu hoher Flexibilität. In der Praxis wird man jedoch häufig zusätzliche Aspekte von Hand programmieren müssen. Der J2EE- Standard definiert dazu die nötigen Schnittstellen. J2EE-konforme Applikations-Server bieten diese Standard-Features an, wobei man berücksichtigen muss, dass nur wenige Produkte die aktuelle Version 1.3 erfüllen. Benötigt man darüber hinausgehende Features, muss man auf spezielle Sicherheitswerkzeuge von Anbietern ausweichen, die mit den Herstellern von Applikations-Servern kooperieren.

Einige Bereiche lassen noch zu wünschen übrig. Die in der Spezifikation EJB 2.0 neu hinzugekommenen Message Driven Beans etwa sind noch gar nicht in die Sicherheitsarchitektur integriert. Außerdem fehlt es etwa an Tipps, Beispielen und Tutorials, die eine „richtige“ Verwendung des Sicherheitsmodells zeigen. Das J2EE-Referenzbeispiel Petstore von Sun verwendet auf Web-Ebene nur in geringem Maße und auf EJB-Ebene keinerlei Zugriffskontrolle. Das offenbart zwei wesentliche Schwachstellen des J2EE-Sicherheitsmodells. Zum einen ist es sehr schwierig, die Zugriffskontrolle zwischen Web- und EJB-Ebene zu koordinieren. Beschränkt man sich auf die Web-Ebene, liegen die EJB-Komponenten offen für Zugriffe von Applikations- oder Web-Service-Clients. Konzentriert man sich auf die EJB-Ebene, wird es schwierig, benutzerfreundliche Oberflächen zu gestalten. Verwendet man beide Ebenen, ist es problematisch, ein stimmiges

Zusammenspiel zu erreichen.