Domain Based Access Control Model for Distributed Collaborative Applications

Please download to get full document.

View again

of 8
6 views
PDF
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
Domain Based Access Control Model for Distributed Collaborative Applications
Document Share
Document Tags
Document Transcript
   1   Domain Based Access Control Model for Distributed CollaborativeApplications Yuri Demchenko University of Amsterdam   demch@science.uva.nl   Leon Gommans University of Amsterdam   lgommans@science.uva.nl   Cees de Laat University of Amsterdam   delaat@science.uva.nl  Rene van Buuren Telematica Instituut  Rene.vanBuuren@telin.nl    ABSTRACT This paper describes the design and development of a flexible domain-based access control infrastructure for distributed Collaborative Environments. The paper  proposes extensions to classical RBAC models to addresstypical problems and tasks in the distributed hierarchical resource organisation that came from the practical experience in developing industry oriented virtual laboratories infrastructure. The proposed extensions/solutions address the following problems:hierarchical resources policy administration, user roles/attributes management, dynamic security context and authorisation session management, and others. The paper provides implementation details on the use of  XACML for fine-grained access control policy definition for domain based resources and roles organisation.Special attention is given to practical implementation of the authorisation session management as a keycomponent of the distributed hierarchical access control infrastructure. The paper analyses the required  functionality and suggests extensions to the major  service-oriented access generic framework such as Acegi,Globus Toolkit Authorisation framework, and GAAA Authorisation framework in order to support complexresource organisation and collaboration scenarios indynamic virtualised environments. The paper is based onexperiences gained from the industry funded project Collaboratory.nl and other major Grid-based and Grid-oriented projects in collaborative applications and complex resource provisioning. KEYWORDS: Open Collaborative Environment,Domain based security model, RBAC, SAML, XACML,Security context management. 1.   INTRODUCTION The process industry makes extensive use of advancedlaboratory equipment, such as electron microscopes,equipment for surface analysis and mass spectrometers.Due to the high initial outlay and operational costs, andthe expertise required to operate the equipment,laboratories tend not to have all this equipment in-house.On other side the equipment owners increasingly consider  providing access to their resources to remote collaborativegroups in a form of “virtual” laboratory (VL) that usesmodern ICT infrastructures and Internet technologies.Such a VL can offer the same possibilities as a traditionallaboratory, but also enables laboratory staff to utilise theequipment and expertise of third parties.In industrial environment, management and assuranceissues are paramount. They must be supported bycorresponding security infrastructure that should providesecure instruments access and reliable service delivery,and also allow hierarchical administration and minimum privileges assignment.Emerging Computer Grid and Web Services [1, 2]technologies provide a good basis/platform for buildingsuch an open Service-Oriented CollaborativeEnvironment (SOCE) that allows dynamic association of resources and users into virtual organisations or laboratories. Such a virtualisation of resources and userscan be created dynamically, based on experiment (or  business) agreements and terminated once the experimenthas been completed.Grid middleware, been developed in the framework of large inter national projects such as EGEE 1 and GlobusAlliance 2 , provides a common communication/messaginginfrastructure for all resources and services exposed asGrid services, and also allows for a uniform securityconfiguration at the service container or messaging level. 1 http://public.eu-egee.org/ 2 http://www.globus.org/    It has reached a production level of maturity, but it stillremains primary focused on computational resources andtasks management.This significantly simplifies development of SOCEapplications and allows developers to focus onapplication-level logic such as providing advanced business process management and the delivery of complex domain-specific applications.This paper describes our experiences when developinga flexible, customer-driven, security infrastructure for aSOCE. It proposes a domain-based security model toaddress specific and common problems whenimplementing Service Oriented Architecture (SOA) andGrid technologies in the industrial collaborativeenvironment. It continues with further development of theExperiment-centric customer driven security model for Open Collaborative Environment proposed in [3, 4] and being develo ped in the framework of theCollaboratory.nl 3 project (CNL) that investigates howtechnologies for remote operation of laboratoryequipment can be integrated with existing GroupWare for enhanced remote collaboration.The paper is organized as follows. Section 2 describestypical VL organisations between cooperating enterprises provides justification for the domain-based securitymodel (DM). It also provides suggestion on the practicalimplementation in SOCE and discusses benefits. Section3 discusses what functionality is currently available inknown Role-based Access Control (RBAC)implementations and identifies extensions to addressspecifics in controlling access to distributed hierarchicalresources in DM. Section 4 goes deeper into authorisationservice operation in a typical SOCE and identifiesmechanisms to express and convey DM dynamic securitycontext. Section 6 discusses what functionality should beadded to existing authorisation frameworks to supportdomain related security context handling. Section 6 provides practical suggestions and an example of usingXACML for policy expression in DM.The proposed approach and solutions respond to bothcommon and business domain-specific requirements of Collaboratory.nl, and are based on current experience inthe EGEE project. The proposed approach and solutionscan also be used for other use cases that requiredistributed, dynamically invoked and managed accesscontrol infrastructure using Grid and Web Servicesmiddleware. 2.   DOMAIN BASED RESOURCEMANAGEMENT AND SECURITYSERVICES VL provides a flexible framework for associatinginstruments, resources and users into distributed 3 http://www.collaboratory.nl/ interactive cooperative/collaborative environment.However, committed to the VL resource still remain inthe possession and under direct administration of their srcinal owner enterprises.The following administrative and security domainscan be defined for user, resources, policy and trustmanagement:1) Facility – provides administrative/legal platform for all further operational associations; may define what kindof technologies, formats, credentials can be used.2) Virtual Laboratory (VL) – similar to VirtualOrganisation (VO) in Grids. VL can be created on the basis of the VL agreement that defines VL resources,common services (first of all, information/registry andsecurity), administrative structure and VL administrator.Trust relations can be established via PKI and/or VLCertificate population.3) Experiment/project is defined together with the VLresources allocation, members, task/goals, stages, andadditionally workflow. It is perceived that experimentrelated context may change during its lifetime.4) Experiment session that may include multipleInstrument sessions and Collaborative sessions thatinvolves experiment members into interactions.5) Collaborative session – user interactive session.In the above provided classification domains aredefined by common policy under single administration,common namespace and semantics, shared trust, etc. Inthis case, domain related security context may include:namespace aware names and ID’s, policy references/ID’s,trust anchors, authority references, and alsodynamic/session related context.As a dynamic entity or dynamic security association,Experiment session must be supported by the AuthZsession that is based on the positive AuthZ decision, with possible obligations and conditions. Dynamic character of the Experiment/AuthZ sessions allows also delegation of user rights/permissions and must be supported by AuthZ(session) tickets/credentials.Proposed in [3, 4] and implemented at the CNL project Demo stage the Experiment-centric securitymodel provides a good solution for centrally managedresources and user engaged into the Experiment butdoesn’t reflect real hierarchical and multidomainResource management model in typical industrialenvironment. Without including these administrativelevels into the resource and security management model,their management will remain manual work and will beresulted in slow adaptation of the working space, a highadministrative overhead and overly complexmanagement.The Domain-based resource management model (DM)closer reflects business practice among cooperatingenterprises contributing their resources (instruments,other facilities and operator personal) to create a Virtuallaboratory that can run complex experiments on requestfrom customers. To become consistent the DM should be   3   supported by corresponding organisation of the accesscontrol infrastructure.Figure 1 below illustrates relations between major hierarchical components in the DM resource managementand security model. The following suggestions were usedwhen creating this abstraction of the DM:1) physically Instruments are located at the Facility but logically they are assigned to the VL and nextallocation to the Experiment. Full context Instrumentname will look like: CNL:Facility:VirtualLab:Experiment:InstrModel 2) users/members of collaborative sessions areassigned to the Experiment, managerial and operator  personnel belongs to VL and Facility and may havespecific and limited functions in the Experiment;3) particularly, domain based restrictions/policy can be applied to (dynamic) role assignment;3) additionally, administrative rights/functions can bedelegated by the superior entity/role in this hierarchicalstructure;5) Trust Anchors (TA) can be assigned to hierarchicaldomain related entities to enable security associations andsupport secure communication. VL TA1 is suggested asminimum required in DM, Experiment TA2 may beincluded into the Experiment description. Collaborativesession security association can be supported by AuthZtickets. VirtualLaboratory(TA1)Facility(TA0)Experiment(Project)TA2ExperimentSession(AuthzTicket)InstrumentSessionUser/DelegateSessionInstrument InstrumentInstrumentUsers(attrs/roles)CollabSessionSecurityCtx(AuthzTicket)Admin Admin AdminPolicy/Restr. Policy/Restr.Policy/Restr.Users(attrs/roles) Figure 1. Domain based Resource management inSOCE The Experiment description plays an important role inthe DM security infrastructure, it is created by theexperiment owner as a semantic object on the basis of asigned Experiment agreement (and in the context of theoverall VL agreement). It contains all the informationrequired to run the analysis, including the Experiment ID,assigned users and roles, and a trust/security anchor(s) inthe form of the resource and, additionally, the customer’sdigital signature. The experiment description is used to provide experiment-dependent configuration data for other services to run the experiment and manage thedynamic security context. The Experiment descriptionmay also specify a workflow to orchestrate allinteractions between experiment components/services and provide a solution for dynamic security contextmanagement as it is discussed in [5].DM provides the following benefits:1) reflects distributed hierarchical management modelnatural in distributed cooperative business environment;2) multiple and hierarchical policies management thatreflects hierarchical resource organisation;3) allows for dynamic roles assignment with thedomain defined restrictions;4) supports dynamic security context management;5) provides mechanisms for supporting multidomainauthorisation sessions. 3.   EXTENDING RBAC MODEL WITHDOMAIN BASED SECURITYCONTEXT MANAGEMENT Fine-grained access control in typically interactivecollaborative environment can be achieved using RBACauthorisation model, which generally consists of major functional components that include: Policy EnforcementPoint (PEP), Policy Decision Point (PDP), PolicyAuthority Point (PAP) [6]. In RBAC, user/requestor access rights are defined by roles in a form of user attributes and a separately managed access control policycontains rules that define what roles are allowed to dowhat actions on the resource.Generic RBAC model [6, 7] provides an industryrecognised solution for effective user roles/privilegesmanagement and policy based access control. Manystudies suggest RBAC as a natural method to model thesecurity requirements in collaborative environment but atthe same time they argue for application specificextensions, e.g., for user group organisation includingadditional group/team defined restrictions on separationof duties, roles/attributes combinations, etc. [8, 9].Practical RBAC implementation requires resolution of many other administration and security related issues leftout of scope in classical RBAC such as:- policy expression and management,- roles management and separation of duties,- rights/privileges delegation,- AuthZ session management mechanisms,- security context management in dynamic scenario.Two basic implementations of the generic RBACmodel are Access Control Lists (ACL) that can be rather applications/implementation specific, and an emergingindustry standard eXtensible Access Control MarkupLanguage (XACML) that defines a rich policy expressionformat and simple Request/Response messages format for PEP-PDP communication [10]. XACML extensions andspecial profiles address most of mentioned above issues atthe standard level. However, there are no widely used practical implementations for this new functionality.The papers [11, 12] proposes an extension of thegeneric RBAC model the usage control (UCON) based    authorisation framework for collaborative application thatspecifically addresses access control to the consumableresources or which access should be coordinated among agroup of users. This is achieved by using obligations,resource/environmental conditions, introducing mutableresource and user attributes, and applying ongoingcontrol. The proposed implementation uses XACML as a policy expression language with proprietary defined theObligation element. However, detailed analysis of the proposed UCON publications and implementationsreveals that the UCON framework uses centralised policymanagement, environment and attributes control that mayhave a principal problem of races when usingconditions/obligations on mutable attributes. Proposedusage session doesn’t allow full functionality required for generic authorisation session management in a multi-domain environment.When combining with the RBAC, the RBAC-DM(note, in most cases we will use abbreviations DM andRBAC-DM as equivalents) will intend to address most of above mentioned issues at the practical level byintroducing domain related security context that actuallyreflects natural for cooperating entities/enterprisesadministration model and separation of duties. Use of Experiment and Collaborative session allows toimplement delegations and minimum privileges principlein access control management but in its own turn requiresconsistent authorisation session context handling. 4.   AUTHORISATION SERVICEOPERATION IN SOCE In a SOCE, security services can be dynamically bound to main services at the service messaging level.This allows independent development but impose newrequirements to the security services design: •   Orthogonal to basic services, e.g. achieved by providing generic security services and API’s •   dynamically configurable both with structuralcomponents and environment context •   flexible security context management byseparating security context from functionalcomponents and enabling dynamic servicesinvocation •   capable of scaling over multiple security andadministrative domainsA Resource or Service in SOCE is protected by siteaccess control system that relies on both Authentication(AuthN) of the user and/or request message andAuthorisation (AuthZ) that applies access control policiesagainst the service request. It is essential in a service-oriented model that AuthN credentials are presented as asecurity context in the AuthZ request and that they can beevaluated by calling back to the AuthN service and/or Attribute Authority (AttrAuth). This also allows loosecoupling of services (allowing domain independency evenfor hierarchical DM).The Requestor requests a service by sending a servicerequest ServReq to the Resource’s PEP providing asmuch (or as little) information about theSubject/Requestor, Resource, Action as it decidesnecessary according to the implemented authorisationmodel and (should be known) service access control policies.In a simple scenario, the PEP sends the decisionrequest to the (designated) PDP and after receiving a positive PDP decision relays a service request to theResource. The PDP identifies the applicable policy or  policy set and retrieves them from the Policy Authority,collects the required context information and evaluatesthe request against the policy.In order to optimise performance of the distributedaccess control infrastructure, the Authorisation servicemay also issue authorisation tickets (AuthzTicket) thatconfirm access rights. They are based on a positivedecision from the Authorisation system and can be usedto grant access to subsequent similar requests that matchan AuthzTicket. To be consistent, AuthzTicket must preserve the full context of the authorisation decision,including the AuthN context/assertion and policyreference.A typical DM access control use-case may require acombination of multiple policies and also multi-levelaccess control enforcement, which may take place whencombining newly-developed and legacy access controlsystems into one integrated access control solution. TheSOCE experiments may apply different policies andrequire different user credentials depending on the stageof the experiment.DM can improve overall services manageability butrequires additional/corresponding mechanisms for dynamic security context management. It is alsosuggested that using AuthZ ticket with full sessioncontext will simplify distributed access controlmanagement in a hierarchical DM and allow for decoupling access control infrastructure components in adistributed environment.Detailed analysis of how dynamic security context can be managed in SOA/Grid is discussed in the recent paper [5]. The following mechanisms and tools of the generalaccess control infrastructure can be used to mediate adynamic security context: •   Service and requestor/user ID/DN format that shouldallow for both using namespaces and context awarenames semantics. •   Attribute format (either X.509/X.521 or URN/SAML2.0 presentation). •   Context aware XACML policy definition using theEnvironment element of the policy Target element(see section 5 for detailed discussion).   5   •   Security tickets and tokens used for AuthZ sessionmanagement and for provisioned resource/serviceidentification. In both cases security tickets shouldcontain the full security context and be supported byrelated AuthZ and provisioning infrastructure. •   Dynamic VO membership credentials (practically can be supported by existing VO management tools – see[13] for details) or other user and services federations. •   Workflow as primarily used for complex/combinedservices orchestration can be also used for managingdynamic security context.Most of mentioned above mechanisms are available incomplementary XML-based formats Security AssertionMarkup Language (SAML) [14] and XACML [10] thatare used for security assertion and access control policyexpression. 5.   ADDING WIDER SECURITYCONTEXT MANAGEMENT TOMAJOR AUTHZ FRAMEWORKS To provide described above functionality on domain based security context handling, a number of featuresshould be added to existing AuthZ frameworks such asAcegi Security [15], Globus Toolkit 4.0 AuthZFramework (GT4-AuthZ) [16], gLite Java AuthorisationFramework (gJAF) [17]. They are currently beingdeveloped as pluggable modules to a special GAAA-RBAC profile of the generic Authentication,Authorisation, Accounting (GAAA) AuthorisationFramework (GAAA-AuthZ) [18, 19].Acegi Security is industry recognised security solutionwith a particular emphasis on applications using Springframework for J2EE (http://www.springframework.org/).It provides channel security, reach authentication andSingle Sign-On (SSO) functionality, and also domainobject authorization using Access Control List (ACL).Similar to GT4-AuthZ and gJAF, Acegi security servicescan be called from the main services using service andapplication specific filters.GT4 Authorization Frameworks (GT4-AuthZ) is acomponent of the widely used Grid middleware that provides general and specific functionality to controlaccess to Grid applications and resources using accesscontrol policies in Grid-specific formats, such as AccessControl Lists (ACLs), gridmap file, identity or host based,and also providing external policy evaluation calloutsusing OGSA Authorization PortType that uses SAML asa messaging format. A simple XACML-based PDP is also provided.gLite Java Authorisation Framework (gJAF) is acomponent of the gLite security middleware. It inheritscompatibility with the early versions of the GT4-AuthZthat should ensure their future interoperability andcommon use of possible application specific modules.Both the GT4-AuthZ and gJAF services can be calledfrom the SOAP based Grid services by configuring theinterceptor module which operates in this case as a virtualPEP module together with the chain.Similarity in interaction with the main services andapplications provides a good basis for developing commonmodules/library to support dynamic andresource/application domain related context.Figure 2 shows the GAAA-RBAC structure thatcontains the following functional components provided asa GAAAPI package to support all the necessary securitycontext processing and communication between a PEPand a PDP: •   A Context Handler (CtxHandler) that calls to anamespace resolver (NS Resolver) and attributeresolver (AttrResolver), which in its own can call toexternal Attribute Authority Service (AAS) tovalidate presented attributes or obtain new ones. •   A Policy Information Point (PIP) that providesresolution and call-outs to related authoritative PolicyAuthority Points (PAP); •   Triage and Cache functionality that provides aninitial evaluation of the request, including the validityof the provided credentials. This functionality is usedfor handling AuthZ tickets/tokens and also for AuthZsession management by evaluating service requestsversus the provided AuthZ ticket/token claims; •   A Ticket Authority (TickAuth) generates andvalidates AuthZ tickets or tokens on the requestsfrom PEP or PDP; to support AuthZ session ticketsare cached directly by TickAuth or by PEP/PDP.To support dynamic security context changes, theGAAAPI provides an advanced configurationmanagement capability, based on the generic AuthZservice operational model. In particular, when the PEPfunction is invoked, during AuthZ request processing, it isdynamically configured with context aware modules NSResolver, Triage, TickAuth, and TrustDMngr.When providing access control during a multi-stageexperiment, the security context (e.g., the policies, teammembers and/or roles) may change. Such changes may becontrolled in the experiment workflow and fed into accesscontrol system via an advanced configurationmanagement interface to GAAAPI modules.An AuthzTicket is generated as the result of a positivePDP decision. It contains the decision and all necessaryinformation to identify the requested service. When presented to the PEP, its validity can be verified and inthe case of a positive result, access will be grantedwithout requesting a new PDP decision. Such a specificfunctionality is provided in the GAAAPI package withthe Triage module.The current GAAAPI implementation supports bothSAML-based and proprietary XML-based AuthzTicketformats.
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