Generiek toegangsbeheer voor OSGi-gebaseerde software

Faculteit Ingenieurswetenschappen

Vakgroep Informatietechnologie

Voorzitter: Prof. Dr. Ir. P. LAGASSE

Generiek toegangsbeheer voor

OSGi-gebaseerde software

door

Frederic COENE

Promotor: Prof. Dr. Ir. B. DHOEDT

Scriptiebegeleider: Ir. W. HAERICK

Scriptie ingediend tot het behalen van de academische graad van

licentiaat informatica

Academiejaar 2005–2006

Dankwoord

Dank aan iedereen die het geduld heeft kunnen opbrengen om met me samen te werken, me

gesteund heeft en me de kans gegeven heeft om dit eindwerk te maken, in het bijzonder:

• mijn promotor, prof. dr. ir. B. Dhoedt, voor het scheppen van de mogelijkheid dit

onderzoek te verrichten,

• mijn begeleider, ir. W. Haerick, voor de medewerking en expertise,

• mijn ouders voor de financiele en morele steun die mijn studies mogelijk hebben gemaakt,

• mijn broers, vrienden en familie voor de morele steun tijdens een moeilijk jaar.

Frederic Coene, juni 2006

Toelating tot bruikleen

De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van

de scriptie te kopieren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrek-

king tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit

deze scriptie.

Frederic Coene, juni 2006

Generiek toegangsbeheer voorOSGi-gebaseerde software

door

Frederic COENE

Scriptie ingediend tot het behalen van de academische graad vanlicentiaat informatica

Academiejaar 2005–2006

Promotor: Prof. Dr. Ir. B. DHOEDTScriptiebegeleider: Ir. W. HAERICK

Faculteit IngenieurswetenschappenUniversiteit Gent

Vakgroep InformatietechnologieVoorzitter: Prof. Dr. Ir. P. LAGASSE

Overzicht

Het OSGi Service Platform is een dynamisch module systeem voor Java. Het is een populaireuitvoeringsomgeving voor Java applicaties maar bevat een nogal rudimentair toegangsbeheer-systeem waarbij het beleid via (conditie, permissie) tupels in een permissietabel bijgehoudenwordt. Een schril contrast met de huidige toegangsbeheerraamwerken die met flexibele en uit-breidbare beleidstalen werken. Dit eindwerk werpt eerst een blik op de werking van het OSGitoegangsbeheersysteem. Vervolgens wordt een vergelijking opgesteld van 5 van de voornaamstetoegangsbeheerbeleidstalen, namelijk Rei, Ponder, KAoS, XACML en Protune. En tenslottewordt een generiek toegangsbeheersysteem ontworpen en geımplementeerd op basis van Sun’sXACML 2.0 raamwerk met behulp van JAAS (een Java PAM implementatie) als authenticatie-mechanisme.

Trefwoorden

toegangsbeheer, OSGi, XACML, JAAS

Generic Access Control for OSGi-based SoftwareFrederic Coene

Supervisor(s): Prof. Dr. Ir. B. Dhoedt, Ir. W. Haerick

Abstract—This article is the extended abstract of a dutch thesis entitled”‘Generiek toegangsbeheer voor OSGi-gebaseerde software”’. It’s a studyof how generic, reusable, fine-grained, flexible access control can be ap-plied to an OSGi environment. First the OSGi Framework and it’s currentpossibilies for access control are examined. Next current access control lan-guages Rei, Ponder, KAoS, XACML en Protune are compared with regards totheir flexibility and useability. And lastly a system that allows for more fine-grained and flexible access control for an OSGi environment is developped,based on Sun’s XACML v2.0 access control framework and the JAAS au-thentication mechanism.

Keywords—access control, OSGi, XACML, JAAS

I. INTRODUCTION

THE goal of the thesis this extended abstract is about, is thestudy and implementation of ”‘Generic access control for

OSGi-based software”’. First the reader will be introduced tothe OSGi Service Platform and the concept of generic accesscontrol. Next 2 of the best access control policy languages willbe compared to each other. One has to be selected to use inthe access control framework that will be designed and imple-mented as an illustration of a generic access control system foran OSGi environment. To conclude, the designed system willbe analysed and evaluated.

II. OSGI AND ACCESS CONTROL

A. The OSGi Service Platform

The OSGi Service Platform [2] is a dynamic module systemfor Java. It provides module support, life cycle management,dynamic discovery of new services and dependencies to Java ap-plications. A Java application running in an OSGi environmentis called a bundle, services it offers are defined in it’s serviceinterface and registered with the OSGi service registry.

B. Access control

Access control in computer security can be defined as fol-lowed:The ability to permit or deny the use of/access to an object orresource by a subject.

The access control proces can be split up in 4 subprocesses:• Authentication: The authentication proces tries to verify theidentity of the subject.• Authorization: The authorization proces checks if the subjecthas the right to use the resource and will deny access to theresource if necessary.• Accounting and administration: The accounting and admin-istration processes are optional. Accounting is done by loggingall accessrequests and actions of subjects. Administration refersto the ability to add, delete and change subjects and their rights.

C. Access control functionality in the OSGi FrameworkThe OSGi Framework contains a simple, dynamic access con-

trol system. The enforcement is done through permissions, it’s

an extension of the Java permission model. An access controlrule is represented by a (condition, permission) tuple. For ex-ample:

{[...BundleLocationCondition "http://www.acme.com/*"](...SocketPermission "www.acme.com")

}

A policy is called a permission table and contains tuples en-tered as above. There are only 2 Conditions defined, aBundleLocationCondition and a BundleSignerCondition, allother conditions should be self-implemented. There is defaultsupport to compare strings, combine multiple conditions, etc.

The OSGi access control system is very rudimentary, cer-tainly if the abilities of it’s permission table are compared tothe abilities of current access control languages.

III. ACCESS CONTROL LANGUAGES

A access control language is needed for the new access con-trol system that will be developped. In the comparison of the 5access control languages Rei, Ponder, KAoS, XACML [1] andProtune, only 2 make the final cut: KAoS and XACML. Thecriteria [6], [4], [5], [7] used in this comparison are subdividedin 3 categories:• Flexibility: Some features that can improve the flexibility ofa language are: the ability to specify variables in a policy, thepossibility to combine rules or conditions, support for executingexternal functions, the possibility to include accountinginforma-tion in a policy, the extendability of the language and the set ofpossible conflict resolution algorithms.• Usability: Some language features that can improve usabilityare: the use of declarative rules to define a policy, the readabilityof the language, the availability of implementations and supportapplicaties (such as policyeditors), standardization of the lan-guage.• Reasonability [5]: Characteristics of a language that influencethe reasonability are: the totality of a language (a decision willalways be reached in a total language) and the monotonicity ofa language (the withdrawal of credentials can not lead to addi-tional privileges in a monotone language).

KAoS’ best features are its usability and it’s standard supportfor using accounting information in the access decision. It hasgreat usability thanks to KPAT, the policy administration appli-cation that comes with KAoS.

XACML on the other hand, is more flexible than KAoS, itsupports the use of implicit variables, can execute external func-tions and has better support for combining rules and conditions.XACML is currently the only standardized access control policylanguage.

There is no clear winner in the comparison but XACML isfinally chosen for its flexibility and the fact that it’s standardized.

It’s not unreasonable to expect that support applications will bedevelopped for a standardized language.

IV. ACCESS CONTROL COMPONENT

Now that a policy language has been chosen, the access con-trol component must be designed and implemented.

A. Architecture

The architecture of the access control system and the dataflowthrough the system is shown in figure 1.

Fig. 1. Architecture of and dataflow though the AC system.

It consists of 6 main components:• The Policy Enforcement Point (PEP) enforces a decisionmade by the PDP and is implemented by altering the service abundle provides and making it connect to the ACService beforeexecuting the requested method.• The ACService provides the service interface and delegatesall requests and answers between the PEP’s and the PDP.• The Policy Decision Point (PDP) is the heart of a access con-trol system, the access control decision are made here, basedon a request, a policy and the information gotten from the PIP.Sun’s XACML 2.0 implementation is used to implement thePDP.• The Policy Authentication Point authenticates the subjects ofaccess requests. The Java PAM (Pluggable Authentication Mod-ules) implementation JAAS is used for authentication. It is adynamic and extendible authentication mechanism.• The Policy Information Point answers to information ques-tions coming from the PDP, the implementation is based onSun’s XACML and is extended to support accounting and theexecution of OSGi bundle methods (so the information retrievedby these methods can be used by the PDP).• The Policy Administration Point is a simple file-based admin-istration component with a push-based delivery system. When-ever a policy is changed, the policy is pushed to the PDP.

V. EVALUATION

A. Flexibility

XACML’s flexibility is excellent, it has a decent set ofdatatypes and has lots of standard functions defined for thesetypes. It uses a Target (which is a simplified condition) to checkif a request is applicable to the current rule or policy. This makesit possible to define implicit variables and also to index policiesby applicability to a subject or resource. The XACML frame-work can be extended by defining new datatypes, functions orattribute finders.

B. Usability

Although a program is developped to automate the proces ofadding access control code to a bundle that needs to be pro-tected, this program is not very thrustworthy. It has to decompilea Java class and this proces might fail if the given class containscomplex, recent (Java 1.4+) code.

XACML has no support at all for policy administration.Luckily XACML is based on XML, so it’s structured and hu-manreadable and a policy can still be edited by an XML-editor.Still, XACML needs a real policy administration application.The fact that XACML is standardized, enlarges the chance thatthis will happen.

VI. CONCLUSIONS

The OSGi access control system and language lack both flex-ibility and usability, it’s permission table system is inadequate.

The access control system that was designed, based onXACML certainly does not lack flexibility. But to maximizeflexibility, usability had to be reduced. The system is able toenforce policy decision at the method level, it’s a very flexible,fine-grained and extendible system. But the PEP is its weakpoint, a PEP has to be constructed from the bundle that needsto become access controlled, before it is installed in the OSGiFramework. There’s no way to just enable access control for abundle installed in an OSGi environment without deinstalling,editing and reinstalling the bundle.

REFERENCES

[1] OASIS eXtensible Access Control Markup Language (XACML) TC. URLhttp://www.oasis-open.org/committees/xacml/.

[2] The OSGi Service Platform - The Dynamic Module System for Java. URLhttp://www.osgi.org/.

[3] Sun’s XACML Implementation. URL http://sunxacml.sourceforge.net.

[4] Serge Bogeholz Mark Evered. A Case Study in Access Control Require-ments for a Health Information System. Technical report, University ofNew England, Australia, 2004.

[5] Shriram Krishnamurthi Michael Carl Tschantz. Towards ReasonabilityProperties for Access-Control Policy Languages. Technical report, 2006.

[6] Daniel Olmedilla Piero A. Bonatti. Semantic Web Policies: Where are weand What is still Missing? Technical report, Rewerse, 2006.

[7] Alvaro Arenas Syed Naqvi, Philippe Massonet. A Study of Languages forthe Specification of Grid Security Policies. Technical report, CoreGRID,2006.

INHOUDSOPGAVE i

Inhoudsopgave

1 Inleiding 1

1.1 Toegangsbeheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Generiek toegangsbeheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 OSGi en toegangsbeheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Conditional Permission Admin . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.2 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Probleem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5 Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Vereisten 12

2.1 OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.1 BundleLocationCondition en BundleSignerCondition . . . . . . . . . . . . 13

2.2 Gebruiker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Beleid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1 Flexibiliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.2 Beleidsadministratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Authenticatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Algemeen ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.1 Access control framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.2 OSGi Framework en access control framework verweven . . . . . . . . . . 16

3 Keuze van de beleidstaal 18

3.1 Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1 Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

INHOUDSOPGAVE ii

3.2 Toegangsbeheerbeleidstalen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Rei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.2 Ponder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.3 KAoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.4 XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.5 Protune . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Vergelijking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Toegangsbeheercomponent 33

4.1 Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1 Authenticatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.2 Authorisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.3 Beleidsadministratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.4 Beleidsbeslissing afdwingen . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Introductie tot XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3.1 PAuthP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3.2 ACService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.3 PAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3.4 PEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3.5 Compatibiliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5 Evaluatie 64

5.1 Configuratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1.1 Installatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1.2 Configuratiebestanden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2 Testopstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3 Flexibiliteit van het beleid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.4 Gebruiksgemak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.4.1 Installatie van een bundel met toegangsbeheer . . . . . . . . . . . . . . . 74

5.4.2 Administratie van het beleid . . . . . . . . . . . . . . . . . . . . . . . . . 74

INHOUDSOPGAVE iii

6 Besluit 76

6.1 Doel bereikt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

INLEIDING 1

Hoofdstuk 1

Inleiding

Generiek toegangsbeheer voor OSGi-gebaseerde software, een hele mond vol. In dit inleidend

hoofdstuk worden de belangrijkste begrippen, namelijk ”toegangsbeheer” en ”OSGi”, uitgelegd.

In sectie 1.3 wordt duidelijk gemaakt wat beide met elkaar te maken hebben. En op het einde

van het hoofdstuk worden de probleem- en doelstellingen uiteengezet.

1.1 Toegangsbeheer

We vinden stoplichten in de straten en sloten op de deuren van onze huizen, beide zijn voor-

beelden van fysisch toegangsbeheer. In het veld van de computerbeveiliging vinden we overeen-

komstige systemen, namelijk firewalls en proxies die de toegang tot netwerkbronnen beperken

en loginmechanismen die met een digitale sleutel werken. Het hier beoogde toepassingsgebied is

natuurlijk de computerbeveiliging.

Het voornaamste doel van toegangsbeheer is het beschermen van de confidentialiteit en

integriteit van informatie, systemen en bronnen. M.a.w. verzekeren dat informatie/systemen

enkel toegangelijk zijn voor geauthoriseerde gebruikers en veilig zijn voor niet-geauthoriseerde

veranderingen.

Definitie

Toegangsbeheer is de mogelijkheid tot het toelaten of verbieden van het gebruik van een object

(passieve entiteit zoals een systeem, bestand) door een subject (gebruiker, actieve entiteit zoals

een individu of proces). De basis van toegangsbeheer bestaat uit authenticatie en authorisa-

tie. Het authenticatieproces tracht de identiteit van het subject te verifieren, m.a.w. het tracht

1.1 Toegangsbeheer 2

te achterhalen of het subject is wie of wat het claimt te zijn. Het authorisatieproces controleert

of het subject voldoende rechten heeft voor het beoogde gebruik van het object en zal al dan

niet de toegang tot het object weigeren.

Uitbreiding

Een goed toegangsbeheersysteem zorgt buiten authenticatie en authorisatie ook voor accounting

en administratie. Accounting wordt uitgevoerd door het, in detail, loggen van de acties van het

geauthenticeerde subject. Het zo bekomen logboek wordt aangewend bij o.a. auditing, trend

analyse, facturatie, capaciteitsplanning en authorisatiebeslissingen. Administratie verwijst naar

het vermogen om gebruikers en hun privileges toe te voegen, te verwijderen en aan te passen en

zo dus de authenticatie- en authorisatiebeslissingen aan te passen.

Beleid

Een flexibel toegangsbeheersysteem zal steeds een onderscheid maken tussen het toegangsbeheer-

beleid en het mechanisme (of methode). Het mechanisme bepaalt hoe het beslissingssysteem

werkt en het beleid bepaalt wat er beslist wordt. Bij een flexibel systeem kan het beleid ver-

anderen zonder dat het nodig is om het mechanisme aan te passen, beleid en mechanisme zijn

onafhankelijk van elkaar. In het slechtste (minst flexibele) geval zal elke verandering van het

beleid een verandering in het mechanisme vereisen.

Toegangsbeheerbeleidstaal

De taal die gebruikt wordt om het beleid van een toegangsbeheersysteem te definieren, noemt

men de toegangsbeheerbeleidstaal (Eng. access control policy language).

Mechanisme

De belangrijkste types van toegangsbeheermechanismen zijn:

• discretionary access control (DAC): De eigenaar van het object bepaalt wie er toegang

heeft en welke privileges ze hebben.

• mandatory access control (MAC): De beheerder van het systeem legt het toegangsbeleid

van de objecten vast.

1.2 OSGi 3

• role-based access control (RBAC): De toegangsbeslissingen zijn gebaseerd op de rollen

(functies) die de individuele gebruikers hebben als deel van een organisatie. Gebruikers

worden 1 of meerdere rollen toegekend (zoals bijvoorbeeld dokter, verpleegster, secretares-

se, database-administrator).

• rule-based access control: Toegangsbeslissingen worden genomen op basis van op voorhand

bepaalde en geconfigureerde regels.

• lattice-based access control (LBAC): Wordt gebruikt voor complexe toegangsbeslissingen

over verschillende objecten en/of subjecten. Via rolhierarchie en beperkingen kan men een

RBAC zo configureren dat die een LBAC simuleert.

1.1.1 Generiek toegangsbeheer

Generiek wordt gedefinieerd als ”gerelateerd aan of toepasbaar voor grote klassen of groepen

in tegenstelling tot specifiek”. Generiek toegangsbeheer is dus toegangsbeheer toepasbaar op

een grote groep systemen/applicaties, m.a.w. niet verweven met een specifiek systeem. Het

toegangsbeheermechanisme is (deels) onafhankelijk van de beschermde objecten.

Het grote voordeel van een generiek toegangsbeheersysteem is herbruikbaarheid. Het is

ontworpen om te werken met een grote groep applicaties en bespaart dus de moeite om voor

elke applciatie afzonderlijk een toegangsbeheersysteem te bedenken en uit te werken. Maar

doordat het systeem generiek is, kan het geen rekening houden met applicatiespeficieke noden.

Een generiek systeem lijkt dus aan flexibiliteit te moeten inboeten. De oplossing hiervoor bestaat

erin om het systeem uitbreidbaar te maken. Wanneer applicatiespecifieke functies noodzakelijk

zijn, kunnen die dan gedefinieerd worden.

1.2 OSGi

OSGi Alliance

De OSGi [6](Open Services Gateway initiative) Alliance is een open forum met als missie het

specificeren, creren, verbeteren en promoten van een open diensten platform voor de levering

en het beheer van meerdere applicaties en diensten op alle types van genetwerkte apparaten

in thuis, voertuig, mobiele en andere omgevingen. Ze werd in 1999 opgericht door o.a. Sun

Microsystems, IBM en Ericsson.

1.2 OSGi 4

De leden van de OSGi Alliance komen uit verscheidene takken van de bedrijfswereld, o.a.

uit de automobiele en consumenten elektronica, dienstenlevering en technologie gemeenschap-

pen. Oorspronkelijk was het OSGi framework bedoeld voor service gateways, maar uiteindelijk

kwamen er toepassingen in een breder domein. De specificaties vinden nu hun toepassing in een

verscheidenheid aan applicaties, van mobiele telefoons tot de open-source Eclipse IDE. Andere

toepassingen vindt men in auto’s, industrile automatisering, domotica, PDA’s, grid computing

en fleet management (zie Figuur 1.1).

Figuur 1.1: OSGi toepassingen

De OSGi Alliance is een non-profit organisatie die zelf geen producten aanbiedt, het ont-

wikkelt enkel de OSGi specificatie en stelt deze vrij van kost en zonder licentie voorwaarden ter

beschikking. OSGi implementaties van leden kunnen wel door de OSGi Alliance gecertificeerd

worden via het ”Compliance Program”.

OSGi technologie

De OSGi specificaties definieren een open standaard, component-georienteerde uitvoeringsom-

geving voor genetwerkte diensten. Het toevoegen van een OSGi Service Platform aan een net-

werkapparaat, voegt de mogelijkheid toe om de levenscyclus van de software componenten in dat

apparaat van gelijk waar op het netwerk te beheren. Software componenten kunnen ”on the fly”

geınstalleerd, upgedate of verwijderd worden zonder de werking van het apparaat te onderbre-

ken. Software componenten zijn bibliotheken of applicaties die dynamisch andere componenten

kunnen ontdekken en gebruiken. De OSGi Alliance heeft standaard component interfaces ont-

wikkeld zoals HTTP servers, configuratie, logging, beveiliging, gebruikersadministratie, XML en

vele andere.

1.2 OSGi 5

Software component architecturen adresseren een toenemend probleem in software ontwik-

keling: het grote aantal aan configuraties die moeten ontwikkeld en onderhouden worden. De

gestandaardiseerde OSGi component architectuur vereenvoudigt dit configuratieproces aanzien-

lijk.

De kern van de OSGi specificatie bestaat uit het OSGi Framework. Het Framework stelt

een gestandaardiseerde omgeving ter beschikking van de applicaties (bundels genoemd), het is

