OSGi.nl

Dat security een van de minst gebruikte aspecten van OSGi is, bleek al tijdens de voorbereiding op de workshop die Karl Pauls en ik gaven op de EclipseCon 2008. We wilden daarvoor zowel Equinox als Apache Felix gebruiken. Voor de laatste had Karl de implementatie al voor 80% af en deze workshop was een mooie stok achter de deur om de missende 20% te completeren. Voor Equinox ontdekten we dat er geen enkele vorm van documentatie was over hoe je security aan moest zetten en gaandeweg het maken van de opdrachten kwamen we nog wat problemen tegen die we direct aan de developers gemeld hebben.

De workshop zelf werd prima ontvangen. We hadden een relatief kleine groep van ongeveer 20 man, wat betekende dat we de sessie zelf zeer interactief konden houden met voldoende aandacht voor een ieders vragen. Stap voor stap lieten we aan de hand van voorbeelden zien hoe je de verschillende security features kon gebruiken.

Kort samengevat bouwt OSGi security voort op de security policies in Java, met een aantal verschillen die voortkomen uit de architectuur van het framework en de bijbehorende dynamiek:

• Policies zijn run-time te installeren en updaten, wat nodig is als je ook run-time componenten kunt toevoegen, updaten en verwijderen. Hiervoor zijn services beschikbaar die zelf uiteraard ook afgeschermd kunnen worden.
• De standaard permissies om dingen als file en netwerk I/O af te schermen worden uitgebreid met specifieke permissies om toegang tot services en packages te beperken.
• Run-time kun je ook nieuwe condities toevoegen die zelfs interactie met een gebruiker kunnen triggeren, zoals bijvoorbeeld Windows Vista expliciet vraagt om bepaalde permissies voor ‘t de applicatie toegang geeft tot bepaalde delen van het systeem.

Dat security zo weinig wordt gebruikt heeft volgens mij verschillende oorzaken, maar het belangrijkste punt is dat ik vind dat het ten onrechte zo weinig gebruikt wordt. Dat wil zeggen, er zijn uiteraard verschillende niveau’s waarop je security kunt integreren in je omgeving. In een aantal gevallen is het eenvoudiger en wellicht zelfs wenselijk om de security niet in de applicatie zelf op te lossen, maar in bijvoorbeeld het netwerk waarop de applicatie draait. Als je in je OSGi applicatie echter third-parties toegang geeft tot de applicatie om ze plugins te laten ontwikkelen, dan is OSGi security een hele goede en robuuste oplossing waarbij je interne services en code prima kunt afschermen. Daarnaast vereenvoudigt security ook het auditen van extern ontwikkelde plugins door een declaratief model wat het overbodig maakt om de bytecode zelf te inspecteren. Het voert wat te ver om tot in detail uit te leggen hoe dit werkt, maar als je wel eens hebt meegemaakt dat extern ontwikkelde componenten je eigen applicatie dusdanig beïnvloedden dat de eindgebruiker er problemen mee kreeg die jij vervolgens moest vinden en oplossen, dan weet je dat dit soort situaties niet slechts hypothetisch zijn.

Kortom, kijk eens serieus naar OSGi security en evalueer het. Als je kiest voor Apache Felix dan kun je op de mailing lijst voor gebruikers terecht voor vragen. Daar krijg je doorgaans snel antwoord.