5.3 EJB Security. Client/Server-Komponententechnologie basierend auf Java. Enterprise Java Beans sind Komponenten der Geschäftsapplikation.

Transkript

1 5.3 EJB Security Client/Server-Komponententechnologie basierend auf Java. Enterprise Java Beans sind Komponenten der Geschäftsapplikation. Applikations-Server führen EJBs in Containern aus. Applikations-Server interagiert mit Systemressourcen (z.b. Datenbank) und verteilten Beans auf anderen Servern. Der Applikations-Server handhabt die Sicherheitseinstellungen. Enterprise Java Beans (EJB) sind eine Client/Server-Komponententechnologie für die Entwicklung und das Deployment verteilter Komponenten basierend auf der Java-Plattform. Enterprise Java Beans sind Komponenten der Geschäftsapplikation, z.b. Kunde, Auftrag, Rechnung etc und werden von Applikations-Servern in Containern ausgeführt. Der Applikationsserver bzw. der Container interagiert mit den Systemressourcen (z.b. Datenbank) und übernimmt auch die Interaktion mit verteilten Beans in anderen Servern. Außerdem kontrolliert der Applikationsserver die Sicherheitseinstellungen. 1

2 5.3 EJB Security Es gibt drei Arten von EJBs Session Bean: Bearbeitet Anfragen eines Clients in einer Session. Ist nicht persistent. Es wird zwischen Stateless Session Beans ( keinem speziellen Client zugeordnet) und Stateful Session Beans (einem Client zugeordnet) unterschieden. Entity Bean: Geschäftsobjekt-Komponente die persistent gehalten wird (z.b. in Datenbank) Message-Driven Bean: Reagiert auf Nachrichten und wird erst beim Eintreffen einer Nachricht aktiv. Es gibt prinzipiell drei Arten von Enterprise Java Beans: Session Bean: Führt Anfragen eines Clients während einer Session aus und beschäftigt sich ausschließlich mit dem Client. Es existiert nur für die Zeit der Session (nicht persistent). Es kann Schritte und Daten der Interaktion zwischenspeichern (z.b. Einkaufswagen). Entity Bean: Eine Geschäftslogik-Komponente, die persistent gehalten werden muss (meist mit Datenbanken über JDBC). Message-Driven Beans: Werden nicht über Schnittstellen angesprochen, sondern reagieren auf Nachrichten. Die Bean wird nur beim Eintreffen einer Nachricht aktiv. 2

3 5.3 EJB Security Zum Erstellen eines EJBs ist folgendes zu tun: Remote Interface Schnittstelle mit den Operationen, die ein Client aufrufen kann. Home Interface Operationen zum Lifecycle-Management (Erzeugen, Zerstören etc.). Dient als Factory. Bean Implementation Implementiert die Operationen des Remote Interface. Deployment-Deskriptor (in XML) Defniert das Bean mit den Informationen, die für das Deployment des Bean relevant sind. Um eine EJB zu erstellen, müssen folgende Java-Dateien erstellt werden: Remote Interface definiert die Operationen die von Clienten aufgerufen werden können. Das Home Interface dient als Factory. Es enthält beispielsweise Operationen für das Lifecycle-Management der Bean wie seine Erzeugung oder Zerstörung. Der EJB Container erzeugt dann die Instanzen der Bean. Die Bean implementation implementiert die Operationen, die im Remote Interface spezifiziert sind. Außerdem muss die Bean im XML-Deployment-Deskriptor definiert werden. Der Deployment-Deskriptor enthält relevante Informationen für das Deployment der Bean auf dem EJB-Server. Der Deskriptor ist als XML-Datei implementiert. 3