dus een middleware laag tussen de Java uitvoeringsomgeving en de bundels. Het Framework is

opgedeeld in een aantal lagen (zie Figuur 1.2):

• L0: Uitvoeringsomgeving: Dit is de specificatie van de Java omgeving, OSGi heeft er

verschillende gedefinieerd waaronder een standaard en een minimum OSGi specificatie.

• L1: Modules: Deze laag definieert het beleid voor het laden van klassen. De mogelijkheden

van het standaard Java platform qua packaging, deployen en valideren van Java-gebaseerde

applicaties en componenten zijn beperkt. De Modules-laag breidt standaard Java uit met

private klassen voor modules en gecontroleerd linken tussen modules.

• L2: Levenscyclus Beheer: Bundels kunnen dynamisch geınstalleerd, gestart, gestopt, up-

gedate en gedeınstalleerd worden via de levencycluslaag.

• L3: Diensten Registratie: De L3 laag voegt een dynamisch register voor de diensten toe.

Het traditioneel Java model voor samenwerking van klassen werkt niet goed in een om-

geving waar code dynamisch geınstalleerd en gedeınstalleerd wordt. Het dienstenregister

biedt een uitgebreid model om objecten te delen in een dergelijk omgeving.

Verder is er nog een (optioneel) beveiligingssysteem verweven door alle lagen. Het is gebaseerd

op de Java 2 beveiliging architectuur [2] en biedt de infrastructuur aan om applicaties op te

stellen en te administreren die in een fijnkorrelig beheerde omgeving moeten draaien.

OSGi bundels en diensten

Een minimale kennis over de werking van OSGi bundels en diensten is noodzakelijk voor latere

discussies. Het OSGi Framework definieert een eenheid van modularisatie, namelijk een bundel.

Een bundel bestaat uit Java klassen en andere bronnen, die samen functies aan eindgebruikers

kunnen aanbieden. Bundels kunnen Java packages delen tussen een exporterende bundel en een

importerende bundel op een goed-gedefinieerde wijze.

1.3 OSGi en toegangsbeheer 6

Figuur 1.2: OSGi architectuur

In het OSGi platform zijn bundels gebouwd rond een verzameling samenwerkende diensten

beschikbaar via een gedeeld dienstenregister. Zo een OSGi dienst is semantisch gedefinieerd

door zijn service interface en geımplementeerd als een service object.

Het service object is onderdeel van (en voert uit in) een bundel. Deze bundel moet het

service object registreren bij het OSGi Framework dienstenregister zodat de functionaliteit van

de dienst (i.e. de methoden van de service interface) beschikbaar is voor andere bundels onder

controle van het OSGi Framework.

Indien bundel A het gebruik van de dienst van bundel B aan het dienstenregister vraagt, zal

bundel A een referentie van de service interface van B terugkrijgen. Deze referentie zal verwijzen

naar een instantie van het service object van B. Bundel A kan nu gebruik maken van de diensten

van B door methodes uit de service interface van B rechtstreeks uit te voeren.

1.3 OSGi en toegangsbeheer

Welke faciliteiten voor toegangsbeheer zijn in het OSGi Framework voorzien? Deze vraag moet

eerst beantwoord worden vooraleer verder gegaan wordt.

De voorzieningen voor toegangsbeheer in OSGi zijn op de Java 2 Security Architecture [2]

gebouwd, meer bepaald op het permissie model (waarvin de Permission1 klasse centraal staat).

Het OSGi Framework biedt een goed-gedefinieerde API om permissies in ware tijd te beheren. Er1java.security.Permission


moet opgemerkt worden dat de beveiligingslaag, waarin alle toegangsbeheerfuncties bevat zitten,

optioneel is. Niet elke OSGi implementatie zal deze functionaliteit bezitten, de implementatie

zal dan enkel stubs bevatten die niets uitvoeren en steeds positief antwoorden.

Java 2 permissie model

Een permissie (Permission object) vertegenwoordigt de toegang tot een systeembron[17]. Om

toegang te krijgen tot een systeembron heeft een Java applicatie met security manager (zoals de

OSGi uitvoeringsomgeving) de overeenkomstige permissie nodig die expliciet toegang verleent

aan de uitvoerende code tot de gewenste bron. Een permissie ziet er als volgt uit:

perm = new ServicePermission("org.osgi.service.http.HttpService", "REGISTER");

Het eerste argument slaat typisch op de naam van de klasse waarvoor men de permissie wil

instellen, het volgende argument is een, met komma’s afgescheiden, lijst van acties. Het boven-

staande voorbeeld stelt dus een permissie voor om de actie REGISTER op de dienst HttpService

uit te voeren, m.a.w. de permissie perm geeft dus de toelating om de dienst HttpService te

registreren. De permissie perm representeert wel de toegang tot een systeembron maar vergunt

nog steeds aan niemand toegang. Permission objecten moeten toegekend worden aan stukken

code door het beleid dat actief is in de security manager.

OSGi permissie model

Zoals eerder gezegd breidt de OSGi specificatie[19] de Java 2 Security Architecture uit. Het

OSGi toegangsbeheersysteem is volledig gebaseerd op het Java 2 permissie model. De stukken

code waaraan een Permission object kan toegekend worden, zijn de OSGi bundels. Het is

niet mogelijk om permissies aan kleinere stukken code toe te kennen, dit vereenvoudigt de OSGi

security API doordat alle code van een bundel in hetzelfde beveiligde domein uitgevoerd worden.

Tot de OSGi R4 specificatie in oktober 2005 werd uitgebracht, was het enkel mogelijk om

via de PermissionAdmin onvoorwaardelijke permissies toe te kennen aan bundels en de bundels

konden enkel geauthenticeerd worden op basis van de locatie[18] waarvan ze geınstalleerd werden

(al dan niet lokaal). Sinds de R4 specificatie kunnen bundels ook digitaal ondertekend worden

en werd er een Conditional Permission Admin service toegevoegd, die de permissies van bundels

beheert via een conditioneel model waarbij de condities kunnen testen op locatie of het subject

dat de bundel digitaal ondertekend heeft.


Soorten permissies

Met de standaard Java 2 permissies is het mogelijk om de toegang tot het bestandssysteem, net-

werk, geluid, runtimesysteem e.a. te beheren. OSGi heeft het Java 2 permissie model uitgebreid

met:

• AdminPermission: geeft de authoriteit aan om specifieke, geprivilegeerde administratieve

operaties uit te voeren op of gevoelige informatie op te vragen over een bundel.

• BundlePermission: de authoriteit van een bundel om een andere bundel te vereisen of

aan te bieden of om fragmenten te ontvangen of te bevestigen.

• ConfigurationPermission: wijst op de authoriteit om bundels te configureren.

• PackagePermission: de authoriteit om een package te importeren of exporteren.

• ServicePermission: de authoriteit om een dienst te registreren of te gebruiken.

• TopicPermission: geeft de authoriteit van een bundel aan om over een onderwerp te

publiceren of zich in te schrijven op een onderwerp.

• UserAdminPermission: een permissie die de toelating geeft om toegang te krijgen tot de

gebruikers en hun functies en ze te configureren.

• WirePermission: de authoriteit om tokens op een Wire-object (dat gebruikt wordt voor

communicatie) te consumeren of te produceren.

De belangrijkste van bovenstaande permissies is de ServicePermission, deze vertegenwoordigt

de toelating om een ServiceObject van een bundel te verkrijgen en bijgevolg ook de toelating

om alle publieke methodes van dat ServiceObject uit te voeren.

1.3.1 Conditional Permission Admin

De conditionele permissies bieden een zeer algemeen model dat gerelateerd is aan maar toch

verschillend is van het Java 2 Policy model. Dat model kent een verzameling permissies toe aan

een bepaald stuk code of een ondertekenend subject.

Het Conditional Permission Admin service model hanteert een meer algemene benaderings-

wijze. Conceptueel heeft het een permissie tabel die voor het volledige systeem geldt. Elke

conditionele permissie in deze tabel is toepasbaar op alle bundels die de juiste voorwaarden (con-

dities) vervult. De tabel bestaat uit [verzameling van voorwaarden, verzameling van permissies]


tupels. De permissies (toelatingen) van een tupel zijn enkel geldig wanneer alle voorwaarden in

de verzameling van voorwaarden voldaan zijn ten tijde van de permissiecontrole.

{

[ ...BundleLocationCondition "http://www.acme.com/*" ]

( ...SocketPermission "www.acme.com" )

}

{

[ ...BundleLocationCondition "http://www.et.com/*" ]

[ ...Prompt "Call home?" ]

( ...SocketPermission "www.et.com" )

}

Figuur 1.3: Uittreksel uit een permissie tabel

Zoals eerder gezegd zijn de door de OSGi specificatie gedefinieerde voorwaarden beperkt, er

kan enkel getest worden op de locatie van een bundel (BundleLocationCondition2) en op de

ondertekenaar van een bundel (BundleSignerCondition3). Het is echter ook mogelijk om zelf

voorwaarden te definieren door de Condition interface 4 uit te breiden. Zo kan je een condi-

tionele permissie laten afhangen van externe voorwaarden, zoals bijvoorbeeld, een ingevoerde

SIM kaart, gebruikersinteractie of een succesvolle connectie met authorisatieserver. De moge-

lijkheden zijn legio, op voorwaarde dat ze geımplementeerd worden door de Condition interface

uit te breiden. Het tupel systeem van de permissietabel maakt een flexibel en complex beleid

voeren echter zeer ingewikkeld. Het combineren van condities is niet mogelijk, er kan geen ge-

bruik gemaakt worden van variabelen, elke soort van conditie die men wil instellen, moet zelf

geprogrammeerd worden, etc.

1.3.2 Besluit

De (optionele) beveiligingslaag van het OSGi Framework bevat dus effectief een toegangsbeheer-

systeem. Maar de functionaliteit van dit systeem blijft toch beperkt, authenticatie kan enkel2org.osgi.service.condpermadmin.BundleLocationCondition3org.osgi.service.condpermadmin.BundleSignerCondition4org.osgi.service.condpermadmin.Condition

1.4 Probleem 10

op bundel of ondertekenaar gebeuren (tenzij nieuwe Condition-klassen worden gecreeerd). Erg

fijn-korrelig is het ook niet, het toegangsbeheer op het bundelniveau is het maximum haalbare,

toegangsbeheer op methodeniveau is niet mogelijk. Een permissie tabel is wel een heel rudimen-

tair systeem om een beleid uit te drukken, een echte beleidstaal heeft veel meer mogelijkheden

en zal meer kunnen uitdrukken in minder regels (1 complexe regel kan vele tupels vervangen).

1.4 Probleem

De probleemstelling sluit aan op het besluit van de vorige sectie. Omdat permissies in OSGi

enkel toegekend kunnen worden aan bundels en niet aan afzonderlijke methodes van bundels, is

het dus niet mogelijk om toegangsbeheer op methodeniveau af te dwingen, gebruik makend van

de bestaande OSGi API.

De voorwaarden die kunnen gesteld worden om conditionele permissies toe te kennen zijn

standaard zeer beperkt. Het uitbreiden van een interface voor elke verschillende gestelde voor-

waarde, getuigt niet van bruikbaarheid. Zonder eenvoudig te veranderen voorwaarden is een

flexibel beleid voeren praktisch niet mogelijk is. Het zelf uitbreiden van de verzameling condi-

ties, is bijna gelijk aan een nieuwe beleidstaal implementeren.

De permissietabel komt tekort als structuur om een beleid in uit te drukken. Er ontbreken

vele functies om een flexibel beleid te kunnen voeren, bijvoorbeeld een mogelijkheid om condities

te combineren, permissietabellen te combineren (via bepaalde algoritmen), ondersteuning voor

variabelen, etc.

1.5 Doelstelling

Zoals de titel Generiek toegangsbeheer voor OSGi-gebaseerde software al laat vermoeden, is het

doel van deze thesis te onderzoeken hoever generiek toegangsbeheer mogelijk is in het OSGi

Framework en dan ook een implementatie te ontwikkelen.

De voornaamste voorwaarden waar de toegangsbeheercomponent aan moet voldoen zijn:

• Generiek: Toepasbaar op willekeurige OSGi bundels, zonder nood aan bijkomend pro-

grammeren.

• Flexibel: Een flexibel beleid voeren moet tot de mogelijkheiden behoren zonder nood aan

programmeren of kennis van het interne systeem, enkel het beleid moet aangepast worden.

De beleidstaal moet expressief en uitbreidbaar zijn zodat een flexibel beleid voeren mogelijk

1.5 Doelstelling 11

is. Het systeem moet de mogelijkheid bevatten om toegangsbeheer op methodeniveau af

te dwingen. Ook accounting kan de flexibiliteit van een systeem verbeteren.

• Bruikbaar:

Too often, only the PhD student that designed a policy language or framework

can use it effectively. 5

Deze uitspraak is spijtig genoeg waar. Het is dus niet de bedoeling dat enkel de ontwer-

per kan omgaan met de toegangsbeheercomponent. Een beleid voeren, veranderen, het

activeren van toegangsbeheer voor een bundel mogen geen duistere, omslachtige, slecht

gedocumenteerde handelingen vergen. Beleidsbeheer moet bij voorkeur ook met hiervoor

ontworpen applicaties (tools) kunnen gebeuren en niet enkel manueel.

• OSGi API: Enkel en zoveel mogelijk gebruikmakend van de standaard OSGi API. Het is

niet de bedoeling om een enkele OSGi implementatie te hacken om het doel te bereiken

maar een component te ontwerpen die met alle standaard OSGi implementaties werkt.

OSGi bevat bruikbare functies (bijvoorbeeld ondertekende bundels) en er moet getracht

worden om zoveel mogelijk functionaliteit te hergebruiken/incorporeren.

• Authenticatie: De authenticatie ten opzichte van de toegangsbeheercomponent moet op

verschillende wijzen kunnen gebeuren. Een uitbreidbaar, gestandaardiseerd mechanisme

zou ideaal zijn. Gewenste authenticatievormen zijn o.a. wachtwoord, X.509-certificaat,

oproepende bundel.

5door Kent E. Seamons, Semantic Web Policy Workshop panel, ISWC 2005

VEREISTEN 12

Hoofdstuk 2

Vereisten

Dit hoofdstuk bevat de noodzakelijke vereistenanalyse, in het inleidend hoofdstuk werden al

enkele vereisten (voorwaarden) aangekaart, hier worden ze uitgediept en worden ook nieuwe

vereisten opgeworpen.

Sectie 2.5 handelt over het algemeen ontwerp van de toegangsbeheercomponent. Met de

vereisten en de architectuur van het OSGi Framework in gedachten, kan er al aardig wat over

het algemeen ontwerp gezegd worden.

2.1 OSGi

Zoals eerder gezegd, is het de bedoeling om een toegangsbeheercomponent te ontwerpen die com-

patibel met het OSGi Framework is, niet enkel compatibel met de een of andere implementatie.

Dit betekent concreet dat de component enkel gebruik mag maken van de OSGi specificaties,

meer bepaald de huidige OSGi Service Platform Core Specification Release 4 van augustus 2005.

Zolang enkel de OSGi API methodes en klassen gebruikt worden, zal de toegangsbeheercom-

ponent op alle (volledige) OSGi (Release 4) implementaties draaien. Waarom moet ”volledige”

vermeld worden? Er bestaat namelijk ook een minimale OSGi uitvoeringsomgeving specificatie,

waar de optionele beveiligingslaag volledig is uit weggelaten. Wat de beperkingen van de toe-

gangsbeheercomponent in een minimale OSGi omgeving zijn, zal in sectie 4.3.5 van hoofdstuk 4

blijken.

Een tweede vereiste in verband met OSGi is: hergebruik. Welke onderdelen van het OSGi

Framework kunnen geıncorporeerd worden in de toegangsbeheercomponent? Welke OSGi klas-

sen en methodes zijn bruikbaar met het oog op toegangsbeheer?

2.2 Gebruiker 13

OSGi permissie model

Is het mogelijk om het OSGi permissie model te gebruiken om toegangsbeheer af te dwingen?

Met andere woorden, op basis van de beleidsbeslissing de permissies van de nodige bundels te

veranderen om zo de toegang tot deze bundels te verhinderen of toe te laten?

Het antwoord is neen, dit is niet mogelijk. OSGi bevat een permissie, de ServicePermission,

die kan verhinderen dat een dienst verkregen (en bijgevolg gebruikt) wordt maar het bevat geen

permissie die dit ongedaan kan maken. Eens de dienst verkregen is, kunnen OSGi permissies

het gebruik van deze dienst niet meer verhinderen, wat onaanvaardbaar is. Indien de dienst niet

vrijgegeven wordt tussen methodeoproepen door, kan men zo beleidsveranderingen omzeilen.

Indien een dienst bijvoorbeeld achtereenvolgens met verschillende credentials gebruikt wordt,

zonder deze dienst vrij te geven, kan OSGi het beleid (dat van toepassing is voor deze andere

credentials, dan degene waarmee de dienst verkregen is) niet afdwingen.

2.1.1 BundleLocationCondition en BundleSignerCondition

De BundleLocationCondition en BundleSignerCondition zijn de 2 door OSGi gedefinieerde

standaard condities zoals reeds in 1.3.1 vermeld werd. De eerstgenoemde kan een OSGi bundel

op locatie authenticeren en de tweede op ondertekenaar van een bundel. Beide zullen zeker

geıncorporeerd moeten worden in het authenticatieonderdeel van de toegangsbeheercomponent.

Ze bieden de nodige vorm van ”interne” authenticatie aan, in tegenstelling tot authenticatie via

een wachtwoord, X.509-certificaat, een Radius of Kerberos server dat allemaal buiten het OSGi

Framework plaatsvindt.

2.2 Gebruiker

Gebruiksvriendelijkheid is een steeds een belangrijke vereiste. Een systeem dat uiterst moeilijk

is om op te zetten en te onderhouden zal weinig of niet gebruikt worden.

Indien de gebruiker zelf code moet schrijven om toegangsbeheer voor zijn bundel te verkrij-

gen, dan kan dit niet echt ”generiek” toegangsbeheer genoemd worden. De toegangsbeheercom-

ponent moet met willekeurige bundels kunnen werken zonder dat deze bundels aangepast hoeven

te worden.

Een OSGi systeem is niet noodzakelijk een volwaardige computer, het kan een embedded

systeem zijn, een systeem waar geen toetsenbord en scherm aanhangt. Het installatieproces van

2.3 Beleid 14

de toegangsbeheercomponent en de configuratie van toegangsbeheer voor bundels mogen dus

geen interactieve processen zijn. Het moet mogelijk zijn om ze vanop een andere, genetwerkt

systeem uit te voeren, zoals de traditionele bundels ook kunnen geınstalleerd en geconfigureerd

worden.

2.3 Beleid

2.3.1 Flexibiliteit

De flexibiliteit van het beleid hangt voor het grootste deel af van de expressiviteit van de

beleidstaal. De keuze van de beleidstaal en de hierbij gebruikte criteria worden uitgebreid

toegelicht in hoofdstuk 3.

Toegangsbeheer op basis van de toegangsgeschiedenis van het betreffende doelobject is een

onderdeel van accounting (zie 1.1) en hangt (meestal) niet af van de expressiviteit van de taal

maar is eerder een implementatieprobleem. Het bijhouden van de toestand (Eng. state) of

een geschiedenis van alle (al dan niet succesvolle) toegangsverzoeken en de overeenkomstige

taalelementen komen later nog aan bod.

2.3.2 Beleidsadministratie

Beleidsadministratie is traditioneel een complexe taak. Een systeem dat te complex is om te

beheren, wordt onbruikbaar. Alle beschikbare hulp moet gebruikt worden, hierbij wordt gedacht

aan gespecialiseerde applicaties.

2.4 Authenticatie

Een uitbreidbaar authenticatiemechanisme is zeker een vereiste waarbij de minimale set van

authenticatiemethoden bestaat uit:

• gebruikersnaam en wachtwoord

• X.509-certificaat

• authenticatie op bundel

Authenticatie op bundel zit in het OSGi Framework verweven (zie 2.1.1). Voor de andere

methodes moet er zelf gezorgd worden. Hiervoor kunnen uitbreidbare, gestandaardiseerde au-

2.5 Algemeen ontwerp 15

thenticatiemechanismen zoals PAM [31] (Pluggable Authentication Modules) die verschillende

authenticatiemethodes integreren in een hogere niveau API, gebruikt worden.

2.5 Algemeen ontwerp

2.5.1 Access control framework

De 2 belangrijkste architecturale bouwstenen van een toegangsbeheerraamwerk [16, 34] (Eng.

access control framework) zijn:

