Tegenwoordig worden Grid Computing services gebruikt in grote samenwerkingsverbanden (voornamelijk in wetenschappelijke instituten), waar verschillende gebruikers zich kunnen beroepen op de services of de combinatie van services om zo nieuwe Grid services te construeren (bv. Optiputer project [ http://www.optiputer.net] , waar een virtuele computer is ontwikkeld die gebruik maakt van disk space services, computing services en display services). Door het delen van de resources wordt de toegangscontrole belangrijk, de Grid middleware moet o.a. vertrouwen tot stand brengen tussen de betrokken partners en ongeautoriseerde toegang en diefstal van resources te voorkomen. Tevens biedt de Grid middleware alles wat nodig is om resource service te creëren en te managen. We hebben een autorisatie framework nodig om de toegangscontrole van de resources tussen de betrokken domeinen uit te voeren.

De Open Grid Service Infrastructure (OGSI) [http://www.ggf.org] definieert zo’n autorisatie framework. Het omgaan met de autorisatie beslissing waar meerdere administrative domeinen betrokken bij zijn is een complexe materie. De multi-domain autorisatie aspecten zoals trust building en token sharing zijn nog steeds in ontwikkeling binnen het OGSI. De industrie zal de Grid computing concepten alleen accepteren wanneer de veiligheid is gegarandeerd en hun gevoelige zakelijke informatie is beschermd. In dit artikel proberen we enkele van de basic concepten van een autorisatie framework uit te leggen. De authenticatie vraag wordt hierbij buiten beschouwing gelaten.

In dit artikel wordt gefocust op de key-points van een generiek autorisatie framework. Het is niet onze bedoeling om hier een compleet framework te beschrijven, we willen alleen een lijst van enkele van de bouwstenen opsommen om een simpel prototype van een autorisatie service te bespreken. Over het algemeen bestaat een autorisatie service uit een Policy Decision Point (PDP), een Policy Enforcement Point (PEP) en een policy repository (opslagplaats). De autorisatie service vormt de schakkel tussen de gebruiker (user) en de service. We zullen eerst deze interacties bespreken en vervolgens passeren de bouwstenen de revue. Daarna komen we terug op een proof of concept om wat meer inzicht te kunnen geven. Zie figuur 1 een autorisatie service opgebouwd uit de bouwstenen:

Fig.1 Autorisatie service, user en service.

Sequences
Een autorisatie framework zou in staat moeten zijn om verschillende interacties tussen gebruikers, services en de autorisatie service of ook wel authority af te handelen. Drie basis sequences worden erkend in [RFC 2904 / http://www.ietf.org], de zogenaamde push, pull en agent sequences. Combinaties van deze basis sequences kunnen worden gemaakt, dit wordt gedaan om de autorisatie sterker te maken. De sequences :

Agent: Figuur 2 toont de agent sequence. Gebruikers request, stuurt een request message (1) naar de Authority om een Service te gebruiken. De Authority controleert de services (2)(3) of er aan het request tegemoet kan worden gekomen. Zo ja, krijgt de gebruiker een boodschap terug dat hij geautoriseerd is om de service te gebruiken. De Authority onttrekt de service specifieke zaken en doet dienst als een agent.

Fig.2 Agent sequence.

Pull: Figuur 3 geeft de pull sequence weer. De gebruiker roept de Service (1) op, de service controleert bij de Authority of deze specifieke gebruiker gebruik mag maken van de service (2)(3). De gebruiker wordt op de hoogte gesteld als hij geautoriseerd is (4). De service pulls (ontrekt) de autorisatie.

Fig.3 Pull sequence.

Push: De gebruiker vraagt eerst een token aan bij de authority voor een specifieke Service (1), zie figuur 4. Indien geautoriseerd, stuurt de Authority een token terug naar de gebruiker (2). De gebruiker toont het token (3) in combinatie met de service aanvraag naar de service. De service antwoord een authorized acknowledge terug naar de gebruiker (4).

Fig.4 Push sequence.

In alle hierboven afgebeelde sequences is het actueel gebruik van de service niet gegeven. De autorisatie boodschap kan in band of out of band zijn met het actueel service gebruik. Belangrijk is dat de service de sequence bepaalt.

Policy Decision Point
De verzoeken van de gebruiker worden verwerkt in een policy engine, rule based engine of Policy Decision Point (PDP). Voor ieder verzoek van de gebruiker wordt de corresponderende policy bepaald. De policy beschrijft de voorwaarden om een resource te mogen gebruiken. Dit autorisatie proces kan worden vergeleken met het verzamelen van handtekeningen van autoriteiten op een gemeenschappelijk document. Bij de juiste condities wordt de gebruiker geautoriseerd om de (gevraagde) resources te gebruiken. Om een algemeen autorisatie framework te maken is het wenselijk de policy logic en de semantics van de policy te scheiden. Het semantisch deel kan worden begrepen door context specifieke modules [Application Specific Modules, (ASM) see RFC2903]. Deze modules begrijpen de onderliggende behoefte van een bepaalde resource of service en vertalen de specifieke eigenschappen naar logische waarden. In het algemeen heeft een autorisatie service een verzameling ASMs tot zijn beschikking om de toegangscontrole voor de betreffende service uit te kunnen voeren. De ASMs moeten flexibel te (ont)koppelen zijn met de PDP.
Als voorbeeld voor een ASM nemen we een aanvraag over bandbreedte capaciteit, de specifieke module die de bandbreedte service ondersteund begrijpt de gebruikers vraag van bandbreedte en levert de PDP een antwoord terug, dat gebruikt kan worden in de policy evaluatie. De autorisatie kan worden gegeven in de vorm van tokens (credentials). We definiëren een token als een cryptographically getekende lijst van attributen. Het tekenen (Signen) zorgt voor de bron authenticiteit en integriteit van attributen opgeslagen in het token. Attributen zijn bijvoorbeeld de hoeveelheid geautoriseerde bandbreedte, maar ook de identiteit van de gebruiker.

Policy Enforcement Point
Voor de service controleert een interceptor of een vraag van een gebruiker de vereiste autorisatie(s) heeft. We noemen deze interceptor de Policy Enforcement Point (PEP), deze controle vertegenwoordigd de resource gebruiksbeperkingen. In grote architecturen zijn de PDP en PEP gescheiden entiteiten, de PEP verzoekt de PDP te helpen bij het nemen van de beslissingen, met name op de trust issues. In kleinere architectures wordt het vaak gecombineerd als één enkele entiteit. Net zoals de PDP kunnen specifieke toegangseisen met behulp van ASMs geregeld worden. Zoals in het eerder genoemde voorbeeld voor bandbreedte service kan een router een bepaalde poorten openen of VLAN creëren.

Policies
Het komt hierop neer dat een policy de zakelijke voorwaarden (regels) beschrijft van het gebruik van een resource. Voorwaarden zijn gespecificeerd op zakelijk niveau. Zoals: gezette tijden tussen 8.00 am en 1.00 pm kan de resource worden gebruikt, of alleen de aanvragen van gebruikers afkomstig van domain X enz. We concentreren ons op de multi-domein aspecten om autorisaties aanvragen tussen de betrokken partijen af te handelen. Om een autorisatie framework te maken voor een multi-administratief domein context is flexibiliteit noodzakelijk voor het beschrijven van de regels in policies en om deze regels toe te passen in de PDP en / of PEP. Er is een soort engine nodig die automatisch een gebruikersaanvraag toetst en de bijbehorende policy ophaalt uit de policy repository. Elk administratief domein definieert zijn eigen verzameling van policies. Voor elke aanvraag waar een bepaalde resource voor vereist is, bestaat een policy die de condities voor het gebruik van deze resource beschrijft. Een service waar meerder domeinen bij betrokken zijn is of kan pas geautoriseerd worden als er overeenstemming is tussen de betrokken domeinen. Er zijn meerdere oplossingen mogelijk om deze overeenstemming te verzamelen en te toetsen.

Prototype Autorisatie Service
Als onderzoek voor een generieke autorisatie service hebben we een prototype gebouwd (toen ik werkzaam was bij de UvA) met de volgende technologieën: javacc, serialization, web services. Hieronder volgt een kort overzicht van de besproken bouwstenen in combinatie met de gebruikte technieken.

Onze policy taal is gebaseerd op een eenvoudige if-then-else structuur. In elke if statement wordt een condition gecontroleerd en de juiste actie ondernomen. Met Javacc hebben we onze policy parser geconstrueerd [https://javacc.dev.java.net/] om deze taal te parsen. Een policy wordt geparsed en om gezet in een policy object. Deze policy objecten worden daarna geserializeerd en opgeslagen in de policy repository met een bepaald service label. Dit label wordt gebruikt om de service aanvraag te matchen met het policy object.Bekijk het volgende policy-fragment:

[code]if ( ( ASM::Authz.validateToken( Request::AAA.Authz.SimpleToken ) )
then
(vlanId = ASM::ServiceX.add2Vlan(Request::AAA.mac);
Reply::Answer.message = vlanId;Reply::Answer=”permit”)
else
(Reply::Answer = “denied ” )[/code]

De voorbeeld policy beschermt onze video gateway in de push-sequence. De gebruiker stuurt een aanvraag naar de autorisatie service door het pushen van een token naar de PEP/PDP. In de eerste regel wordt het token gecontroleerd. In de tweede regel wordt onze computer (port met mac address) toegevoegd aan een bepaalde vlan waarin we de gevraagde video stream zouden kunnen zien. Als het token niet valide zou zijn geweest, was ons het gebruik van de service geweigerd.

In de policy hebben we de Request::. variabelen gespecificeerd, welke corresponderen met de request message element names. Het request voor als het ware de data in het policy object. De gebruikersaanvraag ziet er dan ongeveer zo uit:


<VideoOnDemandService>
<AAA>
<Authz>
<SimpleToken>... Token...</SimpleToken>
</Authz>
<Mac>00:63:5B:4A:01:9D</Mac>
</AAA>
<VIDEO>
... video specific details, e.g. Genre, author.
</VIDEO>
</VideoOnDemandService>


Elke reference van ASM::.(args) in de policy definieert een component gebruikt bij het handelen van het semantisch deel van de service aanvraag. Op deze manier houden we de policy evaluation eenvoudig gebaseerd op primitieve waarden geretourneerd door de ASMs.

We slagen er op deze manier in een flexibel en eenvoudig dynamic system te creëren: Alle policy zijn verzameld en dit zorgt ervoor dat de policy kan worden evaluated at run-time. Als tweede zijn de gebruikte pluggable modules gespecificeerd in de policy, we gaan ervan uit dat deze ook geladen zijn of al aanwezig zijn in de PEP/PDP wanneer de policy wordt uitgevoerd. De pluggable modules (ASMs) maken het prototype flexibel in het ondersteunen van de verschillende services. De taal blijkt krachtig genoeg om de businessvoorwaarden te kunnen beschrijven, door middel van geneste if-then-else structuren kunnen complexe regels worden beschreven.

Grid Autorisatie Framework
De Globus Toolkit (GT) [www.globus.org] is de reference implementatie van het Global Grid Forum gebaseerd op de OGSI specificaties. In de GT versie 4 toolkit is een nieuw autorisatie framework ontwikkeld. De basics beschreven in dit artikel maken deel uit van de GT4 autorisatie stub geleverd door de Grid middleware, zie figuur 5 de bouwstenen in the Globus toolkit:

Fig.5 Autorisatie in de Globus Toolkit v4.

In dit figuur herkennen we een centrale PDP, deze PDP kan zich beroepen op andere PDP’s en zelfs externe PDP kan worden gebruikt (autorisatie services) om de definitieve beslissing te maken. Voor elke service herkend als Grid Service wordt deze run-time stub gegenereert. In ons geval konden we inhaken in met ons prototype om een gedeelte van de user request te evalueren en de autorisatie te bepalen. De centrale PDP of master PDP verzamelt alle statements van de betrokken PDP’s, de policy beschrijft welke PDP’s er nodig zijn en hoe het definitieve resultaat wordt bepaald.
De multi domein aspecten is nog steeds in onderzoek.

Conclusie
Grid services worden gedeeld in de Grid community. De resources moeten worden beschermd met een authorization framework om resource diefstal tegen te gaan. We hebben de key aspecten van een authorization framework de revue laten passeren om een flexibele authorisatie service te creëren. Dit is een klein gedeelte van het security verhaal, andere trends zijn het authenticatie gebied en met name het identity management en single sign on. Voor toekomstige authorization frameworks worden veelbelovende technologiën ontwikkeld om attributen uit te kunnen wisselen, zoals de SAML v2 specification [zie OASIS, http://www.oasis-open.org]. De Grid computing arena werkt als een early adopter of levert de eerste specificaties van opkomende technologiën. Het is nuttig om de richting van dit gebied te volgen en te toestsen of de concepten al ingezet kunnen worden bedrijfsapplicaties .

Referenties
Dit artikel is gebaseerd op het volgende paper:

Leon Gommans, Bas van Oudenaarde, Freek Dijkstra, Cees de Laat, Tal Lavian, Inder Monga, Arie Taal, Franco Travostino, Alfred Wan, “Applications Drive Secure Lightpath Creation across Heterogeneous Domains”, IEEE Communications Magazine, Feature topic Optical Control Planes for Grid Networks: Opportunities, Challenges and the Vision, vol. 44, no. 3, March 2006.

—————————————————————————————
Meer weten over SOA-specialist Finalist IT Group?