4 5.3 EJB Security 1: frage nach Home Object Reference Client Naming Service 3: erzeuge EJB Object 5: EJB Reference 6: Methodenaufruf 2:Home Object Reference Home Interface Remote Interface EJB Container/Server Home Object 4: erzeuge EJB Object EJB Object Die Folie zeigt den grundlegenden Aufbau für den Aufruf von EJB Komponenten. Eine Client- Anwendung benutzt einen Namensservice (naming service) zum Aufruf eines EJBs, welches sich in einem EJB-Container befindet. Der EJB-Container stellt eine Laufzeitumgebung für EJBs zur Verfügung. Der Standard-Ablauf beim Aufruf eines EJBs auf dem Server sieht wie folgt aus: 1. Der Client erhält die EJB Home Object Reference mittels des Naming Service, der üblicherweise vom Applikationsserver zur Verfügung gestellt wird. 2. Der Naming Service gibt die EJB Home Object Reference zurück, die vom Client benötigt wird, um eine EJB Instanz zu erzeugen. 3. Nachdem das EJB Home Object bekannt ist, erzeugt der Client eine Instanz des EJBs durch einen Aufruf der entsprechenden Operation des Home Interfaces. 4. Das EJB Home Object erzeugt das EJB Object. 5. Eine Referenz auf das EJB Home Object wird dem Clienten zurückgeliefert. 6. Nachdem das EJB Object erzeugt wurde, kann der Client die Methoden des EJBs mittels des EJB Object Remote Interfaces aufrufen. 4

5 5.3 EJB Security Remote Interface HelloWorld.java package helloworld; import javax.ejb.ejbobject; import java.rmi.remoteexception; // remote interface for `HelloWorld' EJB. public interface HelloWorld extends EJBObject { public void sayhello() throws RemoteException; } Auf den folgenden Folien ist ein Hello World Beispiel gezeigt, welches die Schritte zur Erstellung eines Stateless Session Beans zeigt. Zunächst wird das Remote Interface definiert. In diesem Beispiel gibt es eine Schnittstellenoperation sayhello(). Remote Interfaces sind immer von EJBObject abgeleitet. 5

6 5.3 EJB Security Home Interface HelloWorldHome.java package helloworld; import java.io.serializable; import java.rmi.remoteexception; import javax.ejb.createexception; import javax.ejb.ejbhome; // Home interface for the HelloWorld EJB. public interface HelloWorldHome extends EJBHome { // Creates an instance of the HelloWorldBean class on the server. HelloWorld create() throws RemoteException, CreateException; } Das Home Interface enthält nur eine Operation zum Erzeugen eines HelloWorld-Beans. Das Home Interface erweitert immer EJBHome. 6

7 5.3 EJB Security Bean Implementation - HelloWorldBean.java package helloworld; import java.rmi.remoteexception; import javax.ejb.sessionbean; import javax.ejb.sessioncontext; public class HelloWorldBean implements SessionBean { public void sayhello() { System.out.println("Hello World"); }... Die Operationen des Remote Interfaces werden in der Bean Implementation Klasse implementiert. Da wir nur die Operation sayhello() im Remote Interface haben, ist auch nur diese zu implementieren. Wir implementieren die Bean als Session Bean. Das die Session Bean stateless ist, wird erst im Deployment Descriptor angegeben. Neben den Operationen im Remote Interface müssen möglicherweise weitere Operationen implementiert werden (z.b. muss für jede create() Operation im Home Interface die Operation ejbcreate() und ejbpostcreate() implementiert werden). 7

8 5.3 EJB Security Deployment Descriptor ejb-jar.xml <ejb-jar> <description>helloworld example EJB</description> <display-name>helloworld EJB</display-name> <enterprise-beans> <session> <ejb-name>helloworld</ejb-name> <home>helloworld.helloworldhome</home> <remote>helloworld.helloworld</remote> <ejb-class>helloworld.helloworldbean</ejb-class> <session-type>stateless</session-type> </session> </enterprise-beans> </ejb-jar> Der Deployment Descriptor (ejb-jar-xml) ist eine XML-Datei, die die Informationen zu den Enterprise Beans zusammenfasst, die zum Deployment auf dem Applikations-Server notwendig sind. Die Informationen zu einem EJB werden innerhalb des Elements <enterprisebean> spezifiziert. Dazu gehört der Name, unter dem die Bean im Container bekannt sein soll (<ejb-name>), das Home Interface (<home>), das Remote Interface (<remote>) und die Implementierung der Bean (<ejb-class>). Bei session beans kann auch der Session-Typ angegeben werden (als Wert des Elements <session-type>, entweder stateless oder stateful). 8

9 5.3 EJB Security Client package helloworld; import javax.naming.initialcontext; import javax.rmi.portableremoteobject; import helloworld.helloworld; import helloworld.helloworldhome; public class HelloWorldClient { public static void main(string[] args) { try { // Get a naming context InitialContext jndicontext = new InitialContext(); Nachdem die Bean auf dem Applikations-Server installiert wurde, können sich Clienten an den Server wenden und auf die Bean zugreifen. Dazu muss sich der Client erst den Namenskontext holen, um von dort eine Referenz auf das Bean Home Interface zu erfragen. 9

10 // Get a reference to the Bean's Home interface Object ref = jndicontext.lookup("helloworld"); HelloWorldHome home = (HelloWorldHome) PortableRemoteObject.narrow(ref, HelloWorldHome.class); // Invoke creation of remote Bean-instance HelloWorld helloworld = home.create(); // call the method sayhello() helloworld.sayhello(); } catch (Exception e) { System.out.println(e.toString()) }; Nachdem der Client den Namenskontext hat, fragt er nach der Referenz auf das Home Interface der Bean. Dazu benutzt der Client den Namen der Bean, der im Deployment Descriptor im Element <ejb-name> angegeben ist. Da der Namenskontext nur eine Referenz vom Typ Object liefert, wird diese noch zum richtigen Typ umgewandelt. Auf dem Home Interface kann der Client dann die Operation zum Erzeugen einer Bean-Instanz aufrufen. Auf dieser Instanz können dann die Operationen des Remote Interface aufgerufen werden. In diesem Beispiel ruft der Client die Operation sayhello() auf. 10

11 5.3 EJB Security Beteiligte am Lebenszyklus eines EJBs: Bean Provider: Programmiert das Bean. Application Assember: Stellt aus Beans eine Anwendung zusammen. Bean Deployer: Konfiguriert einen Applikationsserver mit dem Bean Beteiligte haben verschiedene Aufgaben bzgl. Sicherheit. Die EJB-Spezifikation sieht prinzipiell drei Beteiligte am Lebenszyklus eines EJBs vor. Der Bean Provider programmiert die Bean, der Application Assembler stellt aus den Beans eine Anwendung zusammen und der Bean Deployer legt die Bean auf einen Applikationsserver, auf dem sie ausgeführt werden kann. Diese drei Beteiligten haben verschiedene Aufgabengebiete in Bezug auf die Systemsicherheit. 11

12 5.3 EJB Security EJB Sicherheitsarchitektur hat eine Trennung zwischen Sicherheitsund Anwendungslogik. Application Assembler definiert Rollen (security roles) für die Anwendung und weist Methoden-Aufrufrechte (method permissions) zu deklarativ im Deployment-Deskriptor Deployer ordnet den Rollen Principals zu. Ein Principal ist ein Serverseitiges Objket, das an authentifizierte Benutzer gebunden wird. Client darf Methode eines EJBs aufrufen, wenn der zugeordnete Principal eine entsprechende Rolle hat. Container Provider muss die Sicherheitsstrategie durchsetzen. Generell kann man sagen, dass die EJB-Architektur die Sicherheitslogik von der Anwendungslogik trennt, d.h. der Bean Provider soll die Sicherheitsstrategie nicht in die Anwendungslogik integrieren. Der Application Assembler definiert die Sicherheits-Rollen der EJB-Anwendung. Eine Rolle ist (wie im RBAC-Modell definiert) eine Gruppierung von Rechten, die ein Benutzer braucht, um die Anwendung auszuführen. Der Application Assembler definiert (deklarativ in einem Deployment Descriptor) die Methoden-Erlaubnisse (method permissions) für jede Rolle. Der Deployer ist dafür verantwortlich die Principals (oder Gruppen von Principals) zu den vom Application Assembler definierten Rollen zuzuordnen. Ein Principal ist ein Server-seitiges Objekt, dass mit dem authentifizierten Benutzer verbunden wird. Der Principal ist in der Regel der Aufrufer (caller) der Methode. Zur Laufzeit wird einem Clienten nur dann erlaubt eine Methode aufzurufen, wenn der mit dem Clienten verbundene Principal mindestens eine Rolle hat, die ihm die Erlaubnis zum Aufruf der Methode gibt bzw. der Application Assembler hat keine Zugriffsschutzbeschränkungen für die Methode spezifiziert. Der Container Provider ist dafür verantwortlich die Sicherheitsstrategie zur Laufzeit durchzusetzen. 12

13 5.3 EJB Security Sicherheitsaufgaben des Bean Provider Soll möglichst wenig mit Sicherheit konfrontiert werden, Konzentration auf Geschäftslogik. Sicherheitslogik soll nicht hart im Code eingebettet werden. Aber: Einfache Schnittstellen zum Zugriff auf den Sicherheitskontext des EJBs. Der Bean Provider soll so wenig wie möglich mit Sicherheitsfragen belangt werden und die Sicherheitspolitik soll nicht hart im Code des Beans eingebettet werden. Der Bean Provider soll sich auf die Umsetzung der Geschäftsabläufe konzentrieren. In bestimmten Fällen kann es jedoch vorkommen, dass Sicherheitsaspekte im Bean implementiert werden müssen. Für diesen Fall ist es dem Bean Provider über einfache Schnittstellen möglich, auf den Sicherheitskontext eines EJBs zuzugreifen. 13

14 5.3 EJB Security Schnittstelle javax.ejb.ejbcontext besitzt zwei Methoden zum Zugriff auf Sicherheitsmethoden public interface javax.ejb.ejbcontext { java.security.principal getcallerprincipal(); boolean iscallerinrole( String rolename ); } Die Schnittstelle javax.ejb.ejbcontext besitzt zwei Methoden, die es dem Bean Provider erlauben, Sicherheitsinformationen über den Aufrufer (caller) des EJBs zu erlangen. Mit dem Aufrufen der Methode getcallerprincipal() innerhalb einer EJB-Methode kann der Principal bestimmt werden, der die EJB-Methode aufgerufen hat. Mittels der Methode getname() des Objektes java.security.principal kann dann der Name des Principals bestimmt werden. Eine EJB-Methode kann mit der Methode iscallerinrole() testen, ob der Aufrufer der EJB-Methode eine bestimmte Rolle besitzt. 14

15 5.3 EJB Security Beispiel für getcallerprincipal() public class EmployeeServiceBean implements SessionBean { EJBContext ejbcontext; public void changephonenumber(...) {... Context initctx = new InitialContext(); Object result = initctx.lookup("java:comp/env/ejb/emplrecord"); EmployeeRecordHome emplrecordhome = (EmployeeRecordHome) javax.rmi.portableremoteobject.narrow(result, EmployeeRecordHome.class); // obtain the caller principal. callerprincipal = ejbcontext.getcallerprincipal(); Ein Beispiel für den Einsatz der Operation getcallerprincipal() zeigt diese Folie. Im Beispiel wird die Telefonnummer des Aufrufers der Methode geändert. Zunächst wird mit der Operation getcallerprincipal() der Principal des Aufrufers der Methode betsimmt. 15

16 // obtain the caller principal s name. callerkey = callerprincipal.getname(); // use callerkey as primary key to EmployeeRecord finder EmployeeRecord myemployeerecord = emplrecordhome.findbyprimarykey(callerkey);...}} // update phone number myemployeerecord.changephonenumber(...); Danach wird der Name des Principals mittels der Operation getname() ermittelt. Dieser Name dient als primärer Schlüssel in einer Datenbank und ein Bean für das zum primären Schlüssel gehörende Datenbank-Tupel wird erzeugt. Auf diesem kann dann die Operation zum Ändern der Telefonnummer aufgerufen werden. 16

17 5.3 EJB Security Beispiel für iscallerinrole() public class PayrollBean... { EntityContext ejbcontext; public void updateemployeeinfo(emplinfo info) { oldinfo =... read from database; // The salary field can be changed only by callers // who have the security role "payroll" }} if (info.salary!= oldinfo.salary &&!ejbcontext.iscallerinrole("payroll")) { throw new SecurityException(...); } Ein Beispiel für den Einsatz der Operation iscallerinrole() zeigt diese Folie, bei dem der Wert für das Gehalt geändert werden kann. Dies ist nur möglich, wenn der Principal die Rolle payroll hat. 17

18 5.3 EJB Security Bean Provider kennt keine systemweiten Rollen, da er die Anwendung nicht kennt, in der die Beans eingesetzt werden. Bean Provider muss die im Code benutzten Rollen im Deployment-Deskriptor deklarieren Application Assembler bildet diese Rollen später auf die tatsächlichen Rollen der Anwendung ab. Da vom Standpunkt des Bean Providers aus noch keine systemweiten Rollen eingeführt wurden, muss der Bean Provider alle im Code des EJBs benutzten Rollen im Deployment Descriptor deklarieren. Dies geschieht mit den <security-role-ref >-Elementen. Dies erlaubt dem Application Assembler oder dem Deployer, diese Namen später mit den Rollen zu verbinden, die in der Anwendung definiert werden. 18

19 5.3 EJB Security <enterprise-beans>... <entity> <ejb-name>aardvarkpayroll</ejb-name> <ejb-class>com.aardvark.payroll.payrollbean</ejb-class>... <security-role-ref> <description> This security role should be assigned to the employees of the payroll department who are allowed to update employees salaries. </description> <role-name>payroll</role-name> </security-role-ref>... </entity> Die Folie zeigt ein Beispiel für die Spezifikation einer Rollenreferenz im Deployment Descriptor. Das Element <security-role-ref> enthält den Namen der Rollenreferenz (<rolename>) und eine optionale Beschreibung (<description>). Im <role-name>-element muss der Name der Rolle stehen, wie sie als Parameter in der Methode iscallerinrole() benutzt wurde. In unserem Gehalts-Beispiel einige Folien zuvor war dies die Rolle payroll. 19

20 5.3 EJB Security Sicherheitsaufgaben des Application Assemblers Definiert Sicherheitssicht auf die EJBs mittels eine Menge von Sicherheits-Rollen (security roles) Für jede Sicherheits-Rolle definiert er die zugehörigen Rechte (method permissions). Bildet die vom Bean Provider definierten Rollen- Referenzen auf Sicherheits-Rollen ab. Der Application Assembler definiert eine Sicherheitssicht auf die EJBs im Deployment Descriptor. Die Sicherheitssicht besteht aus einer Menge von Sicherheits-Rollen, welche eine semantische Gruppierung von Erlaubnissen zum Aufruf von EJB-Methoden sind. Der Application Assembler definiert die Erlaubnisse (method permissions) für jede Sicherheits- Rolle. Wenn der Bean Provider Rollen mittels der <security-role-ref>-elemente im Deployment-Deskriptor beschrieben hat, muss der Application Assembler diese Rollen- Referenzen auf die von ihm definierten Sicherheits-Rollen abbilden. 20

21 5.3 EJB Security Definition von Sicherheitsrollen ist optional. (Es gibt dann keine Sicherheitsinstruktionen an den Deployer) Sicherheitsrolle wird im Deployment-Deskriptor definiert. <security-role>: definiert eine Sicherheitsrolle <role-name>: Definiert den Namen der Rolle <description>: Die Rolle kann optional eine Beschreibung bekommen. Die Definition von Sicherheitsrollen im Deployment-Deskriptor ist optional für den Application Assembler. Definiert er keine Sicherheitsrollen, so entschließt sich der Application Assembler dazu, keine Sicherheits-Deployment-Instruktionen an den Deployer zu übergeben. Wenn der Application Assembler jedoch eine Sicherheitsrolle definiert, so muss er/sie folgendes tun: Definiere die Sicherheitsrolle mittels des <security-role> Elements. Benutze das <role-name> Element, um den Namen der Sicherheitsrolle zu spezifizieren. Optional kann das <description>-element benutzt werden, um eine Beschreibung der Sicherheitsrolle zu geben. 21

22 5.3 EJB Security <security-role> <description> This role includes the employees of the enterprise who are allowed to access the employee self-service application. This role is allowed only to access his/her own information. </description> <role-name>employee</role-name> </security-role> <security-role> <description> This role includes the employees of the payroll department. The role is allowed to view and update the payroll entry for any employee. </description> <role-name>payroll-department</role-name> </security-role> Die Folie zeigt ein Beispiel der Sicherheitsrollendefinition im Deployment Descriptor. 22

23 5.3 EJB Security Method Permission definiert eine Erlaubnis zum Aufruf einer EJB-Methode. Method Permission werden im Deployment- Deskriptor als binäre Relation Sicherheitsrollen x EJB-Methoden definiert. Paar (R,M) bedeutet, dass die Sicherheitsrolle R die EJB-Methode M aufrufen darf. Nachdem der Application Assembler die Sicherheitsrollen definiert hat, kann er/sie die Erlaubnisse (method permissions) für die Aufrufe von EJB-Methoden den Rollen zuordnen. Die Method Permissions werden im Deployment Descriptor als binäre Relation auf der Menge der Sicherheitsrollen und der Menge der EJB-Methoden definiert. Ein Paar (R,M) in der Method-Permission-Relation bedeutet dann, dass die Rolle R die Methode M aufrufen darf. 23

24 5.3 EJB Security Method Permissions werden wie folgt definiert: <method-permission>: Definiert eine Liste von Sicherheitsrollen und EJB-Methoden. Sicherheitsrollen werden mittels <role-name> identifiziert. EJB-Methoden werden mittels <method> identifiziert, welches den EJB-Namen (<ejb-name>) und den Methodennamen (<method-name>) enthält. Alle aufgelisteten Rollen dürfen alle Methoden aufrufen. Eine optionale Beschreibung kann hinzugefügt werden (<description>) Die Method Permissions werden im Deployment Descriptor mit dem Element <methodpermission> definiert. Jedes <method-permission> -Element definiert eine Liste einer oder mehrerer Sicherheitsrollen und eine Liste von einer oder mehreren EJB-Methoden. Alle aufgelisteten Sicherheitsrollen dürfen alle aufgelisteten Methoden aufrufen. Jede Sicherheitsrolle in der Liste wird mittels des <role-name>-elements identifiziert und jede EJB- Methode wird über das <method>-element identifiziert. Eine optionale Beschreibung kann dem <method-permission>-element zugeordnet werden (mit dem <description>-element). 24

25 5.3 EJB Security <method-permission> <role-name>employee</role-name> <method> <ejb-name>aardvarkpayroll</ejb-name> <method-name>findbyprimarykey</method-name> </method> <method> <ejb-name>aardvarkpayroll</ejb-name> <method-name>getemployeeinfo</method-name> </method> </method-permission> <method-permission> <role-name>employee</role-name> <method> <ejb-name>employeeservice</ejb-name> <method-name>*</method-name> </method> </method-permission> Die Folie zeigt ein Beispiel für eine <method-permission>-spezifikation. Für die Methodennamen können auch Platzhalter (z.b. *) benutzt werden. Dies bedeutet, dass die Rolle alle Methoden der Bean aufrufen darf. 25

26 5.3 EJB Security Method-Permission-Relation ist die Vereinigung aller methodpermission Elemente Sicherheitsrolle oder EJB-Methode kann in mehreren methodpermission Elementen auftreten. Mit <exclude-list> können Verbote spezifiziert werden. Bei Konflikten (d.h. Methode steht in exclude-list und methodpermission) haben Verbote Priorität. Sind für EJB-Methoden keine Zugriffsrechte spezifiziert, muss der Deployer die Zuordnung zu Sicherheitsrollen vornehmen oder sie als unchecked deklarieren. Die Method-Permission-Relation ergibt sich dann als die Vereinigung aller Method Permissions in den <method-permission>-elementen. Eine Sicherheitsrolle oder EJB- Methode kann in mehreren <method-permission>-elementen auftreten. Der Application Assembler kann zusätzlich mittels des <exclude-list>-elements eine Menge von EJB- Methoden definieren, die nicht aufgerufen werden dürfen. Der Deployer muss dann dafür sorgen, dass kein Zugriff auf eine Methode erfolgt, die in der exclude-list enthalten ist. Wenn eine EJB-Methode sowohl in der exclude-list als auch in der Method-Permission-Relation steht, so muss der Deployer dafür sorgen, dass kein Zugriff erlaubt ist (d.h. Verbote haben eine höhere Priorität als Erlaubnisse). Sind Methoden weder einer Sicherheitsrolle zugeordnet noch in der exclude-list, liegt es in der Verantwortung des Deployers, Method Permissions zu definieren. Dies kann durch Zuordnung der unspezifizierten Methoden zu Sicherheitsrollen geschehen oder der Deployer entschließt sich dazu, dass diese Methoden bei einem Zugriff nicht auf Autorisierung geprüft werden müssen (spezifiziert durch unchecked). 26

27 5.3 EJB Security Application Assembler ordnet die Rollenreferenzen Sicherheitsrollen zu. Spezifiziert im Deployment-Deskriptor mittels <rolelink> Wert von <role-link> muss ein Wert eines <rolename> Elements sein. Muss auch gesetzt werden, wenn die Werte für <rolelink> und <role-name> identisch sind. Definiert der Application Assembler Sicherheitsrollen im Deployment Descriptor, so muss er/sie allen Rollenreferenzen in den <security-role-ref>-elementen eine Sicherheitsrolle zuweisen. Dies erfolgt mittels des <role-link>-elements. Der Wert des <role-link>-elements muss dabei der Name einer Sicherheitsrolle sein (d.h. der Name muss in einem <role-name>- Element auftreten). Ein <role-link>-element muss auch dann explizit benutzt werden, wenn die Werte für <role-name> und <role-link> identisch sind. 27

28 <enterprise-beans>... <entity> <ejb-name>aardvarkpayroll</ejb-name> <ejb-class>com.aardvark.payroll.payrollbean</ejb-class>... <security-role-ref> <description> This role should be assigned to the employees of the payroll department. Members of this role have access to anyone s payroll record. The role has been linked to the payroll-department role. </description> <role-name>payroll</role-name> <role-link>payroll-department</role-link> </security-role-ref>... </entity>... </enterprise-beans> Die Folie zeigt ein Beispiel. Hier wird die vom Bean Provider definierte Rollenreferenz payroll der vom Application Assembler definierten Sicherheits-Rolle payroll department zugeordnet. 28

29 5.3 EJB Security Sicherheitsaufgaben des Deployers Abbilden der Sicherheitssicht auf die Zielumgebung. Zuweisen von Principals zu Sicherheitsrollen. Rollenreferenzen (benutzt im Bean Code) sind über den Link zu Sicherheitsrollen Principals zugeordnet. Muss die fehlenden (optionalen) Aufgaben des Application Assemblers ausführen (z.b. Sicherheitsrollen und Method Permissions definieren) Der Deployer muss die vom Application Assembler definierte Sicherheitsicht auf die Zielumgebung abbilden. Dies beinhaltet die Zuweisung von Principals zu den im Deployment Descriptor definierten Sicherheitsrollen. Der Application Assembler hatte alle Sicherheitsrollen-Referenzen, die im Bean Code benutzt wurden, mit Sicherheitsrollen verbunden. Der Deployer weist daher keine Principals zu Rollen-Referenzen, da die zu den Sicherheitsrollen zugewiesenen Principals automatisch zu den verbundenen Rollen- Refenrenzen zugeordnet sind. Da die Sicherheitsinformationen im Deployment Descriptor für den Application Assembler teilweise optional sind (z.b. die Definition der Sicherheitsrollen), muss der Deployer die vom Application Assembler nicht durchgeführten Aufgaben übernehmen (z.b. Definition der Sicherheitsrollen und Method Permissions). 29

30 5.3 EJB Security Das Rollenmodell von EJB entspricht RBAC 0 RBAC 0 User Rollen Rechte Sessions Principals, denen autorisierte Benutzer zugeordnet sind. Sicherheitsrollen Method Permissions EJB Client/Server-Aufruf, bei dem ein Benutzer einem Principal zugeordnet wird und damit Sicherheitsrollen besitzt. Abschließend kann man feststellen, dass das bei EJBs verwendete Rollenmodell am ehesten dem RBAC 0 Modell entspricht. Die Benutzer (User) im RBAC 0 Modell entsprechen den Principals in EJB, welche einem autorisierten Benutzer zugeordnet werden. Die Rollen im RBAC 0 Modell sind die vom Application Assembler definierten Sicherheitsrollen und die Rechte im RBAC 0 Modell sind die Method Permissions, die Rollen zugewiesen werden. Bei den RBAC 0 Sessions ist die Zuordnung nicht ganz so offensichtlich. Man kann aber einen Client-Aufruf als Session ansehen, bei dem dem Clienten ein Principal zugeordnet wird. Dieser Principal bekommt dann eine Menge von Rollen zugeordnet, die zur Ausführung der Anfragen des Clienten an den Server ausgewertet werden. 30

31 5.3 EJB Security Es gibt bei EJBs keine Rollenhierachien und keine Constraints. Daher weder RBAC 1 noch RBAC 2. EJBs bieten jedoch weder die Möglichkeit Rollenhierarchien zu definieren noch Constraints aufzustellen. Daher ist das in EJB verwendete Rollenmodell weder RBAC 1 noch RBAC 2 (und damit auch nicht RBAC 3 ). 31

32 5.4 CORBA Security CORBA (Common Object Request Broker Architecture) ist eine Spezifikation der OMG (Object Management Group) Ziel ist die Integration von Anwendungen in heterogenen Umgebungen und die Förderung von Objektorientierung. CORBA ist nur eine Spezifikation, keine eigene Implementierung. CORBA (Common Object Request Broker Architecture) wurde von der OMG (Object Management Group) spezifiziert. Die CORBA-Spezifikation hat die Integration von Anwendungen in heterogenen Umgebungen unter Verwendung der Objektorientierung zum Ziel. Grundvoraussetzung für dieses Ziel ist die Interoperabilität der Softwarekomponenten und der Objekte, aus denen sich Anwendungen zusammensetzen. 32

33 5.4 CORBA Security CORBA Objektmodell Objekte haben eine Identität, eine Lebenszeit und eine Schnittstelle (bestehend aus Methoden und Attributen). Objektaufrufe sind nur über definierte Schnittstellen möglich. Trennung schafft Unabhängigkeit von der Implementierung. Im CORBA-Objektmodell haben Objekte eine Identität und eine Lebenszeit (d.h. Objekte werden erzeugt und können auch wieder zerstört werden). Objekte werden über Schnittstellen beschrieben, die aus Attributen und Methoden bestehen. Die Kommunikation zwischen den Objekten erfolgt dann nur über diese definierten Schnittstellen. Dies schafft eine Unabhängigkeit von der Implementierung der Objekte, was in heterogenen Systemen eine wichtige Anforderung ist. 33

34 5.4 CORBA Security Object Management Architecture Applikationsobjekte CORBA Services Common Facilities ORB (Object Request Broker) Domain Objects Die in der CORBA-Spezifikation vorgestellte Architektur, die sogenannte Object Management Architecture (OMA), besteht aus dem Object Request Broker (ORB), Domain-Objekten, CORBA Services, Common Faciclities und Applikations-Objekten. 34

35 5.4 CORBA Security Verteilte Objekte kommunizieren über den ORB plattformunabhängig. Schnittstellen der CORBA-Objekte werden in programmiersprachenunabhängigen Schnittstellenbeschreibungssprache (Interface Definition Language, IDL) beschrieben. ORB sucht die passende Objekt-Implementierung zu einer Client-Anfrage, überträgt die Aufrufparameter, ruft die zur Anfrage passende Methode auf dem Server- Objekt auf und liefert die Ergebnisse zurück. Der ORB bildet das Rückgrat einer verteilten CORBA-Anwendung. Ein ORB ist ein Software- Bus, auf dem sich CORBA-Objekte registrieren lassen können, um so ihr Dienste anderen Objekten zur Verfügung zu stellen. CORBA-Objekte kommunizieren über den ORB plattformunabhängig, d.h. die von einem CORBA-Objekt angebotenen Dienste werden in einer programmiersprachenunabhängigen Interface Definition Language (IDL) beschrieben. Der ORB ist verantwortlich für das Auffinden des zur Anfrage passenden Server-Objekts, für die Übertragung der Aufrufparameter, für den Aufruf der Methode auf dem Server-Objekt und die Rückgabe des Ergebnisses zum Client. 35