5.3 EJB Security

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
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
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
5.3 EJB Security
3: erzeuge
EJB Object
Client
1: frage nach
Home
Object
Reference
Home
Interface
5: EJB
Reference
6: Methodenaufruf
EJB Container/Server
Home
Object
4: erzeuge EJB Object
Remote
Interface
EJB
Object
2:Home Object
Reference
Naming
Service
Die Folie zeigt den grundlegenden Aufbau für den Aufruf von EJB Komponenten. Eine ClientAnwendung 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.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
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
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
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
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
// 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
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
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
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
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
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
// 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
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
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
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
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 RollenReferenzen 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 SicherheitsRolle. Wenn der Bean Provider Rollen mittels der <security-role-ref>-Elemente im
Deployment-Deskriptor beschrieben hat, muss der Application Assembler diese RollenReferenzen auf die von ihm definierten Sicherheits-Rollen abbilden.
20
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
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
5.3 EJB Security
Method Permission definiert eine Erlaubnis zum
Aufruf einer EJB-Methode.
Method Permission werden im DeploymentDeskriptor 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
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 EJBMethode wird über das <method>-Element identifiziert. Eine optionale Beschreibung kann
dem <method-permission>-Element zugeordnet werden (mit dem <description>-Element).
24
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
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 EJBMethode kann in mehreren <method-permission>-Elementen auftreten. Der Application
Assembler kann zusätzlich mittels des <exclude-list>-Elements eine Menge von EJBMethoden 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
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
<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
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 RollenRefenrenzen 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
5.3 EJB Security
Das Rollenmodell von EJB entspricht RBAC0
RBAC0
User
EJB
Rollen
Principals, denen autorisierte Benutzer
zugeordnet sind.
Sicherheitsrollen
Rechte
Method Permissions
Sessions 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 RBAC0 Modell entspricht. Die Benutzer (User) im RBAC0 Modell entsprechen den
Principals in EJB, welche einem autorisierten Benutzer zugeordnet werden. Die Rollen im
RBAC0 Modell sind die vom Application Assembler definierten Sicherheitsrollen und die
Rechte im RBAC0 Modell sind die Method Permissions, die Rollen zugewiesen werden. Bei
den RBAC0 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
5.3 EJB Security
Es gibt bei EJBs keine Rollenhierachien und keine
Constraints.
Daher weder RBAC1 noch RBAC2.
EJBs bieten jedoch weder die Möglichkeit Rollenhierarchien zu definieren noch Constraints
aufzustellen. Daher ist das in EJB verwendete Rollenmodell weder RBAC1 noch RBAC2 (und
damit auch nicht RBAC3).
31
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
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
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
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 ServerObjekt auf und liefert die Ergebnisse zurück.
Der ORB bildet das Rückgrat einer verteilten CORBA-Anwendung. Ein ORB ist ein SoftwareBus, 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
5.4 CORBA Security
CORBA Services: Allgemeine Hilfs- und Infrastrukturdienste (z.B.
Naming Service, LifeCycle, Transaction, Security Service,...)
Domain Objects: Anwendungsnahe „vertikale“ Dienste:
adressieren spezielle Branchen (z.B. Gesundheitswesen,
Finanzen,...)
Common Facilities: Anwendungsnahe „horizontale“ Dienste (z.B.
System Management, Information Management,....)
Applikationsobjekte: Bestandteil von Anwendungen (nicht von
der OMG spezifiziert)
CORBA Services standardisieren wesentliche Dienste, die von eigentlich jedem Objekt
benötigt werden, wie z.B. Lifecycle- oder Naming-Services. Unter die CORBA Services fällt
auch der Security Service. Die Domain Objects sind anwendungsnahe Dienste, die in
speziellen Branchen gebraucht werden. Beispiele solcher Branchen sind das Finanzwesen oder
das Gesundheitswesen. Die Common Facilities sind ebenfalls anwendungsnahe Dienste, die
aber weniger spezifisch für eine Branche sind, sondern vielmehr übergreifend in vielen
Anwendungen gebraucht werden könnten. Beispiele solcher Dienste sind Dienste zum Systemoder Informations-Management. Applikationsobjekte bieten Dienste spezieller Anwendungen,
die im Gegensatz zu den vorherigen Diensten nicht von der OMG spezifiziert werden.
36
5.4 CORBA Security
Folgende Schritte sind für die Implementierung einer CORBAAnwendung durchzuführen.
1.
2.
schreibe eine IDL-Spezifikation.
Übersetze die Spezifikation mit dem IDL-Compiler (Java
Interfaces, Helper und Holder Klassen, Stubs and
Skeletons).
3. Implementiere die generierten Java-Interfaces
4. Schreibe eine “Main”-Klasse, die die eine Instanz
der Server-Implementierung erzeugt und mit dem
ORB
registriert
5. Schreibe einen Client, welcher eine Referenz zum ServerObjekt erhält und einen entfernten Aufruf macht.
Um eine CORBA-Anwendung zu erstellen, sind folgende Schritte notwendig:
1.
Zunächst müssen die Schnittstellen beschrieben werden. Dies geschieht
programmiersprachenunabhängig mittels der Interface Definition Language (IDL).
2.
Die IDL-Beschreibung wird dann mit einem IDL-Compiler (der dann spezifisch für eine
Programmiersprache ist) übersetzt. Der IDL-Compiler erzeugt mehrere Klassen.
3.
Dann müssen die generierten Schnittstellen implementiert werden.
4.
Danach muss ein Server implementiert werden, der eine Instanz des CORBA-Objekts
erzeugt, mit dem ORB registriert und somit für Clienten zur Verfügung stellt.
5.
Ein Client kann dann eine Referenz auf das CORBA-Objekt erfragen und einen Aufruf
durchführen.
37
5.4 CORBA Security
1. Schreibe eine IDL-Spezifikation
module HelloApp {
interface Hello {
string sayHello();
};
};
Im folgenden stellen wir eine kleine HeloWorld-CORBA-Anwednung vor. Dazu wird zunächst
die IDL-Spezifikation erstellt. Wir haben in diesem Beispiel nur eine Schnittstelle Hello mit
einer Operation sayHello().
38
5.4 CORBA Security
2. Übersetze die Spezifikation mit dem IDL-Compiler
_HelloStub.java
HelloPOA.java
HelloOperations.java
Hello.java
HelloHelper.java
Vertreter-Objekt auf Client-Seite
Server-Objekt zum Bearbeiten von
Client Requests
Java-Version der IDL
Erweitert HelloOperations.java
Typ-Operationen, narrow()
HelloHolder.java
CORBA Input uns Output Streams
Übersetzen wir diese IDL-Spezifikation mit einem IDL-Compiler für Java, bekommen wir
mehrere Klassen generiert. Die Klasse _HelloStub.java repräsentiert das Vertreter-Objekt des
Server-Objekts auf der Client-Seite. Der Client ruft dann die Operation auf dem VertreterObjekt auf und der ORB vermittelt den Aufruf auf das Server-Objekt, welches die Anfrage
bearbeitet. Der ORB gibt dann das Ergebnis über das Vertreter-Objekt an den Clienten zurück.
Die Klasse HelloPOA.java repräsentiert das Server-Objekt, welches den Dienst zur Verfügung
stellt. Die Klasse HelloOperations.java ist die Java-Schnittstelle zum IDL-Interface und
Hello.java erweitert HelloOperations.java . Die Klassen HelloHelper.java und
HelloHolder.java sind Hilfsklassen, die für die Kommunikation gebraucht werden.
39
5.4 CORBA Security
3. Implementiere die generierten Java-Interfaces
class HelloImpl extends HelloPOA
{
public String sayHello()
{
return System.out.println(“Hello!”);
}
}
Die generierten Java-Schnittstellen müssen dann implementiert werden. In unserem
HelloWorld-Beispiel müssen wir nur die eine Operation sayHello() implementieren. Die
Implementierung erweitert die Klasse HelloPOA.
40
5.4 CORBA Security
4. Schreibe eine “Main”-Klasse, die eine Instanz der
Server-Implementierung erzeugt und mit dem ORB registriert
public class Server {
public static void main( String[] args ) {
ORB orb = ORB.init(args, null); //initialisiere ORB
try
{
POA poa = POAHelper.narrow(
orb.resolve_initial_references("RootPOA"));
poa.the_POAManager().activate();
Zum Schreiben des Servers, muss man zunächst den ORB initialisieren. Nachdem dies
geschehen ist, holt man sich vom ORB eine Referenz zum Object Adapter (POA). Der ORB
kennt einige initiale Referenzen, die über Namen ermittelt werden können (z.B. „RootPOA“).
Die zurückgelieferte Referenz ist ein ungetyptes CORBA-Objekt, so dass es zunächst zum
richtigen Typ umgewandelt werden muss (mit der narrow() Operation der entsprechenden
Helper-Klasse) . Danach wird der POA aktiviert, so dass er eine Objektreferenz für eine
Instanz der Objet-Implementierung HelloImpl() erzeugen kann.
41
// Objektreferenz von der Objekt-Implementierung
org.omg.CORBA.Object o =
poa.servant_to_reference(new HelloImpl());
// mit dem Naimg Service registrieren
NamingContextExt nc =
NamingContextExtHelper.narrow(
orb.resolve_initial_references("NameService"));
nc.bind( nc.to_name(„hello.example"), o);
}
catch ( Exception e )
{ e.printStackTrace(); }
orb.run();
}
}
Damit dieses neue erzeugte CORBA-Objekt für Clients erreichbar ist, muss die Objektreferenz
verfügbar gemacht werden. Dies geschieht über den Naming Service. Eine Referenz zum
Naming Service wird mittels orb.resolve initial references("NameService") erlangt. Danach
wird das CORBA-Objekt mittels der bind()-Operation mit einem Namen im Naming Service
gebunden.
42
5.4 CORBA Security
5. Schreibe einen Client, welcher eine Referenz zum
Server-Objekt erhält und einen entfernten Aufruf
macht.
public class Client {
public static void main(String args[])
{
try {
ORB orb = ORB.init(args,null);
Ein CORBA-Client muss ebenfalls zunächst den ORB initialisieren.
43
//Referenz zum Naming Service
NamingContextExt nc =
NamingContextExtHelper.narrow(
orb.resolve_initial_references("NameService"));
//Löse Objektreferenz auf
Hello hello = HelloHelper.narrow(
nc.resolve(nc.to_name(„hello.example")));
//rufe Methoden des CORBA-Objekts auf
System.out.println( hello.sayHello() );
}
.....
Außerdem braucht der Client eine Referenz zum Namensservice, um Referenzen von ServerObjekten zu erfragen. Die Referenz zum Namensservice wird wie beim Server mittels
orb.resolve initial references("NameService") erlangt. Danach kann sich der Client über den
registrierten Namen des CORBA-Objekts eine Referenz auf das CORBA-Objekt beim
Namensservice erfragen. Die Objektreferenz muss dann noch in den richtigen Typ
umgewandelt werden (mittels der narrow()-Operation), bevor die Operationen des CORBAObjekts vom Clienten aufgerufen werden können.
44
5.4 CORBA Security
CORBA Security Service
Nach der erfolgreichen Authentifizierung wird ein Benutzer
innerhalb des Systems durch Principals repräsentiert.
Der Principal-Authenticator weist dem Principal Credentials zu,
die u.a. die für den Zugriffsschutz benötigten Privileg-Attribute
enthalten.
unauthentifizierte Attribute
(public)
Credentials
authentifizierten Attribute
PrivilegAttribute
IdentityAttribute
Wir betrachten nun das im CORBA Security Service spezifizierte Zugriffsschutzmodell.
Zunächst müssen sich Benutzer (bzw. Clienten) am System authentifizieren (z.B. durch ein
Passwort). Bei einer erfolgreichen Authentifizierung wird der Benutzer dann mittels eines
Principals im System repräsentiert, der mit Zugriffsberechtigungen ausgestattet wird. Die
zuständige Komponente zur Authentifizierung ist der PrincipalAuthenticator, welcher einen
Principal mit Credentials ausstattet. CORBA entscheidet den Zugriff eines Principals auf der
Basis dieser Credentials . Credentials enthalten unauthentifizierte Attribute (werden beim
Zugriffsschutz nicht berücksichtigt) und authentifizierte Attribute, die beim Zugriffsschutz
relevant sind. Authentifizierte Attribute sind Privileg-Attribute (z.B. Rollen, Gruppen etc.) und
Identity-Attribute, die die Identität des Principals genauer beschreiben. Welche Attribute nun
genau unter Privileg-Attributen zu verstehen und somit zugriffsschutzrelevant sind, schreibt
die Spezifikation des CORBA Security Services nicht vor. Neben den Credentials des
Principals basiert die Zugriffsschutzentscheidung auch auf den Zugriffsschutzregeln des
Zielobjekts.
45
5.4 CORBA Security
Zugriffsschutzregeln für CORBA-Objekte
CORBA-Objekte kontrollieren den Zugriff auf ihre Operationen
mittels Rechten.
Jede Operation im Interface erfordert bestimmte Rechte
(required rights).
Standard-Rechtefamilie:
g (get), s (set), m (manage), u (use)
Weitere Rechtefamilien können vom Anwendungsentwickler bei
Bedarf definiert werden.
Der Zugriff der Principals mit ihren Privileg-Attributen auf CORBA-Objekte wird mittels
Rechten kontrolliert. Für jede Operation im Interface eines CORBA-Objekts sind bestimmte
Rechte erforderlich (required right). Ein Aufrufer einer Operation muss diese Rechte haben.
Die Spezifikation stellt eine Standardmenge von Rechten zur Verfügung, die vier Rechte
enthält: “g” (“get”), “s” (“set”), “m” (“manage”) und “u” (“use”). Anwendungsentwickler
können jedoch weitere Rechtefamilien definieren.
46
5.4 CORBA Security
Rechte – Operationen:
requiredRights: Operation ‡ Menge von Rechten
Festlegung durch den Anwendungsentwickler.
Rechte sind generisch und nicht a priori an bestimmte
Operationen gebunden.
Rechte – Subjekte:
effectiveRights: Subjekt ‡ Menge von Rechten
Teil der Privileg-Attribute
Zugriffschutz ist im wesentlichen systembestimmt.
Zusammenfassend lässt sich somit sagen, dass der Anwendungsentwickler jede Operation mit
einer Menge von Rechten belegt, die zur Ausführung der Operation benötigt werden (required
rights). Diese Rechte sind generisch in Rechtefamilielen definiert und sind nicht a priori an
bestimmte Operationen gebunden. Subjekte (bzw. Principals) können Rechte besitzen, die in
ihren Privileg-Attributen enthalten sind (effective rights). Die Zuordnung von Rechten zu
Operationen und Subjekten wird im wesentlichen vom System bestimmt.
47
5.4 CORBA Security
Beispiel: EffectiveRights und Required Rights
effective
effective
rights
rights
required
required
rights
rights
operation
operation
id:alice
id:alice
corba:g-ucorba:g-u-
corba:--ucorba:--u-
resolve
resolve
group:admin
group:admin
corba:gsum
corba:gsum
corba:g-ucorba:g-u-
list
list
group:programmers
group:programmers corba:gsucorba:gsu-
corba:gsucorba:gsu-
bind
bind
corba:gsum
corba:gsum
new_context,
new_context,
bind_new_context
bind_new_context
unbind,
unbind, rebind,
rebind,
destroy
destroy
corba:gsum
corba:gsum
interface
interface
NamingNamingContext
Context
Diese Folie zeigt ein Beispiel für die Schnittstelle Naming-Context mit den Operationen
resolve, list, bind, new context, bind new context, unbind, rebind und destroy. In den obigen
Tabellen werden die Rechte der CORBA-Standardfamilie (gennant corba) zum Definieren
des Zugriffsschutzes verwendet. In der linken Tabelle stehen die Rechte in den PrivelegAttributen eines Principals. Die Principal-Identität alice hat die Rechte g (get) und u (use),
die Gruppe admin hat alle Rechte, der Gruppe programmers fehlt nur das Recht m (manage).
Die für die Operationen benötigten Rechte sind in der rechten Tabelle aufgelistet. So kann
alice beispielsweise die Operation resolve aufrufen (da sie das benötigte Recht u besitzt),
aber sie kann nicht die Operation destroy aufrufen (ihr fehlen die Rechte s und m).
48
5.4 CORBA Security
Allgemeines Zugriffsschutzmodell basiert auf
Zugriffsentscheidungsfunktionen (access decision function)
Access Decision Function betrachtet
Privileg-Attribute des Aufrufers
Zugriffsschutzregeln des Zielobjekts
möglicherweise weitere Informationen (Kontext, Zeit etc.)
Kontext-Info
Privileg-Attribute
Zugriffschutzregeln
des Ziel-Objekts
Access Decision Function
(setzt Zugriffsschutzregeln durch)
Zugriff erlaubt?
ja/nein
Das allgemeine Zugriffsschutzmodell basiert auf Zugriffentscheidungsfunktionen (access
decision function), die entscheiden, ob ein Zugriff auf eine CORBA-Operation erlaubt ist. Für
die Zugriffschutzentscheidung werden betrachtet: die Privileg-Attribute des Aufrufers, die
Zugriffsschutzregeln des Zielobjektes und möglicherweise weitere Kontext-Informationen wie
beispielsweise die Zeit.
49
5.4 CORBA Security
Nachteile des CORBA-Standard-Zugriffsschutzmodells
Beschränkte Rechtemenge, low-level(“Object rwx”)
Alle Objekte eines Typs werden gleich behandelt
Keine dynamischen Rechteänderungen
Keine Verbote
Das Standard-CORBA-Zugriffsschutzmodell hat einige Nachteile. Durch die beschränkte
Rechtemenge lassen sich nur sehr beschränkte Zugriffsschutzanforderungen auf den Objekten
modellieren. Die Rechte sind sehr generisch und daher nicht für jede Anwendung passend.
Außerdem bekommen alle Instanzen eines Typs die gleichen Rechte. Es ist nicht möglich,
zwischen Instanzen zu unterscheiden, d.h. einer Instanz andere Rechte zu geben als einer
anderen. Die Zugriffsschutzpolitik kann zur Laufzeit nicht mehr geändert werden und es
besteht keine Möglichkeit, explizit Verbote zum Aufruf von CORBA-Operationen
auszusprechen. Aufgrund dieser Nachteile gibt es Erweiterungen des CORBAZugriffsschutzmodells, die diese Nachteile beheben (siehe 5.5. RACCOON).
50
5.4 CORBA Security
CORBA und RBAC
CORBA-Security Spezifikation bietet die Möglichkeit, Rollen für
die Zugriffsschutzentscheidung zu berücksichtigen (PrivilegAttribute).
Spezifikation lässt das RBAC-Modell offen. Es liegt im
Ermessen des Implementierers der CORBA-Security
Spezifikation, welches RBAC-Modell genommen wird.
Muss in der Access Decision Function implementiert werden.
Die Unterstützung von rollenbasiertem Zugriffsschutz in CORBA ist in der Spezifikation nicht
explizit vorgesehen. Die Spezifikation bietet jedoch die Möglichkeit, rollenbasierten
Zugriffsschutz zu integrieren. Dazu müssen in die Privileg-Attribute Rollen aufgenommen
werden, die von den Access Decision Funktionen bei der Zugriffsschutzentscheidung
berücksichtigt werden. Diese Integration eines Rollenmodells unterliegt demjenigen, der die
Spezifikation des CORBA Security Service implementiert. Dieser kann auch entscheiden,
welche Mächtigkeit das Rollenmodell haben soll (RBAC0, RBAC1, RBAC2 oder RBAC3).
51
5.5 RACCOON
RACCOON = Rigourous Access Control in Object-Oriented Networks
(http://www.inf.fu-berlin.de/Raccoon/)
Forschungsprojekt an der FU als Teil des DFGSchwerpunktprogramms „Sicherheit in der Informations- und
Kommunikationstechnik“
(http://www.telematik.uni-freiburg.de/spps/index.php)
Thema: Spezifikation und das Management objektorientierter
Zugriffsschutzpolitiken im Netz
RACCOON-Annahme: Erhöhte Handhabbarkeit führt direkt zu mehr
Sicherheit!
RACCOON (Rigourous Access Control in Object-Oriented Networks) ist ein
Forschungsprojekt an der FU Berlin, das im Jahr 1999 gestartet wurde. RACCOON ist Teil
des
DFG-Schwerpunktprogramms
„Sicherheit
in
der
Informationsund
Kommunikationstechnik“, an dem mehrere Projekte an unterschiedlichen
Universitäten in Deutschland teilnehmen, die alle an einen bestimmten Aspekt von
Sicherheit forschen. Das Thema von RACCOON ist die Spezifikation und das
Management objektorientierter Zugriffsschutzpolitiken im Netz. Die Arbeiten in
RACCOON stehen unter der Annahme, dass Sicherheitskonzepte- und werkzeuge
nicht eingesetzt werden, wenn sie für den Anwender zu kompliziert sind. Dadurch
entstehen vermeidbare Sicherheitslücken. RACCOON versucht nun handhabbare
Konzepte und Werkzeuge zur Verfügung zu stellen, so dass Sicherheitslücken, die
aufgrund von Verwaltungsfehlern entstehen, reduziert werden.
52
5.5 RACCOON – VBAC
RACCOON bietet:
Handhabbares Zugriffsschutzmodell (View-based Access
Control, VBAC) mit zugehöriger Politiksprache (View
Policy Language, VPL)
CORBA-basierte Infrastruktur zur technischen
Realisierung der Zugriffsschutzstrategien
Graphische Werkzeuge für den Sicherheitsadministrator.
Innerhalb des RACCOON-Projekts wurde ein Zugriffschutzmodell für verteilte Objektsysteme
und dazugehöriger Politiksprache entwickelt. Das Zugriffsschutzmodell nennt sich View-based
Access Control (VBAC), die zugehörige Politiksprache View Policy Language (VPL).
Grundlegendes Konzept des Modells sind Views als Gruppierungskonzept von Rechten auf
Operationen. In RACCOON wurde eine auf CORBA-basierte Infrastruktur entwickelt, die sich
mit einer in VPL spezifizierten Politik konfigurieren lässt und die Zugriffe dann aufgrund der
VPL-Politik im System zur Laufzeit kontrolliert. Graphische Managementwerkzeuge erlauben
es dem Administrator eine Modifikation der Politik zur Laufzeit.
53
5.5 RACCOON – VBAC
View-based Access Control (Brose, 1999)
Erweiterung von rollenbasiertem Zugriffsschutz auf objektorientierte Systeme.
Skalierbarkeit durch Gruppen, Rollen, Views, Typen, Domains
Rolle 1
Benutzer 1
View 1
Gruppe 1
Rolle 2
Benutzer 2
View 2
Gruppe 2
Benutzer 3
Rolle 3
CORBAInterface 1
CORBAInterface 2
CORBAInterface 3
View-based Access Control (VBAC) ist eine Erweiterung von rollenbasietrem Zugriffsschutz
auf objekt-orientierte Systeme. Grundlegende Erweiterung ist das Konzept einer View, welche
eine Menge von Rechten zum Aufrufen von Operationen einer CORBA-Schnittstelle
zusammenfasst. Views dienen als Vermittler zwischen Rollen und Objekten (in diesem Fall
CORBA-Schnittstellen). Gruppen dienen als Gruppierungskonzept von Benutzern und
verbinden die Benutzer mit Rollen. Man kann Rechte an Typen von Objekten geben (d.h. alle
Exemplare eines Objekttyps haben dieses Recht) und man kann Objekte in Domänen
zusammenfassen, für die dann dieselbe Politik gilt.
54
5.5 RACCOON – VBAC
Bietet eine deklarative Politiksprache (View Policy Language)
zur Spezifikation einer VBAC-Politik
– Wiederverwendung, Dokumentation, Kommunikation
– Fixes Objektmodell (CORBA-IDL) erlaubt statische
Konsistenzprüfung
– Feinkörniger Schutz
– Dynamische Rechteänderungen
VBAC-Politiken werden in der deklarativen View Policy Language (VPL) spezifiziert. Die in
VPL spezifizierte Politik dient dann als Dokumentation der Zugriffsschutzanforderungen, zur
Kommunikation und zur Wiederverwendung. Die VPL basiert auf einem festen Objektmodell
(CORBA-IDL) und erlaubt somit statische Konsistenzprüfungen. VPL bietet einen
feinkörnigen Schutz auf der Ebene einzelner Schnittstellenoperationen und die Möglichkeit
Rechteänderungen dynamisch zur Laufzeit durchzuführen.
55
5.5 RACCOON – VBAC
Views
• gruppieren Rechte auf Operationen (Teilmenge eines
Interfaces)
• Können Constraints enhalten
• Beziehung zwischen Views (z.B. View-Erweiterung)
• Erlaubnisse und Verbote
interface Document {
{
void read(out string s);
void write(in string s);
void append(in string s);
void correct(in string s);
};
view Reading controls Document
allow read
}
view Writing: Reading
restricted_to Author {
allow
write
append
}
Zentrales Konzept des VBAC-Modells sind Views. Eine View gruppiert eine Menge von
Rechten, welche Erlaubnisse oder Verbote zum Aufrufen von Operationen eines CORBAObjekts sind. Eine View bezieht sich immer auf genau eine Schnittstelle, d.h. eine View kann
keine Rechte für Operationen verschiedener Schnittstellen geben. Die VPL bietet die
Möglichkeit Views zu erweitern (Notation erweiterte View:Basisview) , so dass die erweiterte
View alle Rechte der Basisview besitzt. Außerdem können Constraints definiert werden, z.B.
dass eine View nur an bestimmte Rollen vergeben werden kann (Notation restricted_to
Rollenname).
56
5.5 RACCOON – VBAC
Object
Role
Employee
Secretary
TechAuthor
NamingCtx
resolve
Resolving
bind
Binding
bind_new_ctx.
o2:Paper
o3:Review
read
resolve
list
append
read
correct
read
resolve
list, bind,
read
write
read
Schutzmatrix-Modell
hat Views als Einträge
o4:T
view Resolving controls NamingContext {
allow
resolve;
}
view Binding : Resolving {
allow
bind;
bind_new_context;
}
Das VBAC-Modell basiert auf einer Zugriffsschutzmatrix, in der die Matrixeinträge Views
sind. Ein Eintrag V in der Zeile S und der Spalte O bedeutet dann, dass das Subjekt S die
View V auf dem Objekt O besitzt.
57
5.5 RACCOON – VBAC
Rollen gemäß RBAC3,
d.h. hierarchische Rollen-Strukturen und Constraints
roles
Examiner
Head: Examiner
// Head is senior to
// examiner
President: Head maxcard 1
Lecturer: Examiner
Candidate excludes Examiner
Rollen können in der VPL gemäß RBAC3 definiert werden. Das heißt, es ist möglich Rollen
hierarchisch zu ordnen (Notation erweiterte Rolle: Basisrolle) und Constraints bzgl. Rollen
zu definieren (z.B. das zwei Rollen nicht demselben Benutzer zugeordnet werden dürfen
(excludes) oder dass eine Rolle nur einem Benutzer zugeordnet ist (maxcard 1)).
58
5.5 RACCOON – VBAC
Schemas beschreiben dynamische Rechteänderungen als
Folge der Ausführung von Operationen
IDL:
interface Paper {
Review submitReview( in string text );
};
VPL:
schema SubmitSchema observes Paper {
submitReview
assigns Modifying on result to caller
assigns ReviewReading on this to caller
removes ReviewSubmitting on this from caller
}
Um dynamische Rechteänderungen zur Laufzeit durchführen zu können, bietet VPL das
Konzept eines Schemas. Rechteänderungen werden durch den Aufruf von Operationen
initiiert. Das Schema beschreibt bei welcher Operation eine Rechteänderung geschieht und in
welcher Weise. Dabei können Views hinzugefügt oder entfernt werden. Mit dem Ausdruck
assigns View on Object to Subject wird eine View auf ein Object einem Subject zugeordnet.
Mit removes View on Object from Subject wird eine View auf ein Object einem Subject
entzogen. Die Schlüsselwörter result, this und caller sind das Ergebnisobjekt der Operation,
das Objekt, auf dem die Operation aufgerufen wurde und der Principal, der die Operation
aufgerufen hat.
59
5.5 RACCOON – VBAC
Vollständige Zugriffsschutzstrategie mit VPL
policy College
roles Author....
view...
view Updating : Reading
restricted_to Author
virtual view Managing
schema ....
Eine vollständige VPL-Spezifikation definiert die Rollen, Views und Schemas.
60
5.5 RACCOON – VBAC
CORBA-Infrastruktur zum Durchsetzen einer in VPL
spezifizierten Zugriffsschutzpolitik
Development:
VPL Compiler zum Umwandeln in XML und zum
Entdecken von Konflikten.
Deployment:
Verifier prüft auf Konflikte mit vorhandenen Politiken und
aktualisiert die Repositories
Management:
View/Role/Domain Server und Management Tools
Um eine VPL-Spezifikation in einem CORBA-System durchzusetzen, wurde im Projekt
RACCOON eine entsprechende Infrastruktur entwickelt. Es gibt Werkzeuge für die
verschiedenen Phasen: Ein VPL-Compiler übersetzt die VPL-Politik in eine XML-Datei
und führt einige Konsistenzchecks durch. Beim Deployment wird diese XML-Datei
benutzt, um die Repositories für Views und Rollen zu konfigurieren. Zur Laufzeit
werden dem Sicherheitsadministrator graphische Managementwerkzeuge zur Verfügung
gestellt, mit der die Politik dynamisch geändert werden kann.
61
5.5 RACCOON - VBAC
VPL
Precompiler
XML
XML
Verifier
Policy Descriptor
IR
IR
Development
Deployment
IR
IR
XML
Verifier
VR
VR
RR
RR
Die VPL-Politik wird zunächst von einem Precompiler in eine XML-Datei transformiert. Ein
Verifier überprüft dann die Korrektheit der Spezifikation und liefert einen Policy Descriptor.
Dieser dient als Grundlage des Deployments. Auch hier gibt es einen Verifier, der die Politik
auf Konflikte mit bereits existierenden Politiken im System überprüft. Gibt es keine
Konflikte, werden die Views und Schemas im View Repository (VR) und die Rollen im Role
Repository (RR) gespeichert.
62
5.5 RACCOON – VBAC
Domänenhierarchien
• Strukturierung und Generalisierung (Politiken gemäß
Organisationsstruktur, Zuständigkeiten)
• Geltungsbereich der Elterndomäne umfasst
Mitgliedsobjekte der Kinddomänen
Hype Inc.
Europe
Europe
R&D
R&D
AnwendungsAnwendungsdomäne
domäne11
US
USBranch
Branch
Sales
Sales
AnwendungsAnwendungsdomäne
domäne22
...
AnwendungsAnwendungsdomäne
domänenn
RACCOON bietet die Möglichkeit Objekte in Domänen zu organisieren. Die Domänen
ergeben sich beispielsweise aus der Organisationsstruktur oder Zuständigkeiten. Jeder
Domäne wird eine Politik zugeordnet, so dass diese Politik für alle Objekte dieser Domäne
und alle Kinddomänen gilt. Objekte können auch in zwei Domänen liegen (wie das Beispiel
mit Anwendungsdomäne 1 und 2 zeigt).
63
5.5 RACCOON – VBAC
Konflikte zwischen Politiken für ein Objekt sind möglich,
da Domänen hierarchisch angeordnet sind bzw.
gemeinsame Mitglieder haben.
Metapolitiken zur Konfliktauflösung
Auflösung semantikabhängig fi Metapolitiken spezifisch
für Politiktypen
Metapolitiken werden Domänen zugeordnet
Keine Meta-Metapolitiken:
– erste anwendbare Metapolitik gilt
(= Metapolitik passenden Typs in der nächsten
gemeinsamen Elterndomäne)
Es kann vorkommen, dass für ein Objekt mehrere Politiken anwendbar sind. Um diese
Konflikte aufzulösen lassen sich Metapolitiken spezifizieren, die diese Konflikte
semantikabhängig auflösen. Auch die Metapolitiken werden Domänen zugeordnet. Es gibt
jedoch keine Meta-Metapolitiken, falls auf ein Objekt zwei Meta-Politiken anwendbar sein
sollten. In diesem Fall wird die erste anwendbare Metapolitik genommen.
64
Raccoon-Laufzeitumgebung
Role Mgmt.
Domain Mgmt.
Policy Mgmt.
Policy Server
Domain Server
Role
Server
Policy
Policy
Domain
Domain
Roles
Client
request()
Target
Interceptor
Access
Decision
Server
Die RACCOON-Laufzeitumgebung besteht aus einem Role-Server, einem Domain-Server
und einem Policy-Server. Auf dem Role-Server werden die Rollen verwaltet, auf dem
Domain-Server die Domänen und auf dem Politik-Server die Views und Schemas. Möchte
ein Client einen Operation auf einem Zielobjekt ausführen, holt sich der Client seine Rollen
vom Role-Server und fügt sie dem Aufruf der Operation zu. Ein Interceptor fängt den Aufruf
ab, ermittelt die Rollen des Aufrufers und leitet diese an ein Access Decision Object weiter.
Dieses ermittelt, in welcher Domäne das Zielobjekt ist und holt sich die anwendbare Politik.
Anhand der Politik und der gesendeten Rollen wird dann der Zugriff entschieden. Ist er
erlaubt, wird der Aufruf ans Zielobjekt weitergeleitet, ansonsten wird eine SicherheitsAusnahme an den Clienten geliefert. Alle Server können mit graphischen
Managementwerkzeugen administriert werden.
65