• PEP (Policy Enforcement Point) of AEF (Access Control Enforcement Function, ISO

benaming)

• PDP (Policy Decision Point) of ADF (Access Control Decision Function, ISO benaming)

Een PEP is een plaats waar de beleidsbeslissingen effectief afgedwongen worden. Het is een

component die applicatie afhankelijk is en verweven zit op de plaatsen waar de toegang tot

een object werkelijk kan verhinderen. Het PDP is de component waar de beleidsbeslissingen

genomen worden. Het PDP kan gebruik maken van extra mechanismen om een grotere func-

tionaliteit te bekomen, zoals bijvoorbeeld gebruikersauthenticatie, accounting (zie 1.1), opslag

van beleidsinformatie (beleidsdatabase), opvragen van beslissingsinformatie (PIP, Policy Infor-

mation Point), etc. Figuur 2.1 toont een eenvoudig configuratie van een toegangsbeheersysteem.

Figuur 2.1: Eenvoudig toegangsbeheerraamwerk: Het PDP kan verdere mechanismen gebruiken

met het zicht op accounting, authenticatie, opslag van het beleid, ...

De basisinteractie tussen de componenten begint bij een PEP. Het betreffende PEP krijgt

een aanvraag binnen dat een beleidsbeslissing vergt. Bij een dergelijke gebeurtenis construeert


het PEP een verzoek om een beleidsbeslissing en stuurt die door naat het PDP. Deze vraag

voor beleidsbeheer van het PEP naar het PDP bevat 1 of meerdere beleidselementen1 inclusief

het doelobject van de toegang. Het PDP ontleedt het verzoek, maakt zonodig gebruik van

een authenticatiemechanisme, beleidsdatabase, e.d. en zendt zijn beleidsbeslissing terug. Het

betreffend PEP zal dan de beleidsbeslissing afdwingen door de aanvraag te aanvaarden of te

weigeren.

Belangrijk in dit geheel maar niet zo zichtbaar is de taal waarmee het beleid gespecificeerd

wordt in het PDP. Hoofdstuk 3 behandelt de volledige keuze van de beleidstaal.

2.5.2 OSGi Framework en access control framework verweven

Aangezien het doel toegangsbeheer op methodeniveau is, moet in elke methode van elke bundel

(waarvoor toegangsbeheer gewenst is) een beleidsbeslissing kunnen afgedwongen worden en dient

er dus voor elke methode van elke bundel een PEP te zijn. Om de flexibel beleid te kunnen

voeren, moet er genoeg informatie voorhanden zijn, de mogelijkheid om informatie uit accounting

of van een andere bundel op te vragen is dus een vereiste.

Aangezien het toegangsbeheerraamwerk op het OSGi Framework gebouwd wordt, zal het

PDP logischerwijze een OSGi applicatie zijn, een OSGi bundel dus.

De basisinteractie zal nu als volgt verlopen: indien een bundelmethode opgeroepen wordt,

zal het overeenkomstige PEP een toegangsaanvraag opstellen en naar het PDP versturen. Het

subject van de aanvraag zal moeten geauthenticeerd worden, vervolgens moet de toegangsbe-

slissing genomen worden. Hiervoor moet het beleid opgehaald worden uit de beleidsdatabase en

indien noodzakelijk voor de authorisatiebeslissing kan nog extra informatie opgehaald worden

afkomstig van accounting of een willekeurig bundel. Vervolgens wordt de beslissing teruggezon-

den naar het PEP in de betreffende bundel en zal de opgeroepen methode al dan niet uitgevoerd

worden.

Rekening houdend met de vereisten qua beleidsadministratie geformuleerd in 2.3.2, is er

nood aan een afzonderlijke beleidsdatabase die beschikbaar is voor het PDP en een beleidsad-

ministratieapplicatie. Het eenvoudige toegangsbeheerraamwerk uit figuur 2.1 kan nu uitgebreid

worden tot figuur 2.2.

1Eng. Policy Element, bevat de basiseenheid van informatie die gebruikt wordt bij de evaluatie van een

beleidsregel. Een beleidselement kan bijvoorbeeld de identificatie van een gebruiker of applicatie bevatten, een

andere bijvoorbeeld een argument van een methode die men wil oproepen.


Figuur 2.2: Toegangsbeheerraamwerk onder OSGi (PEP, PDP, Beleidsadministratie en BundelB

zijn OSGi bundels)

KEUZE VAN DE BELEIDSTAAL 18

Hoofdstuk 3

Keuze van de beleidstaal

De beleidstaal is het belangrijkste onderdeel van de toegangsbeheercomponent. Het installeren

van de component en activeren van toegangsbeheer voor bundels zijn eenmalige gebeurtenissen

maar het toegangsbeheerbeleid kan nog veel veranderen. Het overgrote deel van de ”dagelijkse”

interactie zal ingenomen worden door het beheer van het toegangsbeleid.

3.1 Vereisten

De vereisten die gesteld worden aan de beleidstaal vloeien voort uit de vereisten die gesteld

werden aan de toegangsbeheercomponent en het beleid ervan in hoofdstuk 2.

Generiek

”Generiek toegangsbeheer voor OSGi-gebaseerde software” is het doel, de beleidstaal moet dus

een generieke toegangsbeheerbeleidstaal zijn. Gelukkig zijn de meeste toegangsbeheerbeleids-

talen niet applicatie gebonden. Het moet ook een toegangsbeheerbeleidstaal zijn, beleidstalen

zoals EPAL [1] en P3P [10] die privacy policy languages en geen echte toegangsbeheertalen (Eng.

access control languages) zijn, komen niet in aanmerking als taal.

Flexibel

Hoe flexibeler de taal, hoe flexibeler het beleid kan zijn. En de mogelijkheid om een zeer flexibel

beleid te voeren is natuurlijk een groot pluspunt.

De flexibiliteit van een beleidstaal hangt af van:

3.1 Vereisten 19

• expressiviteit: Wat er allemaal uitgedrukt kan worden met de taalelementen, bijvoorbeeld

de mogelijkheid om een externe functie op te roepen, variabelen te kunnen gebruiken, enz.

• uitbreidbaarheid: De mogelijkheid om de taal uit te breiden en nieuwe taalelementen te

creeren.

Bruikbaar

De bruikbaarheid van een beleidstaal kan van verschillende dingen afhangen. Met een procedu-

rale taal zal het zeer moeilijk zijn om een beleid te definieren. Een taal die zo ontworpen is dat

de constructies eenvoudig door de computer geevalueerd kunnen worden, moet aan leesbaarheid

inboeten en zal bijgevolg slecht leesbaar zijn voor een mens. Zo een taal zal praktisch niet

bruikbaar zijn om een complex beleid mee te voeren tenzij er bijvoorbeeld een hulpapplicatie

voor bestaat waarmee het beleid bewerkt kan worden.

Enkele van de factoren waarvan de bruikbaarheid van een taal afhangt, zijn: de leesbaar-

heid, het bestaan van hulpapplicaties, het bestaan en de complexiteit van de implementaties,

declaratief of proceduraal karakter van de taal.

3.1.1 Criteria

De onderstaande criteria worden gehanteerd bij de vergelijking van de toegangsbeheerbeleidsta-

len, ze werden samengesteld uit de criteria van voorgaande vergelijkende studies zoals [30, 33,

20, 35] en de case study beschreven in [29].

In [30] werd getracht formele criteria te bepalen om de beredeneerbaarheid (Eng. reasonabili-

ty) van toegangsbeheerbeleidstalen te evalueren, deze eigenschappen zijn vooral belangrijk voor

het automatisch redeneren over een taal (bijvoorbeeld via applicaties die de juistheid van een be-

leid moeten verifieren of bewijzen) en voor de logische correctheid van een taal (een niet-correcte,

bijvoorbeeld een niet-monotone, taal kan ongewilde toegang verlenen).

Flexibiliteit

• variabelen: Variabelen laten toe om op een eenvoudige wijze relaties tussen objecten uit

te drukken. De expressiviteit van een taal wordt zo vergroot. Voorbeeld: een client is

geldig indien hij een abonnement heeft en het gevraagde object deel uitmaakt van dat

abonnement:

3.1 Vereisten 20

validClient(Client,Resource)

<- hasSubscription(Client,Subscription), includes(Subscription,Resource)

• combinaties van regels, condities (via disjunctie, conjunctie, negatie, xor, enz.): De mo-

gelijkheden om regels of condities te combineren laat toe om complexe uitdrukkingen op

te bouwen en voorwaarden te stellen die niet (of zeer moeilijk) op te stellen zouden zijn

zonder combinaties.

• externe functies: De mogelijkheid om externe functies uit te voeren of externe attributen

op te vragen laten toe om meer beslissingsinformatie in het beleid te verwerken en dus een

flexibeler beleid te voeren.

• accounting: Accounting en meer bepaald, de mogelijkheid om de toegangsgeschiedenis of

huidige status van een object te gebruiken bij de beleidsbeslissing voegt een extra dimensie

toe aan een beleid.

• uitbreidbaar: De uitbreidbaarheid is een zeer belangrijk criterium, het laat toe om het be-

leidssysteem aan te passen aan de omgeving waarin het moet werken. En is ook belangrijk

om de genericiteit van het toegangsbeheersysteem te garanderen. systeem

• conflictresolutie: Wat gebeurt er indien verschillende delen van het beleid of verschillende

regels toepasbaar zijn en hun beslissingen conflicterend zijn? Welke mechanismen zijn

voorhanden om dit op te lossen? Een verzameling aan conflictresolutiemechanismen laat

meer flexibiliteit toe dan enkel de mogelijkheid om prioriteiten in te stellen. Het automa-

tisch ontdekken van conflictresoluties laat toe om ze allemaal op te lossen op de gewenste

wijze.

Bruikbaarheid

• regels: Een beleid uitdrukken in declaratieve regels leunt dicht aan bij de manier waarop

mensen denken, het voelt intuıtief aan. Declaratieve regels nemen traditioneel een ”als

voorwaarde dan gevolg”-vorm aan.

• leesbaarheid/complexiteit: De leesbaarheid van de beleidstaal en de complexiteit van het

bijhorende raamwerk kunnen een doorslaggevende factor zijn of de taal bruikbaar of on-

bruikbaar is.

3.2 Toegangsbeheerbeleidstalen 21

• implementatie: Sommige toegangsbeheertalen hebben (nog) geen implementaties of er

bestaat enkel een prototype van of zijn niet vrij toegankelijk.

• hulpapplicaties: Het voorhanden zijn van applicaties waarmee een beleid kan bewerkt

worden (Eng. policy editor), kan het configureren, beheren en onderhouden van een beleid

stukken eenvoudiger maken.

• gestandaardiseerd: Enkele voordelen die een gestandaardiseerde taal kan hebben ten op-

zichte van een niet-gestandaardiseerde zijn: betere toegankelijkheid, wijdverspreidheid,

compatibiliteit, beschikbaarheid van hulpapplicaties gemaakt voor dezelfde standaard, ge-

teste en goedgekeurde kwaliteit (dit laatste punt is wel niet altijd waar, cfr. WEP, de

vroegere Wi-Fi beveiligingsstandaard).

Beredeneerbaarheid

• totale taal: Een taal is totaal indien ze altijd tot een beslissing kan komen.

• monotoon: Een taal is monotoon indien het geven van additionele credentials of verdere

informatie kan enkel leiden tot het krijgen additionele privileges. Het weerhouden van

informatie of credentials kan dan niet lijden tot additionele privileges.

3.2 Toegangsbeheerbeleidstalen

Rei [13], Ponder [11], KAoS [3], XACML [4] en Protune [14] zijn de kandidaten waaruit de keuze

moet vallen.

Voorbeeldbeleid

Het onderstaande voorbeeld[35] van een beleid wordt gebruikt ter illustratie van de beleidstalen:

Geef toegang tot de bestanden indien de gebruiker in de groep van

werknemers zit die geauthoriseerd zijn om deze toegang te krijgen.

3.2.1 Rei

Rei [27, 28, 35] is een declaratieve OWL1-gebaseerde beleidstaal die toelaat om een beleid als

beperkingen over toegelaten en verplichte acties op objecten van de omgeving te specificeren. Rei1Web Ontology Language: een semantische markup taal om ontologien te publiceren en te delen op het

wereldwijd web, gebaseerd op RDF [12] en ontwikkeld door W3C [8]


steunt op een applicatie-onafhankelijke ontologie2 om de concepten recht, verbod, verplichting

(Eng. obligation), vrijstelling (Eng. dispensation) en beleidsregels te representeren. De taal is

uitbreidbaar door het specificeren van additionele domeinafhankelijke ontologien.

Beleidsconflicten worden opgelost door het specificeren van meta-policies, die toelaten om

prioriteiten en voorrangsrelaties toe te kennen aan (deel)beleiden. Rei biedt de mogelijkheid om

variabelen te gebruiken bij het specificeren van een beleid, een eigenschap die de expressiviteit

van de taal ten goede komt. Verschillende condities kunnen gecombineerd worden via conjunctie,

disjunctie en negatie.

Rei ontbreekt ondersteuning voor het uitvoeren van externe functies en mogelijkheden tot

accounting.

Beleidsrepresentatie

Figuur 3.1 toont de representatie in Rei van het hierboven gedefinieerde illustratiebeleid. De

leesbaarheid van de, op RDF gebaseerde, taal laat te wensen over en is niet praktisch indien een

groter, ingewikkelder beleid dient gespecificeerd te worden. Hulpapplicaties bestaan nog niet,

er wordt wel aan een GUI gewerkt3 maar de status van het project is onbekend.

3.2.2 Ponder

Ponder[25, 35] is een declaratieve, object georienteerde taal, ontworpen om management en be-

veiligingsbeleiden te specificeren voor gedistribueerde systemen. De taal laat toe om toelatingen,

verplichtingen, informatiefilters, verbodsbepalingen en delegatiebepalingen uit te drukken. Zoals

op figuur 3.2 te zien is, is het mogelijk met Ponder regels te beschrijven, die de toegang tot een

object beperken, op een eenvoudige en declaratieve wijze.

Ponder ondersteunt geen variabelen, accounting of externe functies. Conflictresoluties wor-

den automatisch ontdekt door de meegeleverde hulpapplicatie en moeten dan opgelost worden

door prioriteiten toe te kennen. Ponder is een uitbreidbare taal maar ze is niet gebaseerd op een

logische taal en is bijgevolg niet totaal of monotoon.

De implementatie en hulpapplicatie om beleiden te bewerken zijn recentelijk onttrokken aan

publieke toegang en alle ondersteuning opgezegd, wat Ponder een stuk minder aantrekkelijk2Een ontologie is een datamodel dat een domein representeert en gebruikt wordt om over de objecten in dat

domein en hun onderlinge relaties te redeneren.3http://ebiquity.umbc.edu/project/html/id/50/IDE-for-Rei-Policy-Language


<constraint:SimpleConstraint rdf:ID="IsAuthorizedEmployee"

constraint:subject="#RequesterVar"

constraint:predicate="&example;memberOf"

constraint:object="&example;AuthorizedEmployee"/>

<constraint:SimpleConstraint rdf:ID="IsFilesServer"

constraint:subject="#FilesServerVar"

constraint:predicate="&example;memberOf"

constraint:object="&example;FilesServer"/>

<constraint:And rdf:ID="AreAuthorizedEmployeeAndFilesServer"

constraint:first="#IsAuthorizedEmployee"

constraint:second="#IsFilesServer"/>

<deontic:Permission rdf:ID="FilesServerPermission">

<deontic:actor rdf:resource="#RequesterVar"/>

<deontic:action rdf:resource="&example;access"/>

<deontic:constraint

rdf:resource="# AreAuthorizedEmployeeAndFilesServer"/>

</deontic:Permission>

<policy:Policy rdf:ID="AccessAuthPolicy1">

<policy:grants rdf:resource="#FileServerPermission"/>

</policy:Policy>

Figuur 3.1: Rei voorbeeldbeleid


maakt om te gebruiken als toegangsbeheertaal voor technologie van de toekomst, wat OSGi

toch is.

type auth+ FileAccess {subject Employee, target CompanyFiles}

{

action read, write;

When

IsAuthorizedEmployee(TRUE);

}

Figuur 3.2: Ponder voorbeeldbeleid

3.2.3 KAoS

KAoS [3, 22, 26, 35] is een collectie van diensten en hulpapplicaties die de specificatie, het beheer,

de conflictresolutie en de handhaving van een beleid toelaten. KAoS bevat dus zowel een PDP,

een applicatie om het beleid te beheren (KPAT genaamd) als ook PEP’s die de handhaving ver-

zorgen. Een KAoS-beleid wordt in DAML (DARPA Agent Markup Language) gerepresenteerd

als een ontologie, hierin kunnen toelatingen, verbodsbepalingen en verplichtingen voorkomen.

Conflictresolutie gebeurt door het toekennen van een prioriteit aan een beleid na automatische

detectie van alle conflicten.

Het KAoS raamwerk is generiek en platform onafhankelijk, het bevat grafische applicaties om

het beleid te monitoren, visualiseren en dynamisch te veranderen. Het KAoS raamwerk verzorgt

buiten toegangsbeheer ook domeindiensten (Eng. domain services), die de mogelijkheid biedt om

groepen van agenten4, mensen, bronnen en andere entiteiten te structureren in agent domeinen

en subdomeinen om zo de samenwerking tussen de agenten en externe beleidsadministratie te

bevorderen. Het raamwerk werd ontworpen met robustheid en een groot aanpassingsvermogen

in gedachten en ondersteunt buiten centrale evaluatie ook gedistribueerde evaluatie met een

democratisch of tirannie model.4Agenten zijn autoname computerprogramma’s die de belangen van de gebruiker behartigen.



DAML is een declaratieve, uitbreidbare taal gebaseerd op OWL (en bijgevolg RDF) net als

Rei. DAML omvat geen ondersteuning ter uitvoering van externe functies. Dankzij KPAT, de

administratieapplicatie van KAoS (die alle OWL volledig verbergt voor de gebruiker), blijkt

KAoS wel goed bruikbaar, in tegenstelling tot Rei (waarvan de taal vergelijkbare eigenschappen

heeft). KAoS bevat geen mogelijkheid om variabelen te gebruiken bij het definieren van een

beleid, noch biedt het ondersteuning voor de uitvoering van externe functies.

KAoS heeft als enige in de vergelijking (experimentele [22]) ondersteuning om de toegangs-

geschiedenis of huidige status te gebruiken als beslissingsconditie.

3.2.4 XACML

XACML [32, 33] (eXtensible Access Control Markup Language) is een XML-gebaseerde

toegangsbeheer- en privacybeleidstaal en omvat ook een standaard formaat om een verzoek en

antwoord over een dergelijk beleid uit te drukken.

XACML werd origineel in februari 2003 als standaard geratificeerd door OASIS en de hui-

dige versie, XACML 2.0, werd in maart 2005 ook als OASIS [5] Open Standard goedgekeurd.

XACML is de eerste en voorlopig enige gestandaardiseerde toegangsbeheerbeleidstaal. Deze

standaardisering betekent dat XACML de uitvoerige, publieke beproevingen (die vooraf gaan

aan een standaardisering) met glans heeft doorstaan en de steun heeft van grote spelers op

de informatietechnolgiemarkt (zoals IBM, Sun Microsystems, Oracle Corporation en Computer

Associates).

XACML is een regelgebaseerde beleidstaal, die niet gebaseerd is op een logische taal. Het is

geen totale taal, het resultaat van een beslissing kan Indeterminate (onbeslist) zijn. De taal om-

vat ondersteuning voor data types, functies, combinatielogica, het uitvoeren van externe functies

en is uitbreidbaar, wat toelaat om zeker ingewikkelde (of simpele) regels te definieren. Conflictre-

solutie en het combineren van een (sub)beleid met een ander kan volgens de volgende standaard

algoritmen: deny-overrides5, permit-overrides6, first-applicable7 en only-one-applicable8. De5deny-overrides: Indien om het even welke toepasbare regel tot deny evalueert, zal het resultaat van de

combinatie van alle regels ook deny zijn.6permit-overrides: Idem als deny-overrides maar met permit in plaats van deny.7first-applicable: De regels worden in de volgorde waarin ze in het beleid staan geevalueerd en het resultaat

van de combinatie zal de evaluatie van de eerste, toepasbare regel zijn.8only-one-applicable: Indien meer dan 1 regel toepasbaar is, zal het resultaat onbepaald zijn, anders zal het

de evaluatie van die ene toepasbare regel zijn.


<owl:Class rdf:ID="FileAuthAction">

<owl:intersectionOf rdf:parseType="owl:collection">

<owl:Class rdf:about="&action;AccessAction"/>

<owl:Restriction>

<owl:onProperty rdf:resource="&action;#performedBy"/>

<owl:toClass

rdf:resource="&domains;MembersOfAuthorizedEmployee"/>

</owl:Restriction>

<owl:Restriction>

<owl:onProperty rdf:resource="&action;#performedOn"/>

<owl:toClass

rdf:resource="&domains;MembersOfFilesServer"/>

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

<policy:PosAuthorizationPolicy rdf:ID="AccessAuthPolicy1">

<policy:controls rdf:ID="AccessAuthAction"/>

<policy:hasSiteOfEnforcement rdf:resource="#FileStorageSite"/>

<policy:hasPriority>1</policy:hasPriority>

</policy:PosAuthorizationPolicy>

Figuur 3.3: KAoS voorbeeldbeleid


evaluatie gebeurt steeds centraal in XACML maar het beleid kan gedistribueerd zijn, XACML

omvat ondersteuning voor de abstractie van de locatie van de verschillende beleidsonderdelen

waardoor het beleid evengoed uiteengezaaid over verschillende locaties en soorten informatie-

systemen kan zijn als dat het zou bestaan uit slechts 1 lokaal beleidsbestand.

XACML heeft standaard geen ondersteuning voor het gebruik van accountinginformatie in

de beleidsbeslissing. Het feit dat XACML niet monotoon is, is een tekortkoming afkomstig van

het feit dat XACML niet op een logische taal gebaseerd is. XACML bevat slechts beperkte

ondersteuning van variabelen, het definieren van variabelen gebeurt impliciet via de Target

condities die beperkingen opleggen aan de subjecten of resources op wie de regel toepasbaar is.

Er bestaan verschillende implementaties van het XACML raamwerk waaronder een Java im-

plementatie ontwikkeld door Sun Microsystems [15], er werd nog geen versie met ondersteuning

voor XACML versie 2.0 vrijgegeven maar er is wel een CVS-versie beschikbaar met volledige

ondersteuning voor XACML 2.0 beleidsraamwerk, het 2.0 verzoek/antwoord raamwerk is nog

volop in ontwikkeling 9.


De representatie van een beleid onder XACML gebeurt via de klassen afgebeeld in figuur 3.4.

• Rule: Regels zijn de elementaire eenheden van een XACML-beleid, ze bestaan uit een doel,

conditie en effect. Het effect kan Permit, Deny, Indeterminate of Not Applicable zijn. Een

regel is toepasbaar op een toegangsverzoek indien het doel van het verzoek overeenkomt

met het doel van de regel en het verzoek aan de condities van de regel voldoet.

• Policy: Representeert een beleid, bestaat uit regels, een combinatiealgoritme en (optioneel)

een verzameling van verplichtingen.

• PolicySet: Abstractie van een gedistribueerd en/of gecombineerd beleid. Omvat een ver-

zameling van Policy- of PolicySet-objecten en een algoritme om ze te combineren. Kan

ook verplichtingen bevatten.

De manuele administratie van een beleid onder XACML is intuıtief en leesbaar door de mo-

gelijkheid om regels te definieren en het gebruik van XML maar blijft toch moeilijk voor een

complex beleid. Gelukkig bestaat er reeds een applicatie om een XACML-beleid te bewerken,9Sun’s XACML Implementation project update, door Seth Proctor:

http://sourceforge.net/mailarchive/forum.php?thread id=9723554&forum id=33773


Figuur 3.4: Klassediagram van de XACML taalelementen

de UMU XACML editor10, een andere nuttige applicatie is Margrave, ontworpen voor beleids-

verificatie en de analyse van veranderingen in een beleid. Doordat XACML een standaard is,

worden er in de toekomst nog administratieapplicaties verwacht.

3.2.5 Protune

Protune (PROvisional TrUst NEgotiation)[24, 33, 23] is een recent door de REWERSE Working

Group I2 11 gedefinieerde beleids- en metataal. De taal biedt de mogelijkheid om een toegangsbe-10Ontwikkeld aan de universiteit van Murcia, Spanje en vrij verkrijgbaar op http://xacml.dif.um.es/11REWERSE (REasoning on the WEb with Rules and SEmantics) is een Europees onderzoeksproject met als

doel de positie van Europa op het gebied van (semantische) redeneertalen voor websystemen en applicaties te


<?xml version="1.0" encoding="UTF-8"?>

<Policy xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:cd:04"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:policy:schema:cd:04

http://docs.oasis-open.org/xacml/access_control-xacml-2.0-policy-schema-cd:04.xsd"

PolicyId="urn:oasis:names:tc:example:SimplePolicy"

RuleCombiningAlgId="identifier:rule-combining-algorithm:deny-overrides">

<Description>XACML Example Policy</Description>

<Target/>

<Rule RuleId="urn:oasis:names:tc:xacml:2.0:example:SimpleRule" Effect="Permit">

<Description>Permit the access to the files if the user is in the

group of employees authorized for this access.</Description>

<Target>

<Resources><Resource>

<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">

fileserver.example.com

</AttributeValue>

<ResourceAttributeDesignator

AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:baselocation"

DataType="http://www.w3.org/2001/XMLSchema#string" />

</ResourceMatch>

</Resource></Resources>

</Target>

<Condition>

<Subjects><Subject>

<SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">

fileservergroup

</AttributeValue>

<SubjectAttributeDesignator

AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:role"

DataType="http://www.w3.org/2001/XMLSchema#string" />

</SubjectMatch>

</Subject></Subjects>

</Condition>

</Rule>

</Policy>

Figuur 3.5: XACML voorbeeldbeleid

3.3 Vergelijking 30

heerbeleid, privacybeleid, reputatie-gebaseerd beleid, tijdelijk beleid (Eng. provisional policy)

en bedrijfsregels te specificeren. Protune biedt een uitbreidbare, declaratieve metataal aan,

gebouwd op de logische taal PeerTrust [9]. Protune omvat ook de unieke eigenschap om te

negotieren over verzoeken en beleidsbepalingen, een stap vooruit op het gebeid van semantische

redenering voor websystemen maar nutteloos in functie van toegangsbeheer voor een OSGi-

systeem.

Protune is een zeer veelzijdige taal: declaratief, uitbreidbaar, monotoon, kan variabelen

gebruiken, kan externe functies uitvoeren, ondersteunt het gebruik van regels, goede leesbaarheid

door het gebruik van een metataal (zie figuur 3.6. De taal bevat nog veel meer functionaliteit

die de noden voor het beoogde toegangsbeheersysteem overstijgen (zoals de mogelijkheid tot

negotatie). De enige functionaliteit die ontbreekt is de mogelijkheid beleidsbeslissingen te nemen

op basis van accountinginformatie.

Spijtig genoeg zijn er nog geen implementaties van Protune voorhanden, de taal werd pas in

februari 2005 gespecificeerd [24] en de ontwikkeling van een implementatie van het raamwerk in

nog volop bezig [33].

accessGranted(Employee, Files) <-

authorizedUser(Employee),

isOnFileserver(Files).

Figuur 3.6: Protune voorbeeldbeleid

3.3 Vergelijking

In tabel 3.1 worden de verschillen en gelijkenissen tussen de 5 kandidaten duidelijk.

verstevigen. Werkgroep I2 houdt zich specifiek bezig met beleidsspecificatie, -compositie en -conformiteit.

URL: http://www.rewerse.net12Via prioriteiten.13Via automatische detectie bij het ontwerp van het beleid.14Via standaard algoritmen, zie 3.2.4.15con = conjunctie, dis = disjunctie, neg = negatie16Conjunctie, disjunctie, eerste toepasbare, enige toepasbare en uitbreidbaar (extra operatoren kunnen zelf

gedefinieerd worden).17Conjunctie, disjunctie, negatie en uitbreidbaar.18Zonder ondersteuning en niet meer in ontwikkeling.

3.3 Vergelijking 31

Rei Ponder KAoS XACML Protune

variabelen ja nee nee impliciet ja

combinaties12 con/dis/neg con/dis/neg nee ja13 ja14

externe functies nee nee nee ja ja

accounting nee nee ja nee nee

uitbreidbaar ja ja ja ja ja

conflictresolutie ja15 automatisch16 auto.16 ja17 niet nodig

regels ja ja ja ja ja

leesbaar OWL metataal OWL XML metataal

implementatie ja ja18 ja ja nee

hulpapplicaties nee ja ja ja nee

gestandaardiseerd nee nee nee ja nee

totaal ja nee ja nee ja

monotoon ja nee ja nee ja

Tabel 3.1: Vergelijking van de beleidstalen

Ponder en Protune vallen af als kandidaat wegens het gebrek aan een ondersteunde imple-

mentatie.

Rei en KAoS gebruiken beiden OWL als basis voor hun taal maar ze verschillen toch op

enkele punten: Rei ondersteunt variabelen en combinaties terwijl KAoS conflictresolutie au-

tomatisch kan ontdekken, accountingondersteuning heeft en een beter bruikbaar is dankzij de

administratie- en hulpapplicaties.

XACML bevat alle functionaliteit die Rei bevat19 en meer, zoals betere conflictresolutie, gro-

tere expressiviteit (door de mogelijkheid om zelf operatoren definieren en om externe functies uit

te voeren), betere bruikbaarheid (XML regels zijn leesbaarder dan logische functies geschreven

in OWL en er bestaan hulpapplicaties voor XACML maar voor Rei niet).

De finalisten zijn dus XACML en KAoS. Beide raamwerken zijn goed bruikbaar, ze zijn

uitbreidbaar en hebben goede conflictresolutiemechanismen.

KAoS heeft zeker een voet voor op het vlak van beleidsadministratieapplicaties. KPAT wordt

standaard geleverd bij het KAoS raamwerk en is niet zomaar een beleidseditor: KPAT verbergt19Maar XACML bevat wel slechts impliciete ondersteuning voor variabelen, terwijl Rei ze volledig ondersteunt.

3.4 Besluit 32

de complexiteit van de OWL taal volledig, bevat beleidstemplates die uitgebreid kunnen worden,

laat toe om de PEP’s te volgen en om ontologien te creeren. De enige editor die nu voor handen

is voor XACML, is niet meer dan een editor. Maar door het feit dat XACML een standaard is

en nog in volle ontwikkeling is (versie 3.0 is onderweg), zal de beleidsadministratiesituatie van

XACML in de toekomst waarschijnlijk verbeteren.

De totaliteit en monotoniciteit van KAoS volgen uit het feit dat KAoS gebaseerd is op een

logische taal, dit in tegenstelling tot XACML. XACML is niet totaal en niet monotoon en is van

nul ontworpen. Als gevolg hiervan is de beredeneerbaarheid van XACML minder dan deze van

KAoS maar is de structuur van XACML wel duidelijker en meer toegangsbeheergericht.

Een (klein) voordeel van KAoS ten opzichte van XACML is dat het standaard ondersteuning

bevat voor het gebruik van accountinginformatie in de beleidsbeslissing. Het accountingprobleem

van XACML kan mogelijk bij de implementatie van het toegangsbeheersysteem opgelost worden

(door zelf een accountingsysteem in te bouwen).

XACML heeft een voet voor op KAoS op het vlak van expressiviteit dankzij de ondersteu-

ning voor variabelen, de uitbreidbare combinaties van condities en de mogelijkheid om externe

functies uit te voeren.

Op het vlak van conflictresolutie zijn ze aan elkaar gewaagd, KAoS biedt automatisch ont-

dekking aan maar XACML biedt voldoende standaard algoritmen aan en laat toe om nieuwe te

definieren. Geen van beide is mechanismen is duidelijk beter.

3.4 Besluit

De keuze van de toegangsbeheerbeleidstaal valt uiteindelijk op XACML. De betere flexibiliteit

en het feit dat XACML een actieve en open standaard waren hierbij van groot belang.

TOEGANGSBEHEERCOMPONENT 33

Hoofdstuk 4

Toegangsbeheercomponent

Nu de beleidstaal gekozen is, moet de toegangsbeheercomponent ontworpen worden met als

basis het XACML raamwerk, meer bepaald de XACML implementatie van Sun [15].

In dit hoofdstuk worden eerst de architectuurkeuzes besproken in sectie 4.1, hier wordt nog

zo min mogelijk gesproken over implementatiedetails en elementen van Sun’s XACML imple-

mentatie. Hierna wordt de basis van beleidsbeheer via XACML toegelicht in 4.2. Sectie 4.3

behandelt de implementatie van de bundels die in de eerste sectie werden besproken.

4.1 Architectuur

De structuur voor de toegangsbeheercomponent (zie figuur 4.1) is afgeleid van het toegangsbe-

heerraamwerk beschreven in [16] en is een verfijning van het raamwerk afgebeeld in figuur 2.2.

De basiselementen PEP en PDP worden behouden en er komen 4 nieuwe elementen bij, namelijk

een PAP (Policy Administration Point), PIP (Policy Information Point), PAuthP (Policy Au-

thentication Point) en de ACService (Access Control Service) dat voornamelijk een delegerende

functie heeft.

• PEP: Dwingt de beleidsbeslissing af op methodeniveau in de bundels.

• PDP: Maakt de beleidsbeslissingen op basis van de aanvraag ontvangen van een PEP, het

huidige beleid afkomstig van het PAP en de informatie verkregen van het PIP.

• PAP: Verantwoordelijk voor de (logische1) opslag van het beleid, het doorgeven van het

beleid aan het PDP en de administratie van het beleid.1Indien het beleid gedistribueerd is of niet lokaal opgeslagen wordt.

4.1 Architectuur 34

• PIP: Beantwoordt de informatievragen van het PDP, houdt accountinginformatie bij en kan

externe functies uitvoeren. De informatie (ook wel attributen genoemd) kunnen afkomstig

zijn van het subject (bv. functie of locatie), het doelobject (Eng. resource) of de omgeving

(Eng. environment).

• PAuthP: Onderzoekt de credentials van het subject, zoekt op welke authenticatie het

subject moet doorstaan en voert de authenticatie uit.

Figuur 4.1: Structuur van en dataflow in het toegangsbeheerraamwerk

4.1 Architectuur 35

Een toegangsverzoek kan op 2 wijzen afgewezen worden. De eerste is door het normale

verloop te volgen en een negatief antwoord (stap 10) te krijgen afkomstig van een beleidsregel

die de toegang verbiedt. Indien de authenticatie echter reeds faalt, zal onmiddellijk van stap

5 naar stap 10 overgegaan worden en zal een negatief antwoord teruggegeven worden aan het

PEP.

Het raamwerk is op OSGi vlak logisch opgedeeld in 4 bundels:

• PEP en de originele dienst

• PAP

• PAuthP

• ACService, PDP en PIP

De delegerende ACService, het PDP en het PIP vormen de basis van het raamwerk. Het PIP

onderbrengen in een aparte bundel is ook perfect mogelijk maar niet noodzakelijk. Indien nieuwe

bronnen van informatie/attributen moeten toegevoegd worden aan het PIP, volstaat het om de

gepaste XACML interfaces uit te breiden en de modules aan het PIP toe te voegen. Het is niet

de bedoeling om een nieuwe PIP implementatie te ontwerpen om nieuwe bronnen van informatie

eraan toe te voegen. Het PIP kan dus gerust tesamen met het PDP ondergebracht worden in

de ACService bundel.

De authenticatie en de beleidsadministratie kunnen daarentegen onafhankelijk van de rest

gebeuren en zijn dus aparte modules, indien gewenst kunnen ze vervangen worden door andere

implementaties zonder veranderingen aan de ACService, het PDP of het PIP te moeten doen.

4.1.1 Authenticatie

Sun’s XACML raamwerk bevat geen ondersteuning voor authenticatie, het PAuthP moet dus

volledig van nul opgebouwd worden. Om het wiel niet opnieuw uit te vinden, wordt er gekeken

naar de bestaande, uitbreidbare authenticatiemechanismen met een Java implementatie. De

keuze is gevallen op JAAS23, de Java implementatie van het PAM4 authenticatie en authorisatie

mechanisme. Het is een beproefd, dynamisch en uitbreidbaar systeem en het maakt deel uit van

de Sun’s standaard Java JDK.2http://java.sun.com/products/jaas/3Een eenvoudige tutorial over authenticatie met JAAS is te vinden op:

http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/tutorials/GeneralAcnOnly.html4http://en.wikipedia.org/wiki/Pluggable Authentication Modules

4.1 Architectuur 36

Identificatie

Voor de identificatie van een oproepende bundel kan gebruik gemaakt worden van de Java

klasse Principal5 en voor het bijhouden van zijn credentials bestaat de klasse Subject6. Om

een bundel uniek te identificeren kan gebruik gemaakt worden van de symbolische naam van

de bundel. Het OSGi systeem dwingt af dat deze uniek is in een OSGi omgeving. Indien

wordt getracht een bundel met dezelfde symbolische naam als een, in het OSGi systeem reeds

geınstalleerde, bundel te laden, zal dit laden falen. In XACML hebben de subjecten en objecten

allemaal OSGi bundels, elk subject heeft een unieke subject-id nodig en elk object eveneens een

object-id, voor deze identifiers wordt gebruikt gemaakt van hun symbolisch namen.

4.1.2 Authorisatie

De authorisatiebeslissing wordt gemaakt door het PDP op basis van de aanvraag, het beleid

en de informatie aangebracht door het PIP. Het PDP kan zelf geen attributen van het subject

uit de aanvraag halen of externe informatie genereren, Dat is de taak van het PIP. De concrete

informatie die het PIP verschaft, bestaat uit:

• De subjectattributen, deze bestaan uit de unieke identifier van het subject en attributen

van het subject en van zijn credentials (zoals bijvoorbeeld de gebruikersnaam, het loca-

tieveld van een X.509 certificaat, de locatie/url vanwaar de oproepende bundel afkomstig

is).

• De unieke identifier van het object (in XACML resource-id genoemd), i.e. zijn symbolische

naam.

• De naam van de betreffende methode en de bruikbare argumenten waarmee de methode

opgeroepen werd. Argumententypes die gerepresenteerd kunnen worden in XACML en

waarvoor vergelijkingsfuncties bestaan in XACML, kunnen zodanig gebruikt worden bij

de authorisatiebeslissing.

• Omgevingsattributen: Standaard bevat XACML maar ondersteuning voor 2 omgevings-

attributen. Er bestaat een attribuut die de huidige tijd representeert en een functie die

toegang tot de inhoud van een XML bestand via een XPath7 pad implementeert, zodat5java.security.Principal6javax.security.auth.Subject7http://www.w3.org/TR/xpath

4.1 Architectuur 37

delen van een XML document als attribuut gebruikt kunnen worden. Nieuwe omgevings-

attributen zoals bijvoorbeeld de tijdzone, de architectuur of het besturingssysteem van het

onderliggende systeem, de processorbelasting, e.d. kunnen beschikbaar gesteld worden op

verschillende wijzen. Bijvoorbeeld door de AttributeFinderModule interface uit te brei-

den, dit is de meest flexibele manier. Ofwel door ze manueel toevoegen aan de verzameling

van attributen (zie 4.3.2: accounting), of door een nieuwe XACML functie te definieren

(zie 4.3.2: UseOSGiFunction).

Accounting

XACML ondersteunt standaard geen accounting maar dit wordt gemakkelijk opgelost door in het

PIP de toegangsaanvragen te loggen en bijvoorbeeld de laatste toegangsaanvraag en de laatste

succesvolle toegang tot een object en tot een actie op een object om te zetten in attributen en

beschikbaar te stellen voor het PDP als omgevingsattributen.

4.1.3 Beleidsadministratie

Zoals de software ontwikkelingsprincipes, modulariteit en de scheiding van belangen, het voor-

schrijven , bevindt het PAP zich in een afzonderlijke bundel, net zoals de authenticatiebundel.

En bezit het een interface waar het PDP toegang tot heeft, zodat de implementatie van het PAP

onafhankelijk kan gebeuren van het PDP.

Opslag van het beleid

De eenvoudigste (en voor het ogenblik enige) vorm van persistentie die door XACML onder-

steund wordt, is de opslag van het beleid in XML tekstbestanden. Andere vormen van persis-

tentie zoals de opslag in een database zijn natuurlijk mogelijk indien ze zelf geımplementeerd

worden, dit behoort echter niet tot de doelstellingen. Een XACML beleid opgeslagen in XML

tekstbestanden is eenvoudig te beheren en aangezien geen bijzondere voorwaarden gesteld zijn

aan de performantie of flexibiliteit van de opslagvorm, volstaat de opslag in XML tekstbestan-

den.

Push of pull?

De keuze tussen een push- of pull-mechanisme om het beleid van PAP naar PDP over te brengen,

is er een waarbij de beslissende factoren performantie, eenvoud en gebruiksgemak zijn. De

4.1 Architectuur 38

interface van het PAP zal beide mechanismen toelaten, ze moet methodes om luisteraars te

registeren bevatten zodat een beleid gepusht kan worden. En de interface moet ook een methode

om het beleid rechtstreeks op te vragen definieren. Een push-mechanisme is iets moeilijker te

implementeren maar efficienter. Bij een pull-methode wordt veel tijd verloren met het ophalen

van het beleid bij elke beleidsbeslissing (het beleid moet opgehaald worden zelfs al is het niet

verandert).

4.1.4 Beleidsbeslissing afdwingen

Zoals in 2.5.2 reeds vermeld is, heeft elke methode van de serviceinterface van een bundel een

PEP nodig, om op methodeniveau toegangsbeheer af te dwingen. Methodeoproepen gebeuren

rechtstreeks op de serviceobjecten zonder tussenkomst van het OSGi Framework, de enige wijze

om de PEP’s te implementeren is dus ofwel om een decorator bundel rond de betreffende bundel

te bouwen, die de toegangsbeheerfunctionaliteit toevoegt. Of de methodeoproepen zouden op

een bepaalde manier moeten kunnen onderschept worden op het niveau van de Java virtuele

machine. Aan de Java VM sleutelen is echter geen optie, het systeem moet op een standaard

Java VM kunnen draaien.

Wat te doen bij een toegangsweigering?

Wat dient teruggegeven te worden aan de oproepende bundel indien de toegang geweigerd werd?

Null, een runtime exception8, een checked exception9?

De null-waarde kan een betekenis hebben voor de oproeper. Als de oproeper een null-waarde

terugkrijgt en die een betekenis heeft, wordt eigenlijk een foutieve waarde teruggegeven. Indien

de toegang verboden is, mag de oproeper geen waarde terugkrijgen. De null optie wordt dus

geschrapt.

Een checked exception moet opgevangen worden of in de throws gedeclareerd worden. Een

oproeper die ontworpen is om met een bundel te communiceren zonder toegangsbeheer en zal

incompatibel worden indien toegangsbeheer aan de bundel toegevoegd wordt. Want de betref-

fende checked exception zal niet opgevangen worden en Java zal dit controleren en beslissen dat

de oproeper geen gebruik meer kan maken van de bundel.8Een exceptie die kan geworpen worden tijdens normale uitvoering, hoeft niet gedeclareerd en opgevangen te

worden. In Java zijn RuntimeException, Error en hun subklassen runtime exceptions.9Een gecontroleerde exceptie, een exceptie die gedeclareerd en opgevangen moet worden, kan niet onverwachts

ontstaan.

4.2 Introductie tot XACML 39

Een runtime exceptie zal geen foutieve waarde teruggeven en stelt geen voorwaarden aan

de oproeper. Indien de exceptie echter niet opgevangen wordt, zal de oproeper zijn uitvoering

beeindigen. Er is geen enkele wijze om de oproeper te verplichten de runtime excepties op te

vangen. Maar zoals in de OSGi Service Tutorial [7] geschreven staat,

Always expect RuntimeException when calling a service.

wordt dus aangeraden om bij het oproepen van een dienst altijd een RuntimeException te

verwachten. Indien de oproeper deze richtlijnen volgt, zal zijn uitvoering niet beeindigen, zal hij

geen foutieve waarde terugkrijgen en zal de oproeper code bevatten om de runtime excepties op

te vangen.

Bij een toegangsweigering zal dus een runtime exceptie opgeworpen worden door de toe-

gangsbeheercomponent.

4.2 Introductie tot XACML

De structuur van een XACML beleid, werd afgebeeld in figuur 3.4. Een XACML beleid begint

bij een Policy of PolicySet. Een PolicySet is een container en kan andere Policies, PolicySets of

referenties naar niet-lokale beleiden. Een Policy representeert een toegangsbeheerbeleid, uitge-

drukt via een verzameling Rules. Elk XACML beleidsbestand bevat precies 1 Policy of PolicySet

root XML tag.

Omdat een Policy of PolicySet meerdere Rules of Policies kunnen bevatten, die elke tot een

andere beleidsbeslissing kunnen evalueren, moet XACML deze beslissingen kunnen combineren.

In 3.2.4 werden de verschillende algoritmen reeds besproken, men kan ook steeds een eigen

algoritme bouwen.

Targets

Een XACML PDP moet in het volledige beleid, de beleiden en beleidsregels vinden die toe-

pasbaar zijn voor de aanvraag. XACML maakt hiervoor gebruik van Targets. Een Target is

eigenlijk een verzameling van vereenvoudigde condities voor het Subject, de Resource en de

Action die waaraan moet voldaan worden opdat een PolicySet, Policy of Rule toepasbaar is op

de aanvraag. Bovenop de mogelijkheid om toepasbaarheid te controleren, kunnen Targets ook

gebruikt worden om beleiden te indexeren, wat zeer handig kan zijn om structuur te brengen

in een grote verzameling beleiden. Een Policy kan bijvoorbeeld in zijn Target definieren dat hij

4.2 Introductie tot XACML 40

enkel toepasselijk is op 1 Subject, hierdoor zullen alle Rules die onder deze Policy vallen, enkel

onder beschouwing genomen worden bij aanvragen betreffende dat Subject. Een Target kan ook

leeg zijn, dit betekent dat hij van toepassing is op alle aanvragen.

Eens een toepasselijke Policy gevonden is voor een aanvraag, worden zijn Rules geevalueerd.

Een Policy bevat een willekeurig hoeveelheid Rules. Deze Rules bevatten de kernlogica van een

XACML beleid. De basis van een Rule is een Condition, dit is een booleaanse functie. Als

de evaluatie van de Condition een waar-waarde voortbrengt, dan wordt het Effect (Permit of

Deny) van de Rule teruggegeven. Bij een negatieve evaluatie, is de Condition niet toepasbaar

op de aanvraag en wordt NotApplicable teruggegeven. De evaluatie van een Condition kan

ook resulteren in een fout, dan wordt Indeterminate teruggegeven. Conditions kunnen zeer

complex zijn, ze kunnen opgebouwd worden uit een willekeurig aantal in elkaar geneste functies

en attributen, zoals ze maar samenkomen tot een booleaanse functie.

Attributes, Attribute Values en Functions

XACML handelt vooral in attributen. Een Attribute is een benoemde waarde van een gekend

datatype. Elk Attribute heeft dus een naam (identifier), waarde en type. Attributes zijn ka-

rakteristieken van het Subject, de Resource, de Action of de omgeving (Environment) van de

toegangsaanvraag.

Een Policy zet een Attribute in een waarde om via twee mechanismen: de AttributeDesigna-

tor en de AttributeSelector. Een AttributeDesignator laat toe om een Attribute te specificeren

aan de hand van zijn naam en zijn type. Het PDP zal dan de waarde in de aanvraag opzoeken en

indien ze daar niet gevonden werd de andere attribuutmodules aflopen. AttributeSelectors laten

een beleid toe om attribuutwaarden via een XPath expressie op te zoeken. Beide mechanismen

kunnen meerdere waarden teruggeven, hiervoor biedt XACML een speciaal attribuuttype Bag

aan. Om een Bag met 1 waarde in om te zetten in die waarde moet gebruik gemaakt worden

van een ”-one-and-only” functie.

Eens een Bag van Attributes of een Atribute is opgehaald, moeten de waarden vergeleken

worden met de verwachte waarden om een toegangsbeslissing te maken. Dit gebeurt via een

krachtig systeem van functies (Functions). Functies kunnen een willekeurige combinatie van

attribuutwaarden en types behandelen en kan gelijk welk type attribuut dat ondersteund wordt

door het systeem teruggeven. Functies kunnen als invoer de uitvoer van een andere functie

hebben en kunnen zo willekeurig complexe hierarchien vormen. Nieuwe functies kunnen ook

4.3 Implementatie 41

gedefinieerd worden om een grotere expressiviteit te bekomen.

Request en Response

XACML definieert niet enkel een standaard formaat voor een beleid maar ook een standaard for-

maat om aanvragen (Requests) en antwoorden (Responses) op te bouwen. Een aanvraag bestaat

uit attributen van vier categorieen: Subject, Resource, Action en Environment (deze laatste is

optioneel). Een antwoord bevat 1 of mogelijk meerdere10 resultaten (Results). In een resultaat

zit een beslissing (Decision: Permit, Deny, NotApplicable of Indeterminate), status informatie

(waarom een evaluatie faalde bijvoorbeeld) en optioneel ook verplichtingen (Obligations).

Een Request en Response vormen de standaard wijze van interactie met een PDP via de

evaluate methode.

4.3 Implementatie

Sectie 4.1 behandelde de voornaamste architectuurkeuzes. Hier worden de implementatiedetails

besproken. Alle figuren waar naar gerefereerd wordt, staan tussen de tekst door.

Figuur 4.2 toont de package structuur van de toegangsbeheercomponent. De basispackage

is gacos, dit staat voor Generic Access Control for OSGi-based Software. Onder deze package

bevinden zich de acservice, pauthp, pap en acadder packages, deze representeren respectievelijk

de toegangsbeheerbundel (met daarin het PDP en PIP), de bundel die de authenticatiefuncti-

onaliteit verzorgt, de beleidsadministratiebundel en een Java programma, ACAdder genaamd

dat een bundel JAR-bestand als input neemt en deze altereert voor gebruik met de toegangsbe-

heerdienst.

De 3 OSGi bundels zijn zo gestructureerd dat alle interfaces en klassen die geexporteerd

worden door OSGi11, zich in de root van de overeenkomstige package bevinden en alle imple-

mentaties zich in de subpackage impl bevinden, geheel volgens de programmeerrichtlijnen voor

OSGi bundels.10Enkel bij hierarchische resources die hier niet gebruikt zullen worden.11Alle klassen en interfaces die geregistreerd worden als een OSGi dienst of die door andere bundels geımporteerd

worden, moeten geexporteerd worden door de betreffende bundel.


Figuur 4.2: package structuur van de implementatie

Structuur en dataflow

Met enkele sequentiediagrammen wordt de interne werking en dataflow van het toegangbeheer-

systeem toegelicht. Bij de illustratie wordt gebruik gemaakt van een fictieve bundel met als

serviceinterface TestService en serviceobject TestServiceImpl. Indien een interface of implemen-

tatie veranderd wordt ten dienste van het toegangsbeheersysteem wordt dit duidelijk gemaakt

door AC voor zijn naam te plaatsen.

Figuur 4.3 is een sequentiediagram van een succesvol toegangsverzoek waarbij de authen-

ticatie gebeurt via een gebruikersnaam en wachtwoord. Het illustreert de werking van het

toegangsbeheersysteem. De gelijkenissen met figuur 4.1 zijn duidelijk te zien, elke stap in figuur

4.1 is terug te vinden in het sequentiediagram. Er zijn ook enkele stappen bijgekomen.

1. De oproeper, een bundel in hetzelfde OSGi systeem, voert een methode uit van de be-

schermde bundel ACTestService en geeft hierbij zijn credentials (een gebruikersnaam en

wachtwoord) mee.

2. De beschermde bundel contacteert het toegangsbeheersysteem ACService om te vragen

of de toegangsaanvraag ingewilligd mag worden. De credentials werden ondertussen toe-

gevoegd aan het subject (van het type javax.security.auth.Subject) en ook het object, de

actie en de argumenten worden meegegeven in de aanvraag.

3. De ACService heeft een louter delegerende functie en geeft de aanvraag door aan de PD-

PImpl.


4. De implementatie van het policy decision point moet nu eerst het subject authenticeren

en contacteert hiervoor de PAuthP bundel, het subject en object worden meegegeven.

5. Het PAuthP laadt de loginmodule(s) die in zijn configuratie overeenkomt met het gegeven

object en voert de login() methode uit om het subject te authenticeren.

6. Bij een succesvolle authenticatie krijgt het PAuthP een waar-waarde terug, bij een niet-

succesvolle authenticatie zal een runtime exceptie geworpen worden die helemaal teruggaat

naar de oproepende bundel.

7. Het PAuthP meldt het succes van de authenticatie aan de PDPImpl.

8. De toegangsaanvraag wordt gelogd.

9. De subject-, objecten omgevingsattributen worden opgevraagd aan het PIP.

10. Het PIP beantwoordt de vragen van de PDPImpl.

11. De implementatie van het PDP stelt nu een verzoek op dat behandeld kan worden door de

com.sun.xacml.PDP klasse en voert de evaluate methode uit met als argument het opge-

stelde verzoek. Vanaf hier zal elke referentie naar een object van de com.sun.xacml.PDP

klasse als PDP geschreven worden, om het verschil met het PDP (Policy Decision Point)

element van een toegangsbeheerraamwerk aan te geven.

12. Het PDP object zoekt naar toepasbare beleiden bij de PAPPolicyModule die alle huidige

beleiden bevat.

13. De gevonden beleiden worden teruggegeven.

14. Aan de hand van de regels gedefinieerd in de toepasbare beleiden, de attributen ontvangen

van het PIP en de aanvraag maakt de PDP instantie een beslissing en geeft zijn antwoord

terug aan de PDPImpl klasse.

15. Indien een positief antwoord ontvangen werd, wordt het succes van de aanvraag gelogd.

16. Bij een positief antwoord zal de PDPImpl een waar-waarde teruggeven aan de ACService

als antwoord op de vraag gesteld in stap 3. Bij een negatief antwoord wordt een runtime

exceptie geworpen.

17. De ACService laat aan de beveiligde bundel weten dat hij de toegang mag verlenen tot de

beveiligde dienst aan de oproeper.


18. De beveiligde bundel bevat een instantie van de dienst waar hij de toegang tot beheert en

voert de gevraagde methode uit.

19. Het antwoord volgt.

20. En wordt teruggegeven aan de oproeper.

Figuur 4.3: Sequentie diagram van een succesvol toegangsverzoek met gebruikersnaam en wacht-

woord authenticatie

Het is ook mogelijk om geen extra credentials voor authenticatie toe te voegen waardoor de

serviceinterface identiek blijft. Figuur 4.4 toont een dergelijk scenario waarbij de authenticatie

gebeurt door het controleren van de locatie van de bundel.

Veel verschil is er niet met het vorige sequentiediagram. Ze veschillen op slects enkele plaat-

sen:

• In stap 1 wordt nu een methode van de originele serviceinterface opgeroepen, maar de

implementatie die deze oproep behandelt is wel de nieuwe ACTestServiceImpl (die dus de

originele serviceinterface implementeert). De argumenten blijven ook dezelfde.


Figuur 4.4: Sequentie diagram van een succesvol toegangsverzoek zonder toegevoegde credentials

• Het subject in stap 2 bevat nu een BundleCredential waar de oproepende bundel in

verwerkt zit en geen gebruikersnaam of wachtwoord meer.

• In stap 5 wordt nu de BundleLocationLoginModule geladen die via de OSGi conditie

BundleLocationCondition, de oproepende bundel op zijn locatie authenticeert.

4.3.1 PAuthP

Figuur 4.5 toont de volledige package structuur van het PAuthP. Het belangrijkste element is

de interface PAuthP, die de authenticatiedienst bevat. Op de figuur is duidelijk zichtbaar dat

de PDP implementatie PDPImpl eenvoudig geassocieerd is met de PAuthP. De reden hiervoor is

dat de authenticatie die voorafgaat aan de beleidsbeslissing, gebeurt vanuit de klasse PDPImpl

en die dus een referentie naar de authenticatie interface vereist.

De bundelidentificatie klasse en de credentialklassen zitten niet in de gacos.pauthp, deze

klassen zitten in de gacos.acservice.auth.credential package en hebben een aparte bundel gekre-

gen om 2 redenen. Ten eerste kan de ACService bundel zo opstarten zonder dat er een PAuthP


bundel moet opgestart zijn en een 2de reden is dat ze niet in de ACService bundel kunnen

ondergebracht worden omdat er dan een cyclisch buildpath zou ontstaan tussen de ACService

bundel en de PAuthP bundel wat niet toegelaten is. Beide bundels hebben de klassen wel nodig,

ACService om er de subjectattributen uit te halen en PAuthP om er de credentials uit te halen.

Authenticatie interface

De authenticatie interface gacos.pauthp.PAuthP bevat slechts 1 methode met 2 argumenten, het

te authenticeren subject en het object waartoe men toegang wil.

public boolean authenticate(Subject subject, String resource);

Het subject bevat de identificatie en de credentials van de oproeper en de resource is gelijk

aan de symbolische naam van de bundel waartoe toegang gevraagd wordt. Deze laatste is nodig

om te bepalen welk authenticatie mechanisme moet gebruikt worden. In JAAS zijn (net zoals

in elke PAM implementatie) de authenticatie methodes configureerbaar per dienst. Een JAAS

login configuratiebestand12 ziet er als volgt uit:

gacos.test.certservice.CertService{

gacos.acservice.auth.loginmodule.X509KeyStoreLoginModule sufficient;

gacos.acservice.auth.loginmodule.PlainPasswordFileLoginModule sufficient;

};

gacos.test.testservice.TestService{

gacos.acservice.auth.loginmodule.BundleLocationLoginModule required;

};

gacos.pauthp.impl klassen

De PAuthPImpl is het hart van de authenticatie bundel, ze implementeert de authenticatie inter-

face, laadt de configuratie, maakt de juiste logincontext aan en voert de effectieve authenticatie

uit door de login() methode van LoginContext aan te roepen.12Het formaat en de betekenis van de vlaggen staan beschreven in de javax.security.auth.login.Configuration

javadocs.

URL: http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/login/Configuration.html


Figuur 4.5: structuur van de Policy Authentication Point package


De klasse PAMConfigFile extendeert de abstracte klasse Configuration, ze kan een JAAS

configuratietekstbestand inlezen en parsen.

De OSGiLoginContext is een extensie van de LoginContext klasse die zorgt voor het dyna-

misch laden van PAM loginmodules en het aanroepen van hun methodes. Het was nodig om

deze te creeren omdat de standaard Java klasse LoginContext niet kan omspringen met het

laden van de loginmodules vanuit een OSGi bundel, ze gebruikt een classloader met speciale

permissies die niet werkt in een OSGi systeem.

PAM werkt met een callback-mechanisme om credentials aan een gebruiker te vragen, de

BundleCallbackHandler is een delegerende klasse die de ontvangen callbacks analyseert en

doorverwijst naar de juiste handler.

gacos.pauthp.loginmodule klassen

PAM is een raamwerk waarin de loginmodules at runtime geladen worden, zo kunnen modu-

les dynamisch toegevoegd en verwijderd worden. In de JAAS implementatie zijn de modules

implementaties van de LoginModule13 interface. De inhoud van de gacos.pauthp.loginmodule

package is te zien op figuur 4.6.

Sun levert standaard enkele loginmodules in de package com.sun.security.auth.module14

waaronder een LdapLoginModule, JndiLoginModule en Krb5LoginModule om respectievelijk

te authenticeren via het LDAP-, JNDI- of Kerberos-protocol. Deze 3 modules maken standaard

enkel gebruik van de NameCallback en PasswordCallback, deze callbacks verzorgen de invoer

van een gebruikersnaam en een wachtwoord voor alle loginmodules, beide callbacks kunnen

behandeld worden door de UserPassCredential. Het authenticatiemechanisme kan dus ge-

bruik maken van deze authenticatieprotocollen en van gelijk welk ander protocol waarvoor een

LoginModule bestaat en dat authenticatie via een gebruikersnaam en wachtwoord ondersteunt.

Zoals in 2.1.1 vermeld werd, zijn in OSGi Release 4 twee methodes voor authenticatie inge-

bouwd. De BundleLocationCondition test op de locatie van een bundel, dit is de URL vanwaar

de bundel gedownload werd15. Met de BundleSignerCondition is het mogelijk om de DN reeks13javax.security.auth.spi14http://java.sun.com/javase/6/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/package-

summary.html15De locatie van een bundel kan worden opgevraagd in een OSGi systeem maar zit niet bevat in het JAR-

bestand van de bundel. Bij installatie moet de locatie van de bundel opgegeven worden en OSGi haalt dan zelf

de bundel op. Er bestaat dus wel mogelijkheid om deze locatie te spoofen via klassieke aanvallen, waarbij het

OSGi systeem denkt dat het aan het downloaden is van het juist systeem maar eigenlijk communiceert met de


Figuur 4.6: loginmodule package

(Eng. Distinguished Name chain) van de ondertekenaar van een bundel te verifieren ten opzichte

van de DN reeks gedefinieerd in de conditie.

De geımplementeerde loginmodules zijn:

• Omdat JAAS een foutmelding geeft indien er geen loginmodule gedefinieerd is voor een

dienst, is het handig een loginmodule te hebben die geen authenticatie uitvoert en altijd

positief antwoord. Dat is exact wat de NoAuthenticationLoginModule doet.

• De BundleLocationLoginModule maakt gebruik van de OSGi klasse

BundleLocationCondition om te authenticeren op de locatie waarvan een bundel afkom-

stig is.

• De BundleSignerLoginModule is een implementatie van authenticatie via de

BundleSignerCondition. Deze module maakt gebruik van de conditional permission ad-

aanvaller. Bijvoorbeeld door de DNS server waarvan het OSGi systeem gebruik maakt, aan te vallen en DNS

entries te altereren of door een ARP spoof aanval te doen op het systeem waarvan de bundel gedownload zal

worden en vervolgens het IP-adres van dat systeem over te nemen.


min van OSGi, dit is een functie die in release 4 werd toegevoegd en optioneel is. Om

aan de OSGi specificatie te voldoen, moet deze niet geımplementeerd zijn. Indien het toe-

gangsbeheersysteem ontdekt dat deze module niet ondersteund is door het OSGi systeem

waar het op draait zal deze module genegeerd worden.

• De PasswordLoginModule en PlainPasswordFileLoginModule zijn respectievelijk een ab-

stracte klasse die de meeste methodes voor authenticatie via een gebruikersnaam en wacht-

woord implementeert en een extensie daarvan die de gebruikersnamen en wachtwoorden

uit een tekstbestand haalt. De PlainPasswordFileLoginModule is niet verantwoordelijk

voor het geencrypteerd opslaan van de wachtwoorden. Indien dit gewenst is, moet de

encryptie gebeuren aan de client zijde onmiddellijk na het ingeven van het wachtwoord en

moeten de wachtwoorden ook geencrypteerd ingegeven worden in het tekstbestand.

• De mogelijkheid om een X.509 certificaat mee te kunnen geven als credential voor de au-

thenticatie was een van de vereisten voor het toegangsbeheersysteem, de

X509KeyStoreLoginModule maakt het mogelijk om een X.509 certificaat te verifieren ten

opzichte van het certificaat van een CA (Eng. Certificate Authority). Deze module contro-

leert of het X.509 certificaat dat meegegeven werd als credential effectief uitgegeven werd

door een bepaalde CA in een bepaalde keystore, i.e. of het X.509 certificaat ondertekend

is met de private sleutel van de CA.

4.3.2 ACService

Een overzicht van de inhoud van de ACService bundel is te vinden op figuur 4.7. Alle interfaces en

klassen die moeten geexporteerd worden bevinden zich wederom in de root van de gacos.acservice

package en hun implementaties in de subpackage impl.

Communicatie met andere bundels

De relatie tussen de implementatie van het Policy Decision Point (klasse PDPImpl) en PAuthP

bundel (interface PAuthP) is ook hier zichtbaar. De authenticate methode van de PAuthP

interface wordt rechtstreeks vanuit de PDPImpl klasse uitgevoerd.

De ACService bundel communiceert met het PAP via de PAPTrackerCustomizer en de

PAPPolicyModule. De PAPPolicyModule is een extensie van de abstracte PolicyFinderModule16

16com.sun.xacml.finder.PolicyFinderModule


Figuur 4.7: structuur van de Access Control Service package


klasse uit Sun’s XACML 2.0 implementatie. De naam van de PolicyFinderModule klasse

spreekt voor zich, extensies van deze klasse zijn modules die beleiden moeten vinden, ze re-

presenteren de bronnen waarvan de beleiden komen. In dit geval is de bron het PAP, de

PAPPolicyModule is de verbinding tussen het PAP en het PDP, als het PDP een beleid op-

vraagt via 1 van de findPolicy methoden, geeft de PAPPolicyModule het huidige beleid door.

Dit gebeurt niet door het expliciet te gaan opvragen maar wel door een push-mechanisme.

De PAPPolicyModule implementeert namelijk de PolicyChangeListener interface en via de

PAPTrackerCustomizer wordt de PAP bundel getrackt17, indien de PAP bundel beschikbaar is,

registreert de PAPTrackerCustomizer de PAPPolicyModule als PolicyChangeListener bij het

PAP. Zo worden veranderingen in het beleid onmiddellijk vanuit de PAPFileAdminImpl naar de

PAPPolicyModule gepusht.

Ook de PAuthP bundel wordt getrackt, via de PAuthPTrackerCustomizer klasse, die net zo-

als de PAPTrackerCustomizer een implementatie van de OSGi interface ServiceTrackerCustomizer18.

De OSGi programmeer richtlijnen raden aan om alle services te tracken.

ACService interface

De ACService interface is de dienst die bij het OSGi systeem geregistreerd wordt. Ze bevat

slechts 1 methode met als signatuur:

boolean requestAccess(Subject subject, String object, String action, List args)

throws AccessDeniedException;

Het subject is van de javax.security.auth.Subject klasse en bevat de identiteit van de oproeper,

i.e. een BundlePrincipal) en zijn credentials. Het object of resource is de symbolische naam

van de bundel waarvan de oproeper een methode wil uitvoeren, de action is de naam van deze

methode en in de args lijst zitten de argumenten waarmee de methode opgeroepen wordt die

kunnen omgezet worden in XACML attributen, namelijk instanties van de klassen String, Date,

boolean, integer of double. De AccessDeniedException is de exceptie die teruggezonden

wordt naar de oproeper indien de toegang geweigerd werd, het is een extensie van de Java

RuntimeException klasse, in 4.1.4 werd uitvoerig besproken waarom dit een runtime exceptie

moet zijn.17Tracken gebeurt via een ServiceTrackerCustomizer implementatie zoals de PAPTrackerCustomizer, een der-

gelijke tracker luistert naar de veranderingen in de status van een bundel (in dit geval de PAP bundel) en kan

reageren op een gebeurtenis zoals het beschikbaar worden, verwijderen van of het veranderen van een bundel.18org.osgi.util.tracker.ServiceTrackerCustomizer


PDP

De PDPImpl klasse is het hart van het toegangsbeheersysteem, in deze klasse wordt een PDP19

object aangemaakt dat de effectieve beleidsbeslissingen neemt op basis van de verzameling at-

tributen verkregen van het PIP en het beleid verkregen van het PAP. Een toegangsaanvraag

komt binnen via de requestAccess methode, dan wordt eerst het PAuthP gecontacteerd om

het subject te authenticeren, de toegangsaanvraag wordt hier gelogd door het PIP. Vervolgens

wordt een RequestCtx object aangemaakt, dit is de Sun XACML klasse die een toegangsaan-

vraag representeert die rechtstreeks door een PDP object kan behandeld worden. De aanvraag

wordt behandeld via de evaluate methode van PDP. Waarna het antwoord wordt geanalyseerd

en ofwel wordt een AccessDeniedException opgeworpen ofwel wordt de boolean waarde true

teruggegeven om aan te geven dat het toegangsverzoek goedgekeurd is. Het resultaat20 van de

evaluatie kan zijn:

• DECISION_DENY: In dit geval bestaat geen twijfel, een AccessDeniedException moet op-

geworpen worden.

• DECISION_PERMIT: Ook in dit geval bestaat geen twijfel, het toegangsverzoek wordt inge-

willigd.

• DECISION_INDETERMINATE: Dit betekent dat het PDP geen beslissing heeft kunnen bepa-

len, het beleid bevat misschien conflicterende regels zonder dat een regelcombineeralgo-

ritme werd ingesteld. In dit geval mag geen toegang gegeven worden, het zou een niet-

gewenste toegang kunnen zijn. Het is beter om enkele gewenste toegangen te weigeren en

zeker te zijn dat er geen ongewenste toegangen kunnen voorkomen.

• DECISION_NOT_APPLICABLE: Indien geen toepasbaar beleid gevonden wordt, wordt de toe-

gang goedgekeurd. Indien dit gedrag niet gewenst is, moet aan het beleid een default deny

regel toegevoegd worden.

PIP

Er wordt reeds een PIP geınstantieerd in de ACServiceImpl omdat hierin de nieuwe functies en

attributen, die eventueel gecreeerd werden, toegevoegd worden aan de PolicyFinder instantie.19com.sun.xacml.PDP20Het resultaat wordt gerepresenteerd door de com.sum.xacml.ctx.Result klasse.


Figuur 4.8: Policy Decision Point implementatie


Deze PolicyFinder instantie wordt samen met de PolicyChangeListener geregistreerd bij

de PAP bundel. Deze heeft de verbeterde PolicyFinder nodig om het XML beleidsbestand

correct te kunnen parsen, zonder de PolicyFinder kan het de XML representaties van de

nieuwe attributen en functies niet herkennen.

De PIP21 interface toont duidelijk welke functionaliteit het aanbiedt aan het PDP. De

getAttributeFinder methode geeft een AttributeFinder22 object terug dat de mogelijkheid

biedt aan het PDP om attribuutwaarden te vinden die niet meegeleverd werden in de aanvraag.

De enige dergelijke attributen die gevonden kunnen worden zijn voor het ogenblik de huidige

datum en tijd (via de CurrentEnvModule23) en waarden gevonden in een XML bestand via een

XPath expressie ( via de SelectorModule24). Deze laatste maakt gebruik van de Xalan25 XPath

implementatie.

De getResourceFinder is een ongebruikte methode die enkel voor de volledigheid werd

toegevoegd, een ResourceFinder maakt het mogelijk om van hierarchische bronnen gebruik te

maken. Een XACML functie die hier geen nut heeft.

De 4 createXXXSet methodes halen de attributen uit een aanvraag en zetten ze om in een

formaat dat de PDP klasse kan verwerken. Ze maken het mogelijk om attributen te bouwen die

niet in de aanvraag bevat zitten maar wel subject/object/actie afhankelijk zijn, zoals bijvoor-

beeld de toegangsgeschiedenis van een object of actie.

De PIPAccounting interface bevat 2 eenvoudige maar zeer krachtige methodes. Elke aan-

vraag en succesvolle aanvraag wordt gelogd via de logAccessRequest methode inclusief alle

informatie die in de aanvraag bevat zit. En de getAttributes methode laat toe om de gelogde

informatie om te zetten attributen die bij de beleidsbeslissing kunnen gebruikt worden. Voor het

ogenblik is het aantal attributen beperkt, enkel de laatste toegang en succesvolle toegang van een

object en een actie zijn beschikbaar als attributen. En deze informatie wordt niet persistent ge-

maakt en gaat dus verloren indien de ACService bundel gestopt wordt. De PIPAccountingImpl

klasse kan uitgebreid worden om accounting informatie persistent te maken of bijvoorbeeld om

billing van gebruikers te implementeren (aan de hand van het aantal succesvolle toegangen), etc.

Ter illustratie van de uitbreidbaarheid van XACML en de mogelijkheid om externe func-

ties uit te voeren vanuit een XACML beleid, is er UseOSGiService ontworpen. Deze functie21gacos.acservice.PIP22com.sun.xacml.finder.AttributeFinder23com.sun.xacml.finder.impl.CurrentEnvModule24com.sun.xacml.finder.impl.SelectorModule25http://xalan.apache.org/


implementeert het contacteren van een OSGi bundel en het uitvoeren van een methode zonder

argumenten die een String teruggeeft. De naam van de bundel en de methode worden in het

XACML beleid ingesteld en het resultaat van de uitvoering kan dan ook gebruikt worden in

het beleid. Door de Function26 interface te implementeren in plaats van de abstracte klasse

FunctionBase te extenderen, kunnen krachtigere functies gedefinieerd worden met bijvoorbeeld

een variabel aantal argumenten, waardoor het mogelijk wordt om gelijk welke OSGi bundelme-

thode op te roepen met argumenten die in XACML representeerbaar zijn. Het gebruik en de

kracht van de UseOSGiService wordt in een testopstelling geıllustreerd.

Credentials

De package gacos.acservice.auth.credential zit zoals eerder vermeld in een afzonderlijke bundel,

een bundel die enkel klassen en interfaces exporteert en geen diensten aanbiedt. De structuur

van deze package is te zien op figuur 4.9.

De package bevat 3 interfaces, de Credential interface die specificeert dat een credential een

CallbackHandler moet kunnen teruggeven om zijn callbacks die overeenkomen met zijn cre-

dentialtype te kunnen afhandelen. De StringAttrInterface en StringArrayAttrInterface

zijn interfaces die methodes specificeren om 1 of meerdere (URI, waarde) tupels op te vragen,

de URI wordt gebruikt om een attribuut identifier van te maken om de overeenkomstige waarde

aan te wijzen.

Een BundlePrincipal representeert de identificatie van een OSGi oproepende bundel, het

subject. Het is een implementatie van de standaard Java Principal interface en kan hierdoor

aan een Subject toegevoegd worden. De BundlePrincipal implementeert ook de

StringAttrInterface waardoor er een attribuut kan opgevraagd worden, in dit geval is het de

door XACML gedefinieerde subject-id27 de waarde zal dan de symbolische naam van de oproeper

(i.e. het subject in XACML termen) bevatten.

Tenslotte bevat de package nog de klassen BundleCredential, UserPassCredential en

X509Credential. Deze klassen representeren (zoals de namen al laten vermoeden) de cre-

dentials die een subject kan bezitten. De UserPassCredential representeert een gebruikers-

naam en wachtwoord, de gebruikersnaam kan als attribuut gebruikt worden via de attribuut

id gacos:names:username-id, deze klasse bevat een interne klasse UserPassCallbackHandler

die de CallbackHandler interface implementeert. Het nut van deze klasse werd in 4.3.1 on-26com.sun.xacml.cond.Function27De volledige naam van het attribuut is urn:oasis:names:tc:xacml:1.0:subject:subject-id.


Figuur 4.9: credential package


der de titel gacos.pauthp.loginmodule klassen al besproken. De X509Credential klasse omvat

een X509Certificate28 object en laat door de StringArrayAttrInterface te implemente-

ren toe om alle velden29 van het X.509 certificaat als attributen te gebruiken. Deze klas-

se bevat geen callbackhandler, de authenticatie door de X509KeyStoreLoginModule gebeurt

aan de hand van het ingesloten X509Certificate. De BundleCredential omvat een OSGi

Bundle30 object, dat gebruikt wordt bij de authenticatie door de BundleLocationLoginModule

en BundleSignerLoginModule loginmodules. Deze klasse stelt ook 2 attributen beschikbaar,

namelijk de symbolische naam en de locatie van het Bundle object.

4.3.3 PAP

De PAP bundel is de enige bundel die 2 OSGi diensten registreert, er bestaat een interface naar

de PDP’s toe en 1 ontworpen om het beleid te administreren. De PAPpdp interface definieert

methodes om een push-mechanisme te implementeren, namelijk:

public void addPolicyChangeListener(PolicyChangeListener pcl, PolicyFinder pf);

public void removePolicyChangeListener(PolicyChangeListener pcl);

en hiermee kunnen luisteraars geregistreerd worden die de PolicyChangeListener interface im-

plementeren, indien het beleid veranderd is, wordt het beleid gepusht via de

policyChanged(PolicyCollection newPolicies) methode van de PolicyChangeListener in-

terface.

Via de public PolicyCollection getPolicy(); methode kan een PDP ook een pull-

mechanisme gebruiken.

Door PAPFileAdmin interface kunnen nieuwe XML bestanden toegevoegd worden aan of ver-

wijderd worden van de lijst van bestanden waarin het beleid zich bevindt of kan deze lijst volledig

vervangen worden. Ze bevat ook een reloadPolicies() methode om het beleid te herladen van

uit de XML bestanden. Om deze interface te gebruiken moet er echter nog een administratie-

client geschreven worden, voorlopig gebeurt alle administratie nog manueel. Meer hierover volgt

in het volgende hoofdstuk in verband met de configuratie van het toegangsbeheersysteem.

Zoals in figuur 4.10 te zien is, bestaan er 2 klassen (dit zijn ook de service objecten die bij

het OSGi systeem geregistreerd worden) die de 2 interfaces implementeren en alles delegeren28java.security.cert.X509Certificate29Zowel DN van de eigenaar en de uitgever als alle velden van die DN’s afzonderlijk.30org.osgi.framework.Bundle


Figuur 4.10: structuur van de Policy Administration Point package


naar de werkelijke implementatie, de klasse PAPImpl, deze bevat de volledige functionaliteit

van de PAP bundel. De luisteraars worden hier bijgehouden en hun policyChanged methodes

opgeroepen wanneer nodig. Bij het laden wordt gebruik gemaakt van de PolicyFinder om

nieuwe attributen en functies te herkennen zoals eerder vermeld en er wordt ook geverifieerd

of de XML bestanden voldoen aan de XACML specificatie gedefinieerd in het access control-

xacml-2.0-policy-schema-os.xsd31 schema.

4.3.4 PEP

De PEP’s kunnen niet op voorhand geprogrammeerd worden, ze moeten gebouwd worden rond

de bundels waarvoor toegangsbeheer gewenst is. Alhoewel dit manueel niet zoveel werk is, vergt

dit wel enige kennis van het toegangsbeheersysteem en ook toegang tot de broncode van de

bundel. Beide voorwaarden zijn in vele gevallen niet realistisch. Er moet dus gestreefd worden

naar een methode om een bundel met toegangsbeheer te creeren uit een willekeurige bundel in

JAR-formaat via zo min mogelijke interactie door de gebruiker en zonder nood aan voorkennis

over het toegangsbeheersysteem.

De package gacos.acadder bevat een Java programma ACAdder. Dit programma doet wat

hierboven vereist werd (met de nodige beperkingen).

Als input neemt het een JAR-bestand waarin enkel de binaire class-bestanden zitten waaruit

de bundel bestaat, geen bronbestanden. De argumenten bestaan uit het pad van bundel, een

classpath dat het OSGi Framework en andere bibliotheken die gebruikt worden in de Activator,

serviceinterface of serviceimplementatie van de bundel, bevat. De laatste twee argumenten zijn

de symbolische naam van de interface waaraan toegangsbeheer moet toegevoegd worden en de

symbolische naam van de implementatieklasse dat als serviceobject geregistreerd wordt.

Vervolgens wordt aan de gebruiker gevraagd of hij aan een methode uit de interface extra

credentials (gebruikersnaam en wachtwoord of een X.509 certificaat) wil toevoegen voor de au-

thenticatie. Indien de vraag negatief beantwoord wordt, blijft de serviceinterface onaangeroerd.

Indien positief geantwoord wordt, worden alle methodes afgelopen en telkens gevraagd welke

van de 2 credentials toegevoegd moeten worden. Het mag geen van de twee, slechts 1 of alle

twee zijn en het mag verschillen van methode tot methode. Vervolgens wordt een nieuwe ser-

viceinterface gecreeerd met als naam, de naam van de oude interface met de letters AC ervoor

geplaatst. De serviceinterface klasse wordt geladen via de Class.forName() methode en via31http://docs.oasis-open.org/xacml/2.0/access control-xacml-2.0-policy-schema-os.xsd


de Class.getMethods() worden de methodes in de serviceinterface opgevraagd. Hieruit wordt

een nieuw Java bronbestand gecreeerd dat alle zelfde methodes met eventuele extra argumenten

bevat en dezelfde excepties werpt.

Hierna wordt het manifest onder handen genomen, aan het Import-Package attribuut moeten

de gacos.acservice, gacos.acservice.auth.credential en javax.security.auth packages toegevoegd

worden.

De volgende 2 stappen zijn de 2 moeilijkste.

Eerst moet de activator-klasse veranderd worden om de nieuwe serviceinterface te registreren

met het nieuwe serviceobject (waarvan de implementatie hierna gegenereerd zal worden). Een

eerste methode zou om de huidige activator uit te breiden, super() aan te roepen, de registratie

van de oude service ongedaan te maken en de nieuwe service te registreren. Deze methode stelt

echter 2 zware voorwaarden, een registratie ongedaan maken kan enkel indien gebruik gemaakt

wordt van een ServiceFactory om de dienst registeren (wat niet de traditionele wijze is) en het

serviceobject mag enkel geınstantieerd worden met een constructor zonder argumenten want de

argumenten zijn niet gekend. Een andere methode is door de activator klasse te decompileren

en de regels waar het serviceobject wordt aangemaakt en de serviceinterface geregistreerd wordt

aan te passen door de letters AC te plaatsen voor de namen van het serviceobject (en eventueel

ook voor de naam van de serviceinterface indien er credentials werden toegevoegd). Het nieuwe

serviceobject wordt nu geınstantieerd met dezelfde argumenten als het vorige serviceobject en

geregistreerd onder de naam van de nieuwe serviceinterface.

