Extending XACML Authorisation Model to Support Policy Obligations Handling in Distributed Applications

Please download to get full document.

View again

of 6
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Document Description
Extending XACML Authorisation Model to Support Policy Obligations Handling in Distributed Applications
Document Share
Document Tags
Document Transcript
  Extending XACML Authorisation Model to Support Policy ObligationsHandling in Distributed Applications Yuri Demchenko #1 , Cees de Laat #2  Oscar Koeroo *3 , Hakon Sagehaug **4   1 demch@science.uva.nl, 2 delaat@science.uva.nl # System and Network Engineering Group, University of Amsterdam 3 okoeroo@nikhef.nl *  NIKHEF 4 hakon.sagehaug@bccs.uib.no ** BCCS, UNIFOB AS Abstract The paper summarises the recent and on-goingdevelopments and discussions in the Grid securitycommunity to built interoperable and scalable AuthZinfrastructure for distributed applications. The paper  provides a short overview of the XACML policy format and  policy obligations definition in the XACML specification.The paper analyses the basic use cases for obligations incomputer Grids and on-demand network resource provisioning abstracted to the general complex resource provisioning (CRP) model to identify major requirementsand functionalities in obligations handling that further is proposed as a Reference Model for Obligations Handling(OHRM). The paper refers to ongoing implementations of the obligations interoperability and handling framework insuch project as EU funded projects EGEE and Phosphorus.The proposed implementation is based on the adoption and extension of the OASIS SAML2.0 profile of XACMLspecification but defining a number of missing interfacedefinitions and semantic conventions. The purpose of this paper is to facilitate wider discussion of the policyobligations concept based on the described ongoingimplementations. Keywords: Policy Obligations, Reference Model for PolicyObligations Handling, XACML, Complex ResourceProvisioning, Generic AAA Authorisation Framework. 1. Introduction Policy obligation is an important policy enforcementmechanism and a component of the policy based accesscontrol architecture. Policy obligations allow defining(mandatory) actions that must be taken in connection to the policy decision but can not be specified in the policydocument, or may not be known to the policy administrator.This also allows for separating policy decision stage and  policy enforcement stage that may require informationunknown for the policy decision point at the time of making policy decision, e.g. the resource or service status, user account status, available pool account, etc..Policy obligations is a part the XACML policy definition[1], however current XACML policy enforcement modeldoesn’t define how policy obligations can be handled byauthorisation system components.The goal of this paper is to fill the gap between generalconcept and many implementation details that playsignificant role in building interoperable AuthZinfrastructure solutions.This paper discusses typical use cases for policyobligations use in computer Grids and on-demand network resource provisioning abstracted to the general complexresource provisioning (CRP) model and proposes aReference Model for Obligations Handling (OHRM) thatallows for different obligations enforcement scenarios.In the typical CRP scenarios, the initial policy decisionabout providing access or allocating resource to arequestor/user is done at the reservation stage but actual policy decision enforcement is done at the resource or service access stage.As an example, consider a user requesting a dedicated network path/connectivity at specific time from the Grid enabled Network Resource Provisioning System (NRPS).The NRPS checks user credentials/attributes against accesscontrol policy, network resource availability and makesadvance reservation. As a result of this the user can beassigned one of available pool accounts that should be used when accessing network resource and may be connected toa specific level or quality of service. The access control policy may contain a notion to map user identity or attributes to the pool account but it can not contain aspecific account name which is selected from the available pool. Other actions in connection to the policy decision can be assigning user quota, requirements to log specific data or accounting. These kind of requirements is typically solved  by using provisional policies or policy obligations.The paper is organized as follows. Section 2 provides ashort overview of the policy obligations definition inXACML. It important to note that this paper and the proposed solutions deal with the policy obligations as theyare defined in XACML what is different from the obligation policies as they defined in the Ponder policy language [2].Section 3 describes the general CRP model that separatesresource reservation, resource deployment, and resourceaccess or consumption stages. The section summarisescommon requirements to the authorisation (AuthZ) serviceinfrastructure to support multidomain CRP and identifiesthe basic use cases and required functionality for policyobligation handling.Section 4 introduces OHRM that extended XACML and generic authorisation models to support obligationshandling in the distributed AuthZ infrastructure. Section 5 provides implementation suggestions for the OHRM as a 1  component of the AuthZ infrastructure in Grid based applications.The presented research is a result of authors’ participation and contribution to wide internationalcoordination activity in building interoper[ble Grid oriented AuthZ infrastructure, that will allow flexible relation between central AuthZ services and distributed policyenforcement infrastructure.The presented research and proposed solutions arespecifically oriented for using with the popular Grid middleware being developed in the framework of lar ge international projects such as EGEE 1 and Globus Alliance 2 . 2. Policy Obligations definition inXACML A XACML policy is defined for the target tuple“Subject-Resource-Action” (S-R-A) which can also becompleted with the Environment (S-R-A-E) component toadd additional context to instant policy evaluation [1]. TheXACML policy can also specify the Obligations as actionsthat must be taken on positive or negative authorisationdecisions. Introducing policy obligations allows for moreflexible policy definition by separating stateless conditionsthat are based on the information provided in the accesscontrol request and stateful conditions that may depend onthe target system/resource state. This functionality isimportant for accounting in consumable resource provisioning or mapping requestor’s identity to the resource pre-defined internal (pool) accounts, what is a commonapproach in computer Grids.The XACML authorisation model corresponds to theX.812 Authorisation [3] and GAAA-AuthZ [4] models and includes the following major functional modules: PolicyEnforcement Point (PEP), Policy Decision Point (PDP),Policy Authority Point (PAP), and multifunctional ContextHandler (CtxHandler) that support all necessarycommunications between PEP and PDP.In the XACML authorisation model, a decision requestsent in a Request message provides context for the policy- based decision. The policy applicable to a particular decision request may be composed of a number of individual rules or policies, each of which can containobligations. XACML specifies a number of policy and rulecombination algorithms. The Response message maycontain multiple Result elements, which are related toindividual Resources. The Result element may contain inthe Obligations element a set of obligations returned byPDP extracted from applicable policies. It is stated thatObligations are returned by PDP “as is”, i.e. in a form asthey are written in the policy.There are no standard definitions in XACML version 2.0how the obligated actions should be processed. It should rely on the bilateral agreement between a resourcemanager/owner defining policies and the PEP that willenforce PDP’s decision. The XACML specification requiresthat PEPs must deny access unless they understand and canenforce all obligations returned in the PDP Responsemessage. 1 http://www.eu-egee.org/ 2 http://www.globus.org/ 3. Authorisation Infrastructure forMultidomain CRP 3.1. CRP in Computer Grids and on-demandNetwork Resource Provisioning Two major use cases for the general CRP [5, 6] arecomputer Grids and on-demand Network ResourceProvisioning. Although different in current implementations,they can be abstracted to the same CRP operational modelwhen considering their implementation with the Grid or Web Services and using common Grid middleware. Thisabstraction is considered as an important aspect to provide acommon access control infrastructure for distributed Grid-enabled resources that may include both computingresources and connecting them dedicated network infrastructure.Current network resource provisioning models usesimple pre-allocation/pre-scheduling. At the time of access,users just need to authenticate themselves and use prescheduled resource. Similar approach is used in currentGrid applications. The Grid job manager provides allresources allocation and coordination for the user tasks/jobs,and runs these tasks according to schedule. Such model can be considered as provider centric and leaves less freedom toa user. This model obviously implies significant restrictionsfor such highly dynamic environment as Grid resourceallocations and on-demand provisioning. If this kind of technologies to become widely used, more standardizationefforts are needed to define the whole CRP process and authorisation service components functionality to supportdifferent types of advance reservations for consumableresource, such as [7]: •   fixed advance reservations that imply stricttime/amount constraints (e.g., fixed time and network  bandwidth); •   deferrable advance reservation that allows somedegree of freedom in the time domain with fixed amount (or bandwidth); •   malleable advance reservation that allows variableduration and amount for the fixed consumption amount(e.g., transfer the necessary volume of data in the pre-defined time-frame with bandwidth that can bevariable).The typical on-demand resource provisioning includesthree major stages: resource reservation, resourcedeployment, and the reserved resource access or consumption. In its own turn, the reservation stage includesthe following basic steps: (1) resource lookup, (2) complexresource composition (including alternatives), (3)reservation of individual resources and their associationwith the global reservation ID/ticket. In multi-domain CRP,the reservation stage may require execution of complex procedures that may also request individual resourcesauthorisation. This process can be driven by a meta-scheduling system and controlled by the provisioning/reservation workflow that should also handledomain related AuthZ policies.Such specific usecase as multidomain CRP may requirethat resource reservation policy in each successive domainrelies on the previous domain positive AuthZ decision or isconditional to executing some actions or obligations inother domains. First requirement can be satisfied by usingXACML Environment element that contains AuthZdecision from the previous domain. Conditional (or  2   provisional) AuthZ decision can be achieved by usingXACML policy obligations supported by consistent policyobligations enforcement mechanisms. This functionalityrequires extended AuthZ context exchange betweendomains and can be achieved by using AuthZ ticket thatwas proposed in [8] and can communicate full AuthZdecision context in a secure way.In the discussed multidomain CRP model, domains or sites (as associations of entities) are defined by common policy under single administration, common namespace and semantics, shared trust relations and authorities, etc. Accesscontrol to all domain or site related resources can becontrolled by Domain or Site Central AuthZ Service(DCAS or SCAS) that can simplify common domain/siteaccess control policies management and resourcemanagement in general. However for such complexresources as Optical Networks or Computer Grid clustersthere is no possibility to define policy componentsdependent on the resources state or other event related tothe user task execution. This problem can be solved byadding stateful policy obligations to the site-central stateless policies. Such functionality is available in the XACML butit needs to be supported by common obligations handlingmodel and mechanisms, which however should be defined in a way independent of a policy format to ensureinteroperability of different AuthZ frameworks that may be present in a distributed multidomain environment.In the context of the distributed AuthZ architecture for CRP, obligations provide an important mechanism for  policy decision enforcement in the provisioned network resources, in particular, obligations can be used for mapping global user ID/account to local accounts or groups,assigning quotas or usage limits, services/resourcescombination with implied conditions (e.g., computing and storage resources). 3.2. Authorisation service components tosupport multidomain CRP To support multidomain CRP, the AuthZ infrastructureshould provide the following functionality: •   AuthZ session management to support complexAuthZ decision and multiple resources access,including multiple resources belonging to differentadministrative and security domains. •   AuthZ tickets with extended functionality tosupport AuthZ session management, delegation and obligated policy decisions. •   Authorisation and reservation tokens as policyenforcement mechanisms. •   Policy obligations handling to support conditional(or provisional) policy decision that can be made bysite/domain central AuthZ service.Figure 1 illustrates the major GAAA-AuthZ componentsand how they interact when evaluating a service request [9,6].The authorisation service is called from theservice/application interface via the AuthZ gateway (thatcan be just an interceptor process called from the service or application) that intercepts a service request ServiceRequset(ServiceId, AuthN, AuthZ) that contains a service name(and variables if necessary) and AuthN/AuthZattributes/credentials. The AuthZ Gateway extractsnecessary information and sends an AuthZ requestAuthzRequest (ServiceId, Subject, Action), that contains aservice name ServiceId, the requestor’s identification and credentials, and the requested Action(s), to the PEP. Themajor PEP’s task is to convert AuthZ request’s semanticsinto the PDP request which semantics is actually defined bythe used policy. When using an XACML policy and correspondingly an XACML PDP, the PEP will send anXACML AuthZ request to the PDP in the format (Subject,Resource, Attributes, (Environment)). The Policy DecisionPoint (PDP) evaluates the request and makes a decisionwhether to grant access or not. Based on a positive AuthZdecision (in one domain) the AuthZ ticket (AuthzTicket)can be generated by the PDP or PEP and communicated tothe next domain where it may be processed as a securitycontext or policy evaluation environment. If in general casethe XACML policy contains obligations, they are returned in the XACMLAzResponse (AuthzDecision, Obligations).The PEP (or in more general case Context Handler) callsthe Obligation Handler to process obligations. ObligationHandler ContextHandler  PEPPDPPAP AuthZ Gateway(AuthZ Handler) Resource NE/GMPLS ServReq(Srv,An,Az)XACMLAzResp(AzDcsn,Oblig)ServReq(Srv,Oblig2)   PDPTVS AzReq (Srv,Subj,Act))Validate(AuthzToken)XACMLAzRespAzDcsn  NRPS/Srv IFGAAA-AuthZ XACMLPolicy(Target(S,R,A,E),Rules(S,R,A,E),Oblig0)XACMLAzReq (S,R,A,E)   Figure 1. GAAA-AuthZ components providingservice request evaluation The service request may contain AuthZ ticket that hold extended AuthZ session context or AuthZ token that can just reference a local or global reservation ID, or identify anAuthZ session in which context the request is sent. TheAuthZ token validation is performed by the Ticket/TokenValidation Service (TVS). The TVS is typically called fromthe PEP and returns a confirmation if the ticket or token isvalid and match the AuthZ request context. IntroducingTVS as a separate function or service allow creatingflexible token based policy enforcement infrastructure for on-demand network resource provisioning [6].Using AuthZ tickets during the reservation stage for communicating interdomain AuthZ context is essential toensure effective decision making. At the serviceaccess/consumption stage the reserved resource may besimply identified by the reservation ID created as a result of the successful reservation process. The proposed and implemented in GAAA-AuthZ AuthZ ticket format [8]allows communicating Obligations between domain based authorisation services as a part of the AuthZ context. 4. Obligation Handling ReferenceModel (OHRM) In this section we will discuss the proposed ObligationsHandling Reference Model (OHRM) to support typical 3  CRP use cases. Obligations are included into the policydefinition and returned by PDP to PEP which in its turnshould take actions as prescribed in the obligationinstructions or statements.It is important to notice that obligations are an integral part of the policy and typically included into the policy atthe stage of its creation by the policy administrator or resource owner. For the manageability purpose, policy isconsidered stateless and the statefulness of obligations isachieved by the obligation handlers. The obligationsenforcement process may include few stages and can beresulted either in modifying the service request (e.g., mapfrom subject to account name/type) or by changing theresource/system sate or environment variables.Figure 2 below illustrates the proposed model for  processing obligations in the general case of the SiteCentral AuthZ Service (SCAS). The SCAS means that allsite/domain located resources and services use a centralAuthZ service that maintains a common set of policies for this domain. The described processing model is compliantto the model used in XACML [1] but specifically focuseson the obligations handling dataflow and adds Web services based AuthZ callout interface.The obligations handling model allows two types of obligations execution: at the time of receiving obligationsfrom the PDP and at the later time when accessing aresource or performing an authorised action. First type isdescribed below; the second type of handling obligationscan be achieved by using AuthZ ticket that holdsobligations together with the AuthZ decision.A number of assumptions are made to reflect possibleoptions in AuthZ service infrastructure implementation and different type of Obligations both stateful and stateless thatare concerned with assigning pool accounts, enforcingquotas, controlling usable resource (e.g., number of resource access, purchased video/music listening time, etc.),logging and accounting. SAML-XACMLRR CVS(extern)ObligationHandler (OH-PDP)ObligationHandler (OH-PEP)ContextHandler  PEPPDPPAP State DB(UsageController)State DB(UsageController)AuthZ Gateway(AuthZ Handler)SAML-XACMLRR PIP(Ctx Hdlr) Service/Resource ServReq(Srv,An,Az)ResourceObligHdlr (OH-R)AzResp(Dcsn,Oblig2)AzReq(Srv,Subj,Act))XACMLAzReq (S,R,A,E)WSDL AuthZ PT(SOAP/SSL)SAMLXACMLReq (S,R,A,E)XACMLAzResp(Dcsn,Oblig1)SAMLXACMLResp(Decsn,Oblig)XACMLAzReq (S,R,A,E)   XACMLAzRespDcsnObli1XACMLAzResp(Dcsn,Oblig0)XACMLPolicy(Target(S,R,A,E),Rules(S,R,A,E),Oblig0)1012345678911121314151617181920 Resource SiteSite Central AuthZService (SCAS) ServReq(Srv,Oblig2)Rsr Environm,state Figure 2. Generic Authorisation dataflow and Obligations handling in distributed AuthZ service. 4  For the general (stateful) obligations handling process wecan distinguish the following stages (note: not all stages arenecessary to be implemented in a simple use case but they mayexist in different cases): Obligation0 = tObligation =>=> Obligation1 (“OK?”, (Attributes1 V Environment1)) =>=> Obligation2 (“OK?”, (Attributes2 V Environment2)) =>=> Obligation3 (Attributes3 V Environment3) 1) Obligation0 (stateless) - obligations are returned by thePDP in a form as they are written in the policy. Theseobligations can be also considered as a kind of templates or instructions, tObligation. (Important to mention that due tosecurity reason obligations format and semantics should notuse executable code or reference to locally executed commands).2) Obligation1   or    Obligation2 – obligations have beenhandled by the obligation handler at the SCAS/PDP side and/or at the PEP side correspondingly, depending on implementation.In this case templates or instructions of the Obligation0 arereplaced with the real attributes in Obligation1, e.g. in a formof “name-value” pair. During this stage, the obligation handler can actually enforce obligations or modify obligations and send them further for enforcement by the resource. IntroducingObligation1 and Obligation2 handling stages gives flexibilityto the proposed model as in many cases of the remote PEP and PDP location both sides may not have necessary informationfor the full obligations enforcement.The result of obligations processing/enforcement, can bereturned in a form of modified AuthzResponse (Obligation1) or in a form of global resource environment changes that will betaken into account at the time when the requested service/resource are provided or delivered. In both cases (and specifically in the last case) obligation handler should returnnotification about fulfilled obligated actions, e.g. in a form of Boolean value “False” or “True”, which will be taken intoaccount by PEP or other processing module to finally permit or deny service request by PEP.3) Obligation3 – this is the final stage when obligationsactually take effect, which can be defined as obligations“termination”. This is done by the resource itself or by trusted services managed/controlled by the resource.In the proposed model, option with Obligation1 handlingstage at the SCAS or PDP side is introduced to illustrate a casewhen we need to implement a stateful PDP/SCAS. This isachieved by adding obligations handling functionality to theContext Handler module which functionality is defined flexiblyin the XACML specification.One of the important aspects of the general obligationshandling model is not discussed here, namely logical or timewise sequence of enforcing obligations. The solution was proposed at Open Grid Forum (OGF) OGSA AuthorisationWorking Group (AUTHZ-WG) [9] to add special Chronicleattribute to the Obligation element in XACML, but this ideahas not been further discussed.   5. Implementation suggestions The proposed OHRM is a result of the extended discussionat the joint Authorisation interoperability working group(AUTHZ-INTEROP WG) [10] between the major Grid consortia EGEE in Europe and Open Science Grid (OSG) inUS with participation of the Globus Toolkit development team.AUTHZ-INTEROP WG identified common attributes used for AuthZ in Grid and major types of obligations that arerequired in many Grid applications. All this is summarised inthe document “An XACML Attribute and Obligation Profilefor Authorization Interoperability in Grids” [11]. The attributesand obligations profile provides a basis for interoperability between potentially different AuthZ service implementationsand can be used as a basis for defining new profiles, in particular for network resource provisioning.Implementation of the proposed OHRM is based on theSAML 2.0 Profile of XACML 2.0 [12] that specifiesextensions to the SAML 2.0 assertions and protocol [13] tosupport communication between XACML PEP and PDP. Thisis considered as another important component to achieveinteroperability between different AuthZ frameworks in thedistributed AuthZ infrastructure that not necessary useXACML policy language. 5.1. SAML-XACML Library Initial implementation of the SAML-XACML library asextension to the OpenSAML2.0 library has been done in theframework of the GAAA-AuthZ Toolkits project [14, 15] and currently being contributed to the OpenSAML project [16].The library is intended to be used with the Globus AuthZFramework (GT-AuthZ) [17].The SAML-XACML library allows plugging in multipleObligationHandlers that support different types of obligations(that are identified by ObligationId) and can be called either from the PEP or from the SAML-XACML interface modulesthat handle request/response messages. 5.2. Obligations expression convention Obligations expression in XACML can be described by thefollowing general Obligation term: Obligation = Apply (TargetAttribute,Operation (Variables)), or  Obligation = Apply (TargetAttribute,Operation (Variables), Chronicle) Below example is provided only for illustration how accountmapping obligation can be expressed in the XACML2.0compliant format. Obligation type is identified by ObligationId attribute which value for this example contains value“map.poolaccount” that can used to call out to a designated ObligationHandler. (Note, the example uses a dedicated to the project namespace “http://authz-interop.org/xacml”). <!-- Obligations format option 1 (UID, GID explicitlymentioned as separate XML elements insideAttributeAssignment element) --><Obligations><Obligation ObligationId="http://authz-interop.org/xacml/obligation/map.poolaccount" FulfillOn="Permit"> <!-- This part specifies to what kind of attribute thenext ‘map.to’ action is applied to --><AttributeAssignmentAttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute: requesting-subject"DataType="http://www.w3.org/2001/XMLSchema#string">&lt;SubjectAttributeDesignator  AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id  "DataType="http://www.w3.org/2001/XMLSchema#string"/&gt;</AttributeAssignment> <!-- This is actual account attribute name/value towhich it should be mapped --> 5
Search Related
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks