Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
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
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
1.3 OSGi en toegangsbeheer 7
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.
1.3 OSGi en toegangsbeheer 8
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]
1.3 OSGi en toegangsbeheer 9
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
2.5 Algemeen ontwerp 16
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.
2.5 Algemeen ontwerp 17
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]
3.2 Toegangsbeheerbeleidstalen 22
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
3.2 Toegangsbeheerbeleidstalen 23
<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
3.2 Toegangsbeheerbeleidstalen 24
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.
3.2 Toegangsbeheerbeleidstalen 25
Beleidsrepresentatie
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.
3.2 Toegangsbeheerbeleidstalen 26
<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
3.2 Toegangsbeheerbeleidstalen 27
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.
Beleidsrepresentatie
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
3.2 Toegangsbeheerbeleidstalen 28
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
3.2 Toegangsbeheerbeleidstalen 29
<?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.
4.3 Implementatie 42
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.3 Implementatie 43
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-, object- en 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.
4.3 Implementatie 44
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.
4.3 Implementatie 45
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
4.3 Implementatie 46
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
4.3 Implementatie 47
Figuur 4.5: structuur van de Policy Authentication Point package
4.3 Implementatie 48
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
4.3 Implementatie 49
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.
4.3 Implementatie 50
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
4.3 Implementatie 51
Figuur 4.7: structuur van de Access Control Service package
4.3 Implementatie 52
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
4.3 Implementatie 53
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.
4.3 Implementatie 54
Figuur 4.8: Policy Decision Point implementatie
4.3 Implementatie 55
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/
4.3 Implementatie 56
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.
4.3 Implementatie 57
Figuur 4.9: credential package
4.3 Implementatie 58
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
4.3 Implementatie 59
Figuur 4.10: structuur van de Policy Administration Point package
4.3 Implementatie 60
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
4.3 Implementatie 61
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.
4.3 Implementatie 62
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
4.3 Implementatie 63
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.
5.2 Testopstellingen 70
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] object gotten
[stdout] This is an object.
[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.
5.2 Testopstellingen 71
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.
[stdout] object gotten
[stdout] This is an object.
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
5.2 Testopstellingen 72
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.