De volgende stap bestaat uit het genereren van een nieuwe serviceimplementatie, die:

• de nieuwe serviceinterface implementeert,

• dezelfde constructors bevat als de vorige serviceimplementatie (deze worden via de

Class.getConstructors() methode opgezocht) en in elke constructor de overeenkomstige

constructor van de oude serviceimplementatie uitgevoerd wordt, de zo gecreeerde instantie

van de oude serviceimplementatie is identiek aan het oude serviceobject,

• in elke methode eerst een authorisatieverzoek opstelt met de nodige identificatie (via de

BundlePrincipal) en credentials. Er wordt altijd een BundleCredential toegevoegd.

De oproepende bundel wordt achterhaald door de stacktrace van de huidige uitvoering te

bestuderen en de gevonden naam te vergelijken met de inhoud van elke bundel in het sys-

teem32. De ACService bundel wordt nu gecontacteerd en de requestAccess() methode32Of deze methode de prestaties te zeer negatief beınvloed op grote systemen is niet geweten.


uitgevoerd. Indien de toegang geweigerd werd, wordt de ontvangen

AccessDeniedException (die niet gekend is door de oproeper) omgezet in een

SecurityException, een standaard Java runtime exceptie. Indien de toegang goedgekeurd

is, wordt overeenkomstige methode op de instantie van de oude serviceimplementatie uit-

gevoerd en het resultaat teruggegeven aan de oproeper.

Dit genereren gebeurt aan de hand van 3 templates, 1 voor de hoofding, 1 voor elke constructor

en 1 voor elke methode. In deze templates worden de gemarkeerde velden vervangen door de

gepaste namen.

De gegenereerde bronbestanden van de nieuwe activator, de nieuwe serviceimplementatie en

eventueel de nieuwe serviceinterface worden via de Runtime.getRuntime().exec() methode

gecompileerd (met het classpath dat als argument van ACAdder werd meegegeven). De inhoud

van de oude bundel wordt naar een nieuwe bundel gecopieerd en de nieuwe class bestanden

worden eraan toegevoegd.

Het grootste probleem met deze methode is dat ze enkel werkt indien de activator niet te

ingewikkeld is. De gebruikte decompiler is Jad33, biedt slechts ondersteuning voor JDK 1.3,

als de activator functies gebruikt die toegevoegd werden in Java 1.4 of 1.5 zal deze methode

hoogstwaarschijnlijk falen. Indien de activator echter eenvoudig gehouden wordt (op alle andere

klassen zijn geen restricties), zal deze methode betrouwbare resultaten afleveren.

4.3.5 Compatibiliteit

Het ontwikkelde toegangsbeheersysteem maakt veelvuldig gebruik van de klassen uit de

javax.security.* packages. Dit zijn packages toegevoegd werden aan de Sun Java JDK/JRE uit-

voeringsomgeving met het uitbrengen van de 1.4 versie. Ze zitten echter niet in de, door OSGi ge-

definieerde, speciale Java uitvoeringsomgevingen OSGi/Minimum-1.0 en CDC-1.0/Foundation-

1.034. De minimum vereiste die gesteld wordt aan de uitvoeringsomgeving is dus de beschik-

baarheid van een volledige JDK 1.4 (of beter).

Elke OSGi implementatie die versie 3 of 4 van de OSGi specificatie implementeert, voldoet

om (op de BundleSignerLoginModule na) de volledige functionaliteit van het toegangsbeheer-

systeem te gebruiken. De BundleSignerLoginModule maakt gebruik van de33http://www.kpdus.com/jad.html34Beschikbaar op http://osgi.org/osgi technology/download specs.asp?section=2


ConditionalPermissionAdmin35, dit is een (optionele36) interface die werd toegevoegd aan het

OSGi raamwerk bij de 4de versie. Om van de BundleSignerLoginModule loginmodule gebruik

te kunnen maken moet er dus een OSGi R4 implementatie met ConditionalPermissionAdmin

beschikbaar zijn.

35org.osgi.service.condpermadmin36Een implementatie moet deze interface niet implementeren om te voldoen aan de OSGi R4 specificatie.

EVALUATIE 64

Hoofdstuk 5

Evaluatie

Dit hoofdstuk behandelt het praktisch gebruik en de evaluatie van het ontworpen toegangsbe-

heersysteem. Te beginnen bij de configuratie in sectie 5.1, daarna worden enkele testopstellingen

waarin enkele van de mogelijkheden van het systeem worden toegelicht. Tenslotte worden de

flexibiliteit en het gebruiksgemak van het systeem geevalueerd, twee van de voornaamste eisen

die werden gesteld aan de beleidstaal.

De mappen test1 klaar en test2 klaar bevatten reeds geconfigureerde OSGi omgevingen waar-

in de nodige bundels en testopstellingen al in geladen zijn, zoals beschreven in de configuratie

en installatie secties.

5.1 Configuratie

5.1.1 Installatie

Bij de ontwikkeling en het testen van het toegangsbeheersysteem werd gebruik gemaakt van de

Windows XP SP2 en Mac OS X 10.4.7 besturingssystemen, Java 1.5.0 06 en de Knopflerfish 2,

OSGi R4 implementatie. Theoretisch gezien zou het systeem op elk platform dat een Java JDK

versie 1.4 of hoger en OSGi R3 of R4 implementatie bevat, moeten kunnen uitvoeren.

In deze sectie wordt de configuratie van het toegangsbeheersysteem op een Knopflerfish 2

OSGi implementatie toegelicht. Het systeem wordt klaargemaakt om de testopstellingen op te

kunnen uitvoeren. Alle nodige bestanden staan op de bij deze scriptie horende cd-rom.

Er wordt verondersteld dat het systeem al een Java JDK 1.4 of 1.5 uitvoeringsomgeving

bevat.

• De eerste stap is dan de installatie van de OSGi implementatie. Voer het zelf uitpakkende

5.1 Configuratie 65

JAR-bestand knopflerfish osgi 2.0.0.jar dat zich op de bijgevoegde cd-rom bevindt, uit.

Dit bestand bevat de volledige Knopflerfish 2 distributie (KF2)1. Volg de aanwijzingen op

het scherm. Het systeem kan in een willekeurige map geınstalleerd worden.

• De volgende stap is het toevoegen van de nodige packages aan de

org.osgi.framework.system.packages property2.

Vervang in het tekstbestand knopflerfish.org/osgi/props.xargs3 de lijn:

-Dorg.osgi.framework.system.packages=

door:

-Dorg.osgi.framework.system.packages= org.w3c.dom, org.osgi.service.log,

javax.security.auth, javax.security.auth.login, javax.security.auth.spi,

javax.security.auth.callback, javax.security.auth.login.AppConfigurationEntry,

sun.security.util, com.sun.security.auth.module, com.sun.security.auth.login,

org.osgi.service.condpermadmin

• De Knopflerfish 2 omgeving mag nu opgestart worden. Voer hiervoor het framework.jar

bestand uit dat zich bevindt in de map knopflerfish.org/osgi/ 3.

De KF desktop zou nu zichtbaar moeten zijn, zoals op figuur 5.1 te zien is.

• Vervolgens moeten enkele bibliotheken geınstalleerd worden. Namelijk een bibliotheek die

Sun’s XACML implementatie bevat, een bibliotheek die de credential klassen bevat en

een bibliotheek die de Xalan XPath implementatie bevat. Dit zijn de 3 JAR-bestanden

die zich in de libs map op de cd-rom bevinden, respectievelijk sunxacml2.0-1.0.0.jar,

gacos.auth.credential-1.0.0.jar en xalan xpath api-1.0.0.jar.

Deze kunnen geınstalleerd worden door ze naar de KF desktop te verslepen of via het File

→ Open bundle menuitem.

• De volgende stap bestaat uit de configuratiebestanden en het beleid van het toegangsbe-

heersysteem te kopieren naar de KF2 map.1Het kan ook gedownload worden van http://www.knopflerfish.org/releases/2.0.0/knopflerfish osgi 2.0.0.jar2Deze property bevat een lijst van packages die door de classloader geexporteerd worden en dus beschikbaar

zijn vanuit het OSGi systeem, standaard worden enkel java.* en org.osgi.framework geexporteerd.3Dit is het relatief pad ten opzichte van de map waarin KF2 werd geınstalleerd.

5.1 Configuratie 66

Figuur 5.1: De Knopflerfish 2 desktop.

Alle bestanden bevinden zich in de map conf op de cd-rom, kopieer de volledige inhoud van

deze map naar de map knopflerfish.org/osgi/ 3, dit is de map waarin zich het framework.jar

bestand bevindt.

• De OSGi omgeving is nu klaar om het toegangsbeheersysteem op te starten. Installeer de

onderstaande bundels (die zich in de bundles map op de bijgevoegde cd-rom bevinden) in

volgorde, op dezelfde wijze als de bibliotheken:

1. FilePAP-1.0.0.jar

2. JAASPAuthP-1.0.0.jar

3. ACService-1.0.0.jar

In de console van de KF2 desktop verschijnen nu verschillende boodschappen, de belang-

rijkste zijn:

<datum> <tijdstip> gacos.acservice.impl.ACServiceImpl log

INFO: PAuthP successfully tracked.

<datum> <tijdstip> gacos.acservice.impl.ACServiceImpl log

5.1 Configuratie 67

INFO: PAP successfully tracked, PolicyChangeListener registered.

Ze betekenen dat de ACService bundel succesvol contact heeft gemaakt met de authenti-

catiebundel PAuthP en de administratiebundel PAP.

• Het systeem is nu klaar om de toegang tot beveiligde bundels te beheren.

5.1.2 Configuratiebestanden

De namen van de configuratiebestanden zitten hard gecodeerd in de bundels. Waarvoor de

bestanden dienen en hoe ze gestructureerd moeten zijn, wordt nu uitgelegd.

policies.txt

In het policies.txt bestand staat op de eerste lijn de naam van een beleidscombineeralgoritme.

Deze naam moet een van volgende waarden zijn: none (om de beleiden niet te combineren),

denyoverrides, permitoverrides, onlyoneapplicable of firstapplicable4.

Alle volgende regels zijn de paden van de XML beleidsbestanden waaruit het volledige beleid

bestaat.

pam.txt

pam.txt bevat de authenticatie configuratie van het beleidssysteem. Het volgt de standaard

JAAS structuur. Elke dienst waartoe de toegang beheerd wordt, moet een entry hebben.

gacos.test.firstservice.FirstService{

gacos.pauthp.loginmodule.BundleLocationLoginModule sufficient;

gacos.pauthp.loginmodule.PlainPasswordFileLoginModule sufficient;

};

Zoals zichtbaar is op bovenstaand voorbeeld van een entry, bestaat ze uit de symbolische naam

van de originele serviceinterface die beschermd wordt (niet de naam met ”AC” voor indien

de interface veranderd is). En vervolgens de namen van de loginmodules die gebruikt moeten

doorlopen worden indien een oproepende bundel wil geauthenticeerd zijn om gebruik te kun-

nen maken van de betreffende dienst. Na de symbolische naam van een loginmodule, staat

een controlflag. Deze kan de waarden required, requisite, sufficient of optional aannemen.4Zie 3.2.4 voor meer informatie over deze combineeralgoritmen.

5.1 Configuratie 68

De betekenis van deze vlaggen zijn af te leiden uit hun namen, in de javadoc pagina van de

javax.security.auth.login.Configuration5 klasse staat in detail uitgelegd wat ze exact doen.

password.txt

De (gebruikersnaam, wachtwoord) tupels die gebruikt worden voor de authenticatie door de

PlainPasswordFileLoginModule loginmodule bevinden zich in het password.txt bestand. Elke

regel bevat een gebruikersnaam, een spatie en een (al dan niet geencrypteerd) wachtwoord.

bundlelocation.txt

Het bundlelocation.txt bestand bevat, zoals de naam al doet vermoeden, de configuratie van de

BundleLocationLoginModule loginmodule. Het tekstbestand heeft de volgende structuur: de

eerste regel is de symbolische naam van een oproepende bundel, de hierop volgende regels zijn

de locaties vanwaar een bundel met de eerdergenoemde symbolische naam afkomstig mag zijn.

Deze locatieregels zijn URL’s en mogen de wildcard ”*” bevatten. Een lege regel kondigt aan

dat de volgende regel een nieuwe symbolische naam is en de daaropvolgende regels terug locaties.

Indien een lege regel onmiddellijk volgt op een symbolische naam, betekent dit dat een bundel

met die naam niet geauthenticeerd zal worden, welke locatie hij ook heeft.

bundlesigner.txt

Het configuratiebestand van de BundleSignerLoginModule, het is op dezelfde wijze gestructu-

reerd als dat van de BundleLocationLoginModule loginmodule. De locatie URL’s zijn nu echter

vervangen door een DN of reeks van DN’s gescheiden met een ”;”. Deze mogen ook nu weer de

wildcard ”*” bevatten.

andere bestanden

• Het gacos.keystore bestand is het keystore bestand dat de certificate authority bevat, die

gebruikt wordt bij authenticatie door de X509KeyStoreLoginModule loginmodule. Het

gacos.keystore.readme.txt bestand bevat extra informatie over de naam en wachtwoord

van de CA.

• access control-xacml-2.0-policy-schema-os.xsd is het XACML XML schema dat door de

PolicyReader wordt gebruikt om de XACML elementen in een XML bestand te parsen.5http://java.sun.com/j2se/1.5.0/docs/api/index.html?javax/security/auth/login/Configuration.html

5.2 Testopstellingen 69

• client1.pem en badclient1.pem zijn 2 publieke certificaten die gebruikt kunnen worden om

de X.509 certificaat authenticatie te testen. client1.pem is ondertekende door de certificate

authority die in gacos.keystore zit en badclient1.pem door een andere, niet vertrouwde

certificate authority.

• De map conf/jarsigner bevat een ondertekende bundel die kan gebruikt worden om de

BundleSignerLoginModule te testen.

5.2 Testopstellingen

Bij de eerste testopstelling worden geen extra credentials toegevoegd, de serviceinterface zal

dezelfde blijven zodat de oproepende bundels niets moeten veranderen. Bij deze test zal onder

andere gebruik gemaakt worden van accounting en van de nieuwe UseOSGiService functie, die

externe informatie opvraagt.

De tweede testopstelling zal een gebruikersnaam, wachtwoord en certificaat toevoegen. Bij

deze test zal onder andere het gebruik van een argument, de gebruikersnaam en de velden van

het certificaat als attributen geıllustreerd worden.

Testopstelling 1

De bestanden van deze testopstelling bevinden zich in de test1 map van de cd-rom. In de src

map staan alle bronbestanden. ACAdder bevat een script ACAdder.bat dat geconfigureerd is

om toegangsbeheer toe te voegen aan de TestService1-1.0.0.jar bundel.

De TestService1 bundel definieert 4 servicemethodes:

public String toCaps(String str) throws Exception;

public void nothing(int number, String str, Date date, Object obj);

public Object getObject();

public String getString();

De TestService1User1-1.0.0.jar bundel voert deze 4 methoden achter elkaar uit en print de uitvoer

naar System.out. TestService1User2-1.0.0.jar voert de tweede methode niet uit (om zo een

verschil in de toegangsgeschiedenis te kunnen zien). De TestEmergencyMonitor-1.0.0.jar biedt

een serviceinterface aan met slechts 1 methode, String getEmergencyLevel(). Deze geeft om

beurt ”low”, ”medium” en ”high” terug.


Om te illustreren dat de serviceinterface van TestService1 niet zal veranderen door er toe-

gangsbeheer aan toe te voegen, worden de bundels eerst zonder toegangsbeheer opgestart. Sleep

(in volgorde) TestService1-1.0.0.jar, TestService1User1-1.0.0.jar en TestService1User2-1.0.0.jar

naar de KF2 desktop. Onderstaande log zal in de KF console verschijnen.

[stdout] currentdate : Sat Aug 19 19:56:51 CEST 2006

[stdout] object gotten

[stdout] This is an object.

[stdout] Sat Aug 19 19:56:53 CEST 2006

[stdout] USER1

[stdout] getString()



[stdout] USER2

[stdout] getString()

Dit is de normale uitvoer van de bundels zonder toegangsbeheer, verwijder nu de 3 bundels van

de KF2 desktop door ze te selecteren en met de eject knop te deınstalleren.

Nu zullen we toegangsbeheer toevoegen aan de TestService1 bundel. Kopieer eerst de

volledige map test1 naar plaats waar schrijven toegelaten is. Kopieer dan TestService1-1.0.0.jar

naar de ACAdder map en voer het ACAdder.bat script uit, druk op enter om de standaardkeuze

te nemen bij de vraag of er credentials moeten toegevoegd worden. Er is nu een nieuw JAR-

bestand gecreeerd, TestService1-1.0.0.jar.new.jar. (Deze stap kan ook worden overgeslaan door

de voorgemaakte TestService1-1.0.0.jar.new.jar bundel uit de map test1 te gebruiken.)

Sleep dit bestand naar de KF2 desktop, vervolgens de TestEmergencyMonitor-1.0.0.jar bun-

del en sleep tenslotte de 2 gebruikerbundels ook naar de KF2 desktop. Nu verschijnt heel wat

uitvoer in de console en in de logs van de bundels6. Onder andere:

[stdout] INFO PAuthPImpl.authenticate() on Subject <...>.TestService1User2 for <...>.TestService1

[stdout] INFO Bundle location authentication succeeded.

[stdout] INFO NoAuthenticationLoginModule authentication succeeded.

[stdout] INFO Authentication of gacos.test.testservice1.user2.TestService1User2 succeeded.

Dit is een log van de PAuthP bundel, ze toont welke loginmodules doorlopen worden en het

uiteindelijke succes of falen van de authenticatie.6De log van een bundel is beschikbaar door de bundel te selecteren en rechts het log paneel te selecteren.


Alle attributen die betrekking hebben op een toegangsverzoek, kun je zien in het <request>

XML element. Het antwoord van de PDP wordt afgedrukt als <response> XML element.



Toont de normale uitvoer van de bundels indien de toegangsaanvraag ingewilligd is. Indien ze

geweigerd werd, wordt [stdout] Access denied. uitgeprint.

Alle regels die van toepassing zijn op deze testopstelling 1 bevinden zich in het test1.xml

beleidsbestand. Elke regel bevat een beschrijving in het <Description> XML element.

• Regel 1 laat gebruiker 1 toe om van 8u30 tot 17u30 gebruik te maken van TestService1,

door een van de uren te veranderen zodat het huidig tijdstip buiten dit bereik valt, is het

mogelijk om gebruiker 1 alle toegang tot TestService1 te ontzeggen. Deze regel past een

booleaanse AND-functie toe om twee condities te combineren.

• Regel 2 geeft gebruiker 2 toegang tot de toCaps methode.

• Regel 3 toont het gebruik van de nieuwe use-osgi-service functie. Gebruiker 2 zal slechts

toegang krijgen tot de getString methode van TestService1 indien de getEmergencyLevel

methode van bundel TestEmergencyMonitor ”high” weergeeft. Dit gebeurt elke derde keer.

• Regel 4 illustreert de mogelijkheid om accounting informatie te gebruiken in het beleid. Ge-

bruiker 2 kan de getObject methode enkel uitvoeren indien de vorige succesvolle toegang

van gebruiker 1 kwam. Door de TestService1User2 bundel twee maal uit te voeren, is het

duidelijk in de logs dat hij geen toegang meer krijgt, voer nu eenmaal TestService1User1

uit. Nu zal het toegangsverzoek van TestService1User2 terug eenmalig ingewilligd worden.

Het uitprinten van de XML aanvragen en antwoorden storend werkt, kan de ACService-

1.0.0.NOXML.jar bundel uit map no xml op de cd-rom in de plaats van de huidige ACService

bundel geınstalleerd worden in de KF2 desktop.

Om een verandering in het beleid (door test1.xml te bewerken) hard te maken, moet het

beleid gepusht worden door de PAP bundel te herstarten.

Testopstelling 2

De bestanden van deze testopstelling bevinden zich in de test2 map van de cd-rom. In de src

map staan alle bronbestanden. ACAdder bevat een script ACAdder.bat dat geconfigureerd is om


toegangsbeheer toe te voegen aan de TestService2-1.0.0.jar bundel. De 2 gebruikerbundels zijn al

geconfigureerd om een gebruikersnaam en wachtwoord mee te geven bij toegang tot de methode

public void putNumbers(int i, double d); en een gebruikersnaam, een wachtwoord en een

X.509 certificaat bij toegang tot de methode getString(String str, int i, Object o);. Ze

zullen dus niet meer werken met de originele serviceinterface.

TestService2User1 geeft als gebruikersnaam ”gooduser” door en gebruikt het client1.pem

certificaat dat effectief ondertekend is door de CA die zich in gacos.keystore bevindt. TestSer-

vice2User2 heeft als gebruikersnaam ”eviluser” en gebruikt badclient1.pem, een certificaat dat

door een andere CA getekend werd dan die in de gacos.keystore keystore.

Opnieuw moet eerst de TestService2-1.0.0.jar bundel aangepast worden om met het toegangs-

beheersysteem te kunnen samenwerken. Kopieer wederom de map test2 naar een beschrijfbare

plaats. Kopieer dan het TestService2-1.0.0.jar bestand uit map test2 naar de map ACAdder en

voert het script ACAdder.bat uit. Beantwoord de vragen zoals in de onderstaande log.

Do you want to add authentication credentials? y/n (default=n)

y

Generating the new serviceinterface...

public abstract void gacos.test.testservice2.TestService2.putNumbers(int,double)

Add username/password authentication? (Y/n)

y

Add X.509 certificate authentication? (Y/n)

n

public abstract java.lang.String gacos.test.testservice2.TestService2.getString

(java.lang.String,int,java.lang.Object)

Add username/password authentication? (Y/n)

y

Add X.509 certificate authentication? (Y/n)

y

Installeer de nieuw gecreerde bundel TestService2-1.0.0.jar.new.jar samen met de TestEmergencyMonitor-

1.0.0.jar, TestService2User1-1.0.0.jar en TestService2User2-1.0.0.jar in de KF2 desktop.

Alle regels die van toepassing zijn op deze testopstelling 2 bevinden zich in het test2.xml

5.3 Flexibiliteit van het beleid 73

beleidsbestand. Elke regel bevat een beschrijving in het <Description> XML element.

• Regel 1 laat het gebruik van de TestService2.putNumbers methode toe voor gebruikers

die succesvol geauthenticeerd werden en de gebruikersnaam ”gooduser” hebben. Deze

regel kan beınvloed worden door de naam van de toegelaten gebruiker te veranderen in het

beleid of te maken dat de gebruiker met als naam ”gooduser” niet meer geauthenticeerd

raakt (door pam.txt en password.txt te bewerken bijvoorbeeld).

• Regel 2 maakt terug gebruik van het oproepen van een externe functie met behulp van

de use-osgi-service XACML functie. Deze regel zal succesvol geevalueerd worden indien

het EmergencyLevel van de TestEmergencyMonitor niet ”high” is en de common name

van de eigenaar van het bijgevoegde certificaat gelijk aan ”client1” is. TestService2User1

heeft een dergelijk certificaat en zal dus toegang krijgen wanneer de getEmergencyLevel

methode ”low” of ”medium” teruggeeft.

• Regel 3 illustreert hoe een argument van de methode die opgeroepen wordt als attribuut

gebruikt kan worden. Deze regel geeft toegang tot de methode putNumbers aan oproepende

bundels die als eerste argument het getal ”1” meegeven. TestService2User2 voldoet aan

deze voorwaarde.

Door de wachtwoorden van de gebruikers in password.txt, de inloginstellingen in pam.txt en

de waarden in het beleid te veranderen kunnen de authenticatie- en authorisatiebeslissingen

veranderd worden.

5.3 Flexibiliteit van het beleid

De mogelijkheden van XACML zijn echt zeer uitgebreid. De verzameling ingebouwde func-

ties7 bevat al veel functies voor alle representeerbare datatypes. De mogelijkheid om ze uit

te breiden met nieuwe datatypes en functies is zeker een pluspunt zoals aangetoond is met de

use-osgi-service functie die externe informatie kan opvragen en gebruiken in het beleid. De

mogelijkheid om condities te combineren via de booleaanse functies maakt het mogelijk om zeer

ingewikkelde regels op te bouwen. Nieuwe informatiebronnen zoals een accountingmodule zijn

verbazingwekkend eenvoudig om te integreren met het XACML raamwerk.7De verzameling van constanten van Sun’s XACML bevat een overzicht van de function-id’s. Zie het constant-

values.html bestand in de javadoc map van Sun’s XACML 2.0 op de cd-rom.

5.4 Gebruiksgemak 74

Het enige dat ontbreekt, is de mogelijkheid om expliciet variabelen te gebruiken zonder

restricties. De mogelijkheid om impliciete variabelen te gebruiken dankzij de target en condition

structuur van een regel, benadert die functionaliteit echter zeer goed.

5.4 Gebruiksgemak

Het dagelijks gebruik van het ontworpen toegangsbeheersysteem bestaat uit twee handelingen,

het toevoegen van toegangsbeheer aan bundels en het administeren van het beleid.

5.4.1 Installatie van een bundel met toegangsbeheer

De ACAdder applicatie is niet de meeste robuste en gebruiksvriendelijke applicatie ooit ontwor-

pen. Indien de bundel waaraan toegangsbeheer dient toegevoegd te worden op veel bibliotheken

steunt, kan het moeilijk zijn om de juist commandolijn opties mee te geven aan ACAdder. En

het gebruikt een de decompiler die slechts Java 1.3 ondersteunt om de activator van de bundel

te decompileren, voorspelt niet veel goeds.

Maar de applicatie kan wel een binair JAR-bestand van een bundel als invoer nemen en met

minimale gebruikersinteractie een kant en klare JAR-bundel uitvoeren. Indien de activator niet

te ingewikkeld is (wat wel in veel gevallen zo is, ze moet enkel diensten registreren en tracken),

brengt de applicatie wel betrouwbare resultaten voort.

5.4.2 Administratie van het beleid

XACML maakt duidelijk gebruik van een rule-based access control benadering tot toegangsbe-

heer. Het beleid wordt uitgestippeld door vooraf regels te definieren, er bestaan niet onmiddellijk

mogelijkheden om rollen aan gebruikers toe te wijzen (en dus een role-based benaderingswijze

tot toegangsbeheer te implementeren). Role-Based Access Control (RBAC) in een XACML om-

geving gebruiken, vergt een beetje werk. Gelukkig moet er niets veranderd worden. De rollen

worden toegewezen aan gebruikers in aparte beleidsbestanden, evenals de toelatingen en verbo-

den die aan een rol toegeschreven worden. Hoe dit precies in zijn werk gaat, staat beschreven

in Core and hierarchial role based access control profile of XACML v2.0 [21].

Op het vlak van administratie van het beleid moeten er toch enkele kritische opmerkingen

gemaakt worden.

Doordat XACML niet gebaseerd is op een logische taal maar van nul opgebouwd werd, zijn

de mogelijkheden om automatisch te redeneren over het beleid zeer beperkt. De mogelijkheid om

5.4 Gebruiksgemak 75

een reden te geven waarom een beleidsbeslissing genomen werd, zit dan ook niet in dit systeem.

Het is een eigenschap die sommige andere talen die wel op een logische taal zijn gebaseerd, wel

bezitten en zeer handig blijkt bij het administreren van een (grote8) verzameling regels. Het

zoeken naar de reden waarom iets niet lukt, is soms als zoeken naar een naald in een hooiberg.

Zoals reeds vermeld werd in hoofdstuk 3 over beleidstalen, bestaat er een XACML be-

leidseditor die XACML v2.0 compatibel is, namelijk de UMU XACML Editor. De website

http://xacml.dif.um.es/ is echter nooit bereikbaar geweest tussen september 2005 en augustus

2006, er werd niet gereageerd op e-mails en nergens valt er een mirror te bespeuren. In praktijk

bestaat er dus eigenlijk geen XACML beleidseditor. Een normale XML editor maakt het beheren

van een XACML beleidsbestand wel eenvoudiger maar kan een echte editor nooit vervangen.

Misschien brengt de toekomst wel een oplossing, XACML is en blijft de enige standaard,

nieuwe hulpapplicaties zullen dus wel moeten opduiken.

8Zelfs bij een kleine verzameling regels blijkt dit al handig.

BESLUIT 76

Hoofdstuk 6

Besluit

Het doel van deze thesis was om te onderzoeken hoe generiek toegangsbeheer voor OSGi-

gebaseerde software kon bereikt worden en om een implementatie te ontwikkelen om de gekozen

wijze te illustreren.

Onderweg moesten enkele keuzes gemaakt worden, te beginnen bij de keuze of het bestaande

toegangsbeheersysteem van het OSGi Framework zou uitgebreid worden of niet. Het OSGi toe-

gangsbeheersysteem blijkt rudimentair te zijn, het bestaat uit een uitbreiding van het permissie

model van Java. Het beleid wordt gedefinieerd door (conditie,permissie) tupels aan een tabel toe

te voegen, een schril contrast met de huidige toegangsbeheerraamwerken die met een beleidstaal

werken. Er bestaan geen mogelijkheden om meerdere condities te combineren, geen mogelijkhe-

den om variabelen te gebruiken, primitieve conflictresolutie en geen mogelijkheid om toegangs-

beheer op methodeniveau uit te voeren. Het werd duidelijk dat het permissietabel systeem niet

voldeed om een flexibel beleid te voeren op een gebruiksvriendelijke wijze. Daarenboven steunt

het systeem op de Conditional Permission Admin een optioneel onderdeel van de OSGi R4 dat

nog niet door geımplementeerd werd in de publiek toegankelijke OSGi implementaties.

De keuze werd gemaakt om het toegangsbeheersysteem van OSGi niet uit te breiden maar

om een flexibeler, bruikbaarder en fijn-korreliger toegangsbeheersysteem met als basis een echte

toegangsbeheerbeleidstaal, te ontwerpen.

Bij het zoeken naar een beleidstaal blonken 2 kandidaten uit, KAoS en XACML. KAoS is

niet zo flexibel en uitbreidbaar als XACML maar het raamwerk is wel uitgebreider en omvat een

uitstekende beleidsadministratieapplicatie. XACML daarentegen, is een recentere toegangsbe-

heertaal, een OASIS open standaard (die de steun heeft van o.a. Sun Microsystems, IBM, Oracle

en Computer Associates), van niets ontworpen (en kent dus geen beperkingen op de structuur

6.1 Doel bereikt? 77

door een onderliggende logische taal), XML gebaseerd en is zeer flexibel en uitbreidbaar. Uit-

eindelijk werd niet voor het gebruiksvriendelijkere KAoS gekozen maar wel voor XACML. De

voornaamste redenen waren de flexibiliteit en het feit dat het vooralsnog de enige toegangsbe-

heerbeleidstaal is die gestandaardiseerd werd.

Vervolgens moest gekozen worden of het systeem op methodeniveau of bundelniveau toe-

gangsbeheer zou afdwingen. Er werd geopteerd om op methodeniveau de beleidsbeslissingen af

te dwingen. Een grotere flexibiliteit en de mogelijkheid om credentials aan methodes toe te voe-

gen waren de drijfveren achter deze keuze. Het zou een herbruikbaar, generiek en uiterst flexibel

toegangsbeheersysteem voor het OSGi Framework worden dat authenticatie, authorisatie en

accounting implementeert.

6.1 Doel bereikt?

Het doel werd niet volledig bereikt. Door ”Generiek toegangsbeheer voor OSGi-gebaseerde soft-

ware” als doel voorop te stellen, werd impliciet verondersteld om de belangrijkste eigenschappen

van een toegangsbeheersysteem, zoals de flexibiliteit en bruikbaarheid, te trachten te maxima-

liseren.

Om het toegangsbeheersysteem op basis van het XACML raamwerk te bouwen, blijkt een

uitstekende keuze. Het XACML raamwerk is eenvoudig maar toch krachtig. OSGi specifieke

attributen en attributen afkomstig van de gebruikerscredentials kunnen gebruikt worden bij de

beleidsbeslissing, zelfs resultaten bekomen door een methode van een andere bundel uit te voeren

kunnen verwerkt worden in de beleidsbeslissingen. XACML bevat een grote verzameling interne

functies en alle nodige attribuuttypes om te voldoen aan de flexibiliteitseisen. Ook de keuze

om JAAS als authenticatiemechanisme te hanteren, komt goed uit. Alle JAAS loginmodules

die enkel een gebruikersnaam en wachtwoord vergen, zijn compatibel met het authenticatieme-

chanisme van het geımplementeerde toegangsbeheersysteem. Subjecten kunnen geauthenticeerd

worden via o.a. LDAP, JNDI en Kerberos. Op het vlak van flexibiliteit werd het doel dus

bereikt.

Waar het systeem echter tekort komt, is bij het afdwingen van het beleid. Dat de keuze

om op methodeniveau te werken moeilijkheden meebrengt voor de implementatie van het PEP

(Policy Enforcement Point), is logisch en was op voorhand geweten. Het geımplementeerde

systeem voegt een nieuwe serviceimplementatie toe aan een te beschermen bundel en vanuit

deze nieuwe implementatie wordt eerst het toegangsbeheersysteem opgeroepen en vervolgens

6.1 Doel bereikt? 78

ofwel de originele methode uitgevoerd ofwel een runtime exceptie opgeworpen. Dit systeem

werkt, het biedt de mogelijkheid om credentials te vereisen door argumenten toe te voegen en

gebruikers van de dienst zouden (volgens de OSGi bundel programmeerrichtlijnen) steeds een

runtime exceptie moeten verwachten bij het uitvoeren, de Deny situatie brengt dus geen fouten

met zich mee.

Het probleem is de bruikbaarheid. Een bundel moet aangepast worden vooraleer de toegang

tot deze bundel kan beheerd worden. Er werd een applicatie ontworpen die dit proces automa-

tiseert maar deze applicatie maakt gebruik van decompilatie van de activator van de bundel. Er

kan bijgevolg niet gegarandeerd worden dat het toevoegen van toegangsbeheer aan een bundel

succesvol zal gebeuren. Om bij installatie van een nieuwe bundel in een OSGi systeem het boven-

staande proces automatisch te laten uitvoeren, moet de classloader van de OSGi implementatie

vervangen worden door een eigen classloader. Deze eigen classloader kan dan de gegeven bundel

laden, veranderen en de veranderde bundel doorgeven aan de installatieprocedure. Dit strookt

echter niet met de gestelde vereiste dat er enkel gebruik mag gemaakt worden van de standaard

OSGi API. Een minder intrusieve manier om toegangsbeheer af te dwingen op methodeniveau

zou een vooruitgang in bruikbaarheid betekenen.

Bij de administratie van het XACML beleid moet ook een opmerking gemaakt worden, er

werd een XACML beleidseditor ontwikkeld aan de universiteit van Murcia (Spanje) maar deze

blijkt onvindbaar en kon dus niet getest worden. Voor het ogenblik wordt het beleid nog met

een gewone XML editor bewerkt, dit volstaat voor testsituaties. Door het feit dat XACML nog

niet zo lang geleden gestandaardiseerd werd en nog in volle ontwikkeling is, wordt verwacht dat

er in de toekomst wel meer hulp- en administratieapplicaties voor XACML zullen opduiken.

BIBLIOGRAFIE 79

Bibliografie

[1] Enterprise Privacy Authorization Language (EPAL 1.1). URL http://www.zurich.ibm.

com/security/enterprise-privacy/epal/.

[2] Java 2 Security Architecture, Version 1.2. URL http://java.sun.com/j2se/1.5.0/docs/

guide/security/spec/security-spec.% doc.html.

[3] KAoS Policy and Domain Services. URL http://www.ihmc.us/research/projects/

KAoS/.

[4] OASIS eXtensible Access Control Markup Language (XACML) TC. URL http://www.

oasis-open.org/committees/xacml/.

[5] OASIS (Organization for the Advancement of Structured Information Standards). URL

http://www.oasis-open.org/.

[6] The OSGi Service Platform - The Dynamic Module System for Java. URL http://www.

osgi.org/.

[7] OSGi Service Tutorial. URL http://www.knopflerfish.org/osgi_service_tutorial.

html.

[8] OWL Web Ontology Language. URL http://www.w3.org/TR/owl-features.

[9] PeerTrust. URL http://sourceforge.net/projects/peertrust.

[10] Platform for Privacy Preferences (P3P) Project. URL http://www.w3.org/P3P/.

[11] Ponder: A Policy Language for Distributed Systems Management. URL http://www-dse.

doc.ic.ac.uk/Research/policies/ponder.shtml.

[12] RDF. URL http://www.w3.org/RDF.

BIBLIOGRAFIE 80

[13] Rei : A Policy Specification Language. URL http://rei.umbc.edu/.

[14] REWERSE WG I2 - Policy language, enforcement, composition. URL http://rewerse.

net/I2/.

[15] Sun’s XACML Implementation. URL http://sunxacml.sourceforge.net.

[16] ISO/IEC 10181-3:1996 Information technology – Open Systems Interconnection – Security

frameworks for open systems: Access control framework. ISO/IEC, 1 edition, 1996.

[17] Permissions in the Java 2 SDK, 2002. URL http://java.sun.com/j2se/1.4.2/docs/

guide/security/permissions.html% fi.

[18] About the OSGi Service Platform, Revision 3.0. Technical whitepaper, OSGi Alliance,

2004.

[19] OSGi Service Platform Core Specification, Release 4. The OSGi Alliance, August 2005.

[20] Anne Anderson. A Comparison of Two Privacy Policy Languages: EPAL and XACML.

Technical report, Sun Microsystems, 2005.

[21] Anne Anderson. Core and hierarchical role based access control (RBAC) profile of XACML

v2.0. Technical report, Sun Microsystems, 2005. URL http://docs.oasis-open.org/

xacml/2.0/access_control-xacml-2.0-rbac-pro% file1-spec-os.pdf.

[22] Jeffrey Bradshaw Andrzej Uszok. KAoS Tutorial. URL http://ontology.ihmc.us/KAoS/

KAoS_Tutorial_files/frame.htm.

[23] Piero A. Bonatti and Daniel Olmedilla. Driving and Monitoring Provisional Trust Negoti-

ation with Metapolicies. Technical report, REWERSE, 2005.

[24] Piero A. Bonatti and Daniel Olmedilla. I2-D2, Policy Language Specification. Technical

report, REWERSE, 2005.

[25] Nicodemos Damianou, Naranker Dulay, Emil Lupu, and Morris Sloman. Ponder: a Langu-

age for Specifying Security And Management Policies for Distributed Systems. Technical

report, Imperial College, 2000.

[26] M. Johnson, P. Chang, R. Jeffers, J. Bradshaw, M. Breedy, L. Bunch, S. Kulkarni, J. Lott,

N. Suri, A. Uszok, and Von-Wun Soo. KAoS Semantic Policy and Domain Service: An

BIBLIOGRAFIE 81

Application of DAML to Web Services-Base Grid Architectures. Technical report, Institute

for Human and Machine Cognition (IHMC), 2003.

[27] Lalana Kagal, Massimo Paoucci, Naveen Srinivasan, Grit Denker, Tim Finin, and Katia

Sycara. Authorization and Privacy for Semantic Web Services. IEEE Intelligent Systems,

19(4):50–56, july 2004.

[28] Lalana Kagal, Massimo Paoucci, Naveen Srinivasan, Grit Denker, Tim Finin, and Katia

Sycara. Authorization and Privacy for Semantic Web Services. In First International

Semantic Web Services Symposium, AAAI 2004 Spring Symposium. American Association

for Artificial Intelligence, March 2004.

[29] Serge Bogeholz Mark Evered. A Case Study in Access Control Requirements for a Health

Information System. Technical report, University of New England, Australia, 2004.

[30] Shriram Krishnamurthi Michael Carl Tschantz. Towards Reasonability Properties for

Access-Control Policy Languages. Technical report, 2006.

[31] Sun Microsystems. Pluggable Authentication Modules. URL http://www.sun.com/

software/solaris/pam/.

[32] Tim Moses, editor. eXtensible Access Control Markup Language (XACML) Version 2.0.

OASIS Standard. OASIS, 1 Februari 2005. URL http://docs.oasis-open.org/xacml/2.

0/access_control-xacml-2.0-core-spe% c-os.pdf.

[33] Daniel Olmedilla Piero A. Bonatti. Semantic Web Policies: Where are we and What is still

Missing? Technical report, Rewerse, 2006.

[34] D. Pendarakis R.Yavatkar, R. Guerin. A Framework for Policy-based Admission Control.

Number 2753 in Request For Comment. IETF, 2000. URL http://www.ietf.org/rfc/

rfc2753.txt.

[35] Alvaro Arenas Syed Naqvi, Philippe Massonet. A Study of Languages for the Specification

of Grid Security Policies. Technical report, CoreGRID, 2006.

Generiek toegangsbeheer voor OSGi-gebaseerde software

Documents

Transcript of Generiek toegangsbeheer voor OSGi-gebaseerde software