Authorisation session management in on-demand resource provisioning in collaborative applications

Please download to get full document.

View again

of 8
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
Authorisation session management in on-demand resource provisioning in collaborative applications
Document Share
Document Tags
Document Transcript
  Authorisation Session Management in On-Demand Resource Provisioning inCollaborative Applications Yuri Demchenko, Cees de Laat, Thierry Denys, Christian Toinard  University of Amsterdam, ENSI de Bourges{demch, delaat}{thierry.denys, christian.toinard}  ABSTRACT  Effective use of the resources in modern collaborativeenvironment suggests their sharing betweencollaborating organisations and user groups and on-demand provisioning for the specific tasks and projectsthat may involve distributed resources and users fromdifferent administrative and security domains. The proposed in earlier authors’ work the general Complex Resource Provisioning (CRP) model provides a basis for developing the Authorisation (AuthZ) infrastructure for on-demand multidomain resource provisioning. This paper discusses such important issues as managingauthorisation session and security context inmultidomain CRP and security mechanisms used for this.The use of AuthZ tokens for AuthZ session management in multidomain network resource provisioning isconsidered as a particular case for the general CRP. It  provides information about practical implementation of  AuthZ session management functionality in the GAAAToolkit library being developed in the framework of thePhosphorus project. KEYWORDS: Generic Authentication, Authorizationand Accounting, Complex Resource Provisioning, AAAAuthorisation Framework, Authorisation session,Authorisation Ticket, Pilot Token, Token ValidationService. 1.   INTRODUCTION The modern collaborative environment may includemultiple resources (such as data repositories, scientificinstruments, analytical and image scanning equipment,object and process controlling systems, visualisationsystems, user terminals, and data processing centers) and connecting them networking infrastructure. To achieveeffective management and use of such collaborativeenvironment, all the resources should be provisioned on-demand and support dynamic security associations thatmay include both resources and users. Existing Grid technologies can provide a framework for creating project oriented collaborative environments in a form of the Virtual Organisations (VO) which however haverather static character and doesn’t solve a problem of more dynamic on-demand resource provisioning [1].The general Complex Resource Provisioning (CRP) was proposed in earlier authors’ works [2] to address on-demand resources provisioning issues. It was successfullyused for developing AuthZ infrastructure for Grid and network resources provisioning in the framework of thePhosphorus project [3]. The proposed infrastructuresupports all stages of the CRP process/lifecycle in aconsistent way that first of all requires flexible provisioning and user access control sessionsmanagement.In this paper we summarise our recent developments and discuss the proposed mechanisms such as AuthZ ticketsand tokens that allow supporting authorisation sessionand security context management in multidomain CRP.The paper is organized as follows. Section 2 provides astate of the art about using the policy languages such aseXtensible Access Control Markup Language (XACML)for expressing authorisation policies in Grid based applications and Security Assertion Markup Language(SAML) for expressing authentication and authorisationassertions. It shows that multi-domain authorisationissues including AuthZ session management are poorlyaddressed. Section 3 updates on the general CRP modeland summarises general requirements for AuthZ sessionmanagement capabilities to support the whole CRP process. Section 4 analyses different types of AuthZsessions typically present in CRP systems: provisioningsession and access session. This section introduces AuthZtokens and tickets used as session credentials and access  credentials. Section 5 provides information about thegeneral AuthZ token format and defines different accessand pilot types. Section 6 explains in details the processof the AuthZ context communication during multidomainnetwork resource reservation using pilot tokens. Section 7 provides information about the GAAA Toolkitimplementation to support the suggested functionality for AuthZ tickets and tokens handling during the resourcereservation and access, including tokens generation,validation and relaying. 2.   STATE OF THE ART Several works discuss issues related to using suchsecurity languages as XACML and SAMLcorrespondingly for expressing authorisation policies or expressing authentication and authorisation assertionsthat can be used for Single-Sign-On or as access controlsession credentials. The majority of the works consider authentication across a single organisation or insidesingle trust domain or federation. Other works consider how to enforce protection models using XACML, how tomanage the update of the policy or how to combineseveral policies. Finally, recent state of art studies showsthat authorization for distributed systems and applications, which examples are Grid and collaborativesystems, is really poorly addressed and does not consider multiple organizations sharing a large range of Grid resources. Below we briefly refer to some particular works and papers.The paper [4] discusses security and privacy issues withauthentication of individuals in Web Services using a ringsignature. It uses SAML but does not consider authorization. The paper [5] analyses applicability of XACML to enforce the classical access control modelssuch as Bell-LaPadula; Biba or Chinese Wall. They donot consider a larger range of protection models and donot address multi-domain issues. Other works addressdifferent issues related to expressing and managingXACML based policies, in particular, [6] describes anRBAC implementation using XACML; [7] discusses howto update XACML policies; and [8] analyses policy rulesconflict resolution when merging XACML policies.However, all mentioned above works do not addressspecific access control issues in distributed Grid systemsthat involve multiple domains. The authors in [9] providea state of the art study of security for the Grid infrastructures. They found several works related withauthorization decision-making for multiple users and resources but none of them includes the notion of domain. Finally, Single Sign On (SSO) across multipledomains can be found in the literature but in most casesthe proposed solutions are oriented on web-based applications and using web browser as a user client, theyuse browser cookies for access session management butdon’t deal with authorization [10, 11]. 3.   CRP OPERATIONAL MODELS ANDMULTIDOMAIN AUTHORISATIONARCHITECTURE The two major use cases for the general CRP are on-demand network resource provisioning (NRP) [12] and Grid-based Collaborative Environments (GCE) [13].Although different in current implementations, they can be abstracted to the same CRP operational model whenconsidering their implementation with the Grid or WebServices. This abstraction is considered as an importantstep to provide a common basis to define a commonaccess control infrastructure for dedicated opticalnetworks and Grid brokered networks.The typical on-demand resource provisioning processincludes four major stages, as follows:(1) resource reservation(2) deployment (or activation)(3) resource access/consumption, and additionally(4) resource de-commissioning after it was used.In its own turn, the reservation stage (1) typicallyincludes three basic steps: •   resource lookup, •   complex resource composition (includingalternatives), and  •   reservation of individual resources includingauthorisation of the reservation request.The reservation stage may require the execution of complex procedures that may also request individualresources authorisation. This process can be controlled byan advance reservation system [14] or a meta-schedulingsystem [15] and is driven by the provisioning workflowand related authorization (AuthZ) policy. At thedeployment stage, the reserved resources are bound to areservation ID, which we refer as the Global ReservationIdentifier (GRI). The decommissioning stage isconsidered as an important stage in the whole resource provisioning workflow from the provider point of viewand should include such important actions as global provisioning/access session termination and user/processlogout, log information sealing, accounting and billing.The rationale behind defining different CRP workflowstages is that they may require and can use differentsecurity models for policy enforcement, trust and securitycontext management, but still may need to use commondynamic security context.  In the discussed CRP model, domains are defined (asassociations of entities) by a common policy or a singleadministration, with common namespaces and semantics,shared trust, etc. In this case, the domain related securitycontext may include: •   static security context [16] such as domain based  policy authority reference, trust anchors, all bound  by the domain ID and/or domain trust anchor; •   dynamic or session security contexts bound to theGRI and optionally to a Local Reservation ID (LRI).In general, domains can be hierarchical, flat or organized in the mesh, but all these cases require the same basicfunctionality for the access control infrastructure tomanage domain and session related security contexts. Inthe remainder of the document, we will refer to thetypical use case of the network domains that areconnected as chain (sequentially) providing connectivity between a user and an application.Figure 1 illustrates major interacting components in themulti-domain on-demand NRP: •   A User/Requestor (represented by User client). •   A Destination end service or application. •   Multiple Network Elements (NE) (related to the Network plane). •    Network Resource Provisioning Systems (NRPS)acting as a Domain Controller (DC). •   Inter-Domain Controller (IDC) and AAA servicecontrolling access to the domain- related resources. •   Policy Enforcement Point (PEP), Policy DecisionPoint (PDP), and Policy Authority Point (PAP) asmajor functional components of the AuthZinfrastructure. •   Token Validation Services (TVS) that handlesAuthZ tokens used as AuthZ session credentialsduring reservation and access stages. Figure 1. Components Involved in MultidomainNetwork Resource Provisioning and Basic Sequences(Agent (A), Chain (C), and Polling (P)) The above described CRP model can be generalized for another typical CRP use case of the GCE if we consider collaborative applications as separate resource domainsthat can be logically organised into different structuresand described with the similar set of attributes astraditional network domains. Following [2, 17], in theremainder of this document we will refer to the AuthZinfrastructure described above as GAAA-NRP.Managing AuthZ session context during the reservationstage is essential to ensure consistent resource protectionand effective decision making. At the serviceaccess/consumption stage the reserved resource may besimply identified by the assigned GRI created as a resultof the successful reservation request authorisation.It is an important convention for the consistent CRPoperation that GRI is created at the beginning and sent toall polled/requested domains when running (advance)reservation process. Then in case of a confirmed reservation, the DC/NRPS will store the GRI and bind itto the committed resources. In addition, a domain canalso associate internally the GRI with the LRI. 4.   AUTHZ SESSION MANAGEMENTWITH AUTHZ TICKETS ANDTOKENS There are two types of sessions in the proposed CRPmodel that require a security context management:reservation session, and the reserved resource accesssession. Although the provisioning session may requirewider security context support, both of them are based onthe (positive) AuthZ decision, may have a similar AuthZcontext and will require a similar functionality whenconsidering distributed multi-domain scenarios. Figure 2illustrates relationship between provisioning AuthZsession that spans all CRP stages and resource or application access session which starts at the accessstage. It is essential that both of these sessions share thesame GRI created at the beginning when the resourcerequest has been authorised. ReservationDeployment Access/Use DecommissioningAccessSessionProvisioning session Figure 2. CRP Stages and Session Types. We distinguish two types of the AuthZ sessioncredentials: IDC/AAAPEP   User Client   DC/NRPS  NE PEP   PEP   AgentP   R    A   Service(AAA)laneControl plane DestHostAppli-cation  Network  plane AAAPAP   PDP   TVSTVS   TVS   DC/NRPS   DC/NRPS   IDC/AAAPAP   PDP   IDC/AAAPAP   PDP    NE NE  •   AuthZ tickets that should allow for expressing and communicating the full AuthZ session context and inthis way could be used as access credentials •   AuthZ tokens that should provide more flexiblefunctionality for managing the AuthZ session and thewhole provisioning process.We will discuss in detail the use of AuthZ tokens duringmultidomain network resources reservation and will refer to the detailed AuthZ ticket format and functionalitydescription given in [16]. 5.   AUTHZ TOKEN DATAMODEL ANDTOKEN TYPES In the proposed AuthZ architecture the tokens are used for access control and signalling at different CRP stagesand considered as a flexible and powerful mechanism for communicating and signalling security context betweendomains.The token is defined as an abstract reference to thereservation or the AuthZ session context in domainsusing an abstract shared token meaning/context that isreferenced by the token attributes. Tokens can be used for  both access control when accessing the reserved resources and for signalling during reservation and deployment stages. Correspondingly we distinguish thetwo major types of token in the GAAA-NRP architecture:access tokens and pilot tokens. Access tokens are used inrather traditional manner and described in details in [12].Pilot tokens functionality and format were proposed and defined as the current development result of the AuthZinfrastructure as an integral component of the NRPinfrastructure. Figure 3 illustrates the common datamodel of both access tokens and pilot tokens. Althoughthe tokens share a common data-model, they are differentin the operational model and in the way they aregenerated and processed. When processed by AuthZservice components they can be distinguished by the presence or value of the token type attribute which isoptional for access token and mandatory for pilot token.Access tokens used in GAAA-NRP have a simple formatand contain three mandatory elements: the SessionId attribute that holds the GRI, the TokenId attribute thatholds a unique token ID attribute and is used for tokenidentification and authentication, and the TokenValueelement, and two optional elements: the Conditionelement that may contain two time validity attributesnotBefore and notOnOrAfter, and the Decision elementthat holds two attributes ResourceId and Result, and optional element Obligations that may hold policyobligations returned by the PDP. Figure 3. Authorisation Token Data Model. The GAAA-CRP architecture defines four types of pilottokens that have different profiles of the common datamodel and different processing/handling procedure:Type1 – this pilot token type is used just as acontainer for communicating the GRI during thereservation stage. It contains the mandatory SessionId attribute and an optional Condition element (it does notcontain a TokenValue element).Type2 – this pilot token type is the srcin/requestor authenticating token. Its TokenValue element contains avalue that can be used as the authentication value for thetoken srcin. The token value is calculated on the GRI byapplying e.g. an HMAC function to the GRI together with the requestor symmetric secret or private key.Type3 – this pilot token type extends the Type2 withan element, including multiple Domains, that allows tocollect the Security Contexts (SecCtx) related to thosedomains when passing multiple domains during the  reservation process. Such information includes the previous token and the domain’s trust anchor or publickey.Type4 – this pilot token type is used at thedeployment stage and can communicate, between theSecCtx of the crossed domains, about all participating inthe provisioned lightpath or network infrastructureresources. This token type can be used for  programming/setting up a TVS infrastructure for consistent access control tokens processing at theresource access stage.   When used together with anAuthzTicket the ticket and token identification elementsTokenId/TicketId, SessionId, and Issuer can be shared. 6.   HANDLING INTERDOMAINSECURITY CONTEXT DURINGRESOURCE PROVISIONING 6.1.   Interdomain AuthZ/Security ContextCommunication with the Pilot Tokens During a multidomain network resource reservation, the pilot token goes from the requestor to the resource throwseveral domains. In order to collect the previous domainsAuthZ and security context, the content of the token willchange. The first token is created as a result of positiveauthorisation and a confirmed reservation in the firstdomain. Typically it is the pilot token type 2 (PTT2).When the second domain confirms reservation, a new pilot token type 3 (PTT3) is created that now includes aDomainsContext element that contains a Domain elementas a child holding context information from the previousdomain. The process continues in the next domain and anew Domain element is simply added. Figure 4 providesan example of the pilot token change during amultidomain network resource reservation. The tokenissued in the current domain contains the local DomainId and the DomainsContext element holds information fromall previous domains including related tokens which arechronologically ordered.The next Figure 5 shows an XML pilot token from theexample above with two domains: “viola” and “uva”.Thisfigure shows the different information related to “viola”and “uva”, some conditions (notBefore and  NotOnOrAfter) and different elements as explained withFigure 3.This token also refer to the intermediate type 3 tokenfrom Figure 4: two domains have been passed and context information from the first domain is collected inthe DomainsContext element. Domain1“viola”ResourceRequestor Domain2“uva”Domain3“uclp” Figure 4. Structure of the Pilot Token type 3 AfterPassing Three DomainsFigure 5. XML Pilot Token with Two Domains:“viola” and “uva”. <AAA:AuthzToken xmlns:AAA=""  Issuer =  SessionId ="740b241e711ece3b128c97f990c282adcbf476bb"  TokenId ="dc58b505f9690692f7a6312912d0fb4c"  type=" pilot-type3">  <AAA:TokenValue>190a3c1554a500e912ea75a367c822c09eceaa2f  </AAA:TokenValue>  <AAA:Conditions  NotBefore="2009-01-30T08:57:40.462Z"   NotOnOrAfter ="2009-01-30T09:21:40.462Z"/>  <AAA:DomainsContext>  <AAA:DomaindomainId ="">  <AAA:AuthzToken Issuer =""  SessionId ="2515ab7803a86397f3d60c670d199010aa96cb51"  TokenId ="c44a2f5f70346fdc2a2244fecbcdd244">  <AAA:TokenValue>dee1c29719b9098b361cab4cfcd086700ca2f414 </AAA:TokenValue>  <AAA:Conditions  NotBefore="2009-01-30T07:57:35.227Z"   NotOnOrAfter ="2009-01-31T07:57:35.227Z"/>  </AAA:AuthzToken>  <AAA:KeyInfo> </AAA:KeyInfo>  </AAA:Domain>  </AAA:DomainsContext>  </AAA:AuthzToken> 
Similar documents
View more...
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