034115

PHOSPHORUS

Lambda User Controlled Infrastructure for European Research


Integrated Project

Strategic objective:
Research Networking Testbeds


Deliverable reference number: D.4.3.1


GAAA toolkit pluggable components and XACML
policy profile for ONRP



Due date of deliverable: 31-07-2008
Actual submission date: 04-08-2008
Document code: <Phosphorus-WP4-D.4.3.1>


Start date of project: Duration:
October 1, 2006 30 Months



Organisation name of lead contractor for this deliverable:
University of Amsterdam

Revision [draft, 0.4]

GAAA toolkit pluggable components and XACML policy profile for ONRP


Abstract
This deliverable describes the implementation of the generic AAA Authorisation framework (GAAA-AuthZ) for
Optical Network Resource Provisioning (GAAA-NRP profile) as the pluggable GAAA Toolkit library (GAAA-TK)
and the proposed XACML-NRP attributes and policy profile.
The report summarises recent developments and enhancements to the GAAA-NRP resulted from discussions
with the project partners and the Grid community. Some additional modifications have been done to the initially
proposed GAAA-AuthZ/GAAA-NRP architecture in the project deliverable D4.1.
The report describes the major security mechanisms and functional components that comprise the GAAA-NRP
profile such as authorisation tickets and tokens, Token Validation Service (TVS), reference model for policy
obligations handling (OHRM).
The document describes the XACML-NRP attributes and the policy profile that proposes a set of attributes to
describe a resource, a subject, and an action that are the major components of the authorisation/access control
policy definition. The XACML-NRP profile has been proposed to and was discussed within the Grid community
and it got positive feedback and useful contribution.
It is one of the design principles of the GAAA-NRP and GAAA-TK that the proposed architecture and
implementation should allow an easy integration in other network management/control frameworks and Grid
middleware that are currently used and being developed by NREN and Grid communities.
The report describes in detail a set of APIs used to call main the GAAA-TK services: authorisation service
requested via the Policy Enforcement Point (PEP) or directly to a Policy Decision Point (PDP), and the TVS API
that provides rich functionality for handling token used for access control and signalling. A special section is
devoted to the GAAA-TK library setup and configuration.
The current GAAA-TK library implementation provides full functionality needed to support basic testbed
scenarios. It has been tested with the WP1 Harmony testbed and expects integration into the WP2 G2MPLS
middleware. It is however planned that the library will be updated after feedback received from the
implementers and integrators.
Project co-funded by the European Commission within the Sixth Framework Programme (2002-2006)
Dissemination Level
PU Public
PP Restricted to other programme participants (including the Commission Services)
RE Restricted to a group specified by the consortium (including the Commission Services)
CO Confidential, only for members of the consortium (including the Commission Services)

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosphorus-WP4-M.4.1>
Document Revision History
<This page to be deleted before submission to the EC>
Version Date Description of change Person
0.0 23-07-08 Content and a template Yuri Demchenko
0.1 31-07-08 First draft released Yuri Demchenko
0.2 04-08-2008 Version 0.2 released for the internal WP4
review
Yuri Demchenko
0.3 06-08-2008 Internal review Alexander Willner
0.4 06-08-2008 Accepted internal review changes and
updated TVS interface description.
Version is released for the project review.
Yuri Demchenko

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
4


REVIEW Main reviewer N. Surname
Summary of
suggested
changes

Recommendation 1) Major revision1 2) Minor revision2
Re-submitted for
review - if 1)
DD/MM/YY
Final comments
Approved3: DD/MM/YY





1 Deliverable must be changed and reviewed again before submission to the EC can be considered
2 Deliverable may be submitted to the EC after the author has made changes to take into account reviewers'
comments as appropriate
3 For submission to EC

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosphorus-WP4-M.4.1>
Table of Contents
0 Executive Summary 7
1 Introduction 9
2 Authorisation Infrastructure for Multidomain Network Resource Provisioning (GAAA-NRP)
– General Design 11
2.1 NRP/CRP operational models and AAA Authorisation service architecture 11
2.2 GAAA-AuthZ access control mechanisms and components 14
2.3 AuthZ Ticket formats for extended AuthZ Session Management 16
2.3.1 AuthZ Ticket use in GAAA-NRP 16
2.3.2 AuthzTicket data model and schema 16
2.4 Using AuthZ Tokens for Access Control and Signalling 19
2.5 Token Validation Service (TVS) 21
2.5.1 Basic TVS Functionality 21
2.5.2 Token handling model 21
2.6 Policy Obligations and Obligations Handling Reference Model (OHRM) 22
3 XACML policy profile for OLPP/CRP 25
3.1 Access Control in NRP – Basic Use Cases 25
3.2 Network topology formats used in multi-domain NRP 26
3.2.1 Phosphorus WP1 topology definition [17] 26
3.2.2 Network Description Language (NDL) by UvA and OGF [18] 28
3.2.3 OSCARS topology description format [19] 30
3.3 XACML Policy and attributes format 31
3.4 Attributes used for Authorisation and XACML policy definition 33
3.4.1 Attributes namespace 33
3.4.2 Network or Resource related attributes 33
3.4.3 Subject related attributes 35
3.4.4 Action related attributes 36
3.4.5 Environment related attributes 37
3.4.6 Policy Obligations used in NRP 37
3.5 Policy Expression Conventions 38
3.6 Policy identification and policy resolution 39

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
6
3.6.1 General suggestions 39
3.6.2 Policy resolution convention in the GAAA-TK library 40
3.6.3 Policy identification 41
4 GAAA Toolkit Library 42
4.1 GAAA-TK library components 42
4.2 General AAA/AuthZ API and programming examples 44
4.2.1 PEP-GAAAPI interface 44
4.2.2 Simple XACML PDP API 46
4.2.3 GAAA-PEP API programming examples 46
4.2.4 Attribute expression conventions 48
4.3 TVS API 50
4.3.1 TVS interface 50
4.3.2 TVS programming examples 51
4.4 Authorisation ticket and token examples 52
4.4.1 Authorisation ticket examples 52
4.4.2 TVS XML Token format and examples 52
4.5 Simple XACML policy generation tools 54
5 GAAA-TK library Installation and configuration 55
5.1 Configuration 55
5.2 Installation 56
5.3 Required external libraries 56
6 Conclusion 58
7 References 60
Appendix A Acronyms 62
Appendix B AuthZ Ticket XML Schema and Examples 64
Appendix C AuthZ Token XML Schema 69
Appendix D XACML Policy examples 70

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
7

0 Executive Summary
The Authentication, Authorisation and Accounting (AAA) service is an important component of the supporting
infrastructure for on-demand Optical Network Resource Provisioning (ONRP) across multiple domains and
different target consumer applications. A consistent AAA infrastructure requires interactions of the related AAA
components at all networking layers including the network/forwarding elements, the control plane, the
reservation and provisioning service, and the user/target application layer.
The report summarises recent developments and enhancements to the GAAA-NRP resulted from discussions
with the project partners and the Grid community. Some additional modifications have been done to the initially
proposed GAAA-AuthZ/GAAA-NRP architecture in the project deliverable D4.1.
The report describes the major security mechanisms and functional components that comprise the GAAA-NRP
profile such as authorisation tickets and tokens, the Token Validation Service (TVS), and a reference model for
policy obligations handling (OHRM).
The document describes the XACML-NRP attributes and a policy profile that proposes a set of attributes to
describe a resource, a subject, and an action that are the major components of the authorisation/access control
policy definition. The XACML-NRP profile has been proposed to and was discussed within the Grid community
and it got positive feedback and useful contribution.
It is one of the design principles of the GAAA-NRP and GAAA-TK that the proposed architecture and
implementation should allows an easy integration in other network management/control frameworks and Grid
middleware as currently used and being developed by NRENs and Grid communities.
The report describes in detail a set of APIs used to call main GAAA-TK services: authorisation service
requested via the Policy Enforcement Point (PEP) or directly to a Policy Decision Point (PDP), and the TVS API
that provides rich functionality for handling token used for access control and signalling. A special section is
devoted to the GAAA-TK library setup and configuration.

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
8
The current GAAA-TK library implementation provides full functionality needed to support basic testbed
scenarios. It has been tested with the WP1 Harmony testbed and expects integration into the WP2 G2MPLS
middleware. It is however planned that the library will be updated after feedback received from the
implementers and integrators.

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosphorus-WP4-M.4.1>
1 Introduction
The main objective of the Phosphorus project is to address some of the key technical challenges to enable on-
demand e2e network services across multiple administrative and security domains. The Authentication,
Authorisation and Accounting (AAA) service(s) is considered as an important component of the supporting
infrastructure for on-demand Optical Network Resource Provisioning (ONRP) across multiple domains and
different target consumer applications. A consistent AAA infrastructure requires interaction of the related AAA
components at all networking layers including network/forwarding elements, control plane, reservation and
provisioning service, and user/target applications layer.
This deliverable describes the result of the implementation of the AAA Authorisation infrastructure for multi-
domain Optical Network Resources Provisioning (ONRP) as a pluggable GAAA-TK Java library. The proposed
library is designed in such a way that it could support the major Phosphorus testbed use cases and can be
used at all networking layers: Data plane, Control Plane, Service plane, and can also work with applications.
The proposed GAAA-NRP architecture and GAAA-TK library also targets to ensure future compatibility with the
Grid and NREN access control solutions and infrastructures.
The report is organised as follows. Section 2 summarises the recent Generic AAA Authorisation framework
(GAAA-AuthZ) for ONRP developments. It describes necessary functionalities to support multi-domain ONRP
and introduces a number of mechanisms and solutions to support them, in particular: an AuthZ ticket format for
extended AuthZ session management, an AuthZ token format for multi-domain access control and signalling, a
Token Validation Service (TVS) to enable token based policy enforcement, and a policy Obligation Handling
Reference Model (OHRM). The proposed architecture will allow a smooth integration with other AuthZ
frameworks as currently used and developed by NRENs and the Grid community.
Section 3 describes in detail the proposed XACML-NRP attributes and the policy profile for general and optical
network resource provisioning.
Section 4 describes a set of APIs used to call the main GAAA-TK services. The authorisation service can be
requested via the Policy Enforcement Point (PEP) or directly from the XACML Policy Decision Point (PDP). The
TVS API provides rich functionality to handle token used for access control and signalling. A separate section 5
is devoted to the GAAA-TK library setup and configuration.
Finally, Section 6 provides a summary and suggests further library developments and updates after receiving
feedback from other packages.

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
10
It was a special decision to release the full functional GAAA-TK library two months before the major WP1 and
WP2 deliverables to allow them to integrate AAI functionality into their products and testbeds.
The developed library has been initially tested by WP1 and currently being integrated into the WP1 Harmony
application software.

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
11

2 Authorisation Infrastructure for
Multidomain Network Resource Provisioning
(GAAA-NRP) – General Design
This chapter describes the GAAA/AuthZ architecture for Optical Network Resource Provisioning, hereafter
referred to as GAAA-NRP. The GAAA-NRP extends further the generic AAA Authorisation Framework [1, 2]
and provides a basis for defining the major security mechanisms and components to support multi-domain
network provisioning process such as an AuthZ ticket format for extended AuthZ session management, an
AuthZ token format for multi-domain access control and signalling, a Token Validation Service (TVS) to enable
token based policy enforcement, and a policy Obligation Handling Reference Model (OHRM).
2.1 NRP/CRP operational models and AAA Authorisation
service architecture

The recent research by the authors showed that the major Network Resource Provisioning (NRP) use cases
can be abstracted to the same CRP operational model when considering their implementation with the Grid or
Web Services [3, 4]. This abstraction is considered as an important step to provide a common basis to define a
common access control infrastructure for dedicated optical networks and Grid resources accessed and
brokered over such networks.
The typical on-demand resource provisioning process includes four major stages: (1) resource reservation, (2)
deployment (or activation), (3) the reserved resource access/consumption, and additionally (4) resource de-
commissioning after it was used. In its own turn, the reservation stage includes three basic steps: (a) resource
lookup, (b) complex resource composition (including alternatives), and (c) reservation of individual resources.
The reservation stage may require the execution of complex procedures that may also request individual
resources authorisation. This process can be controlled by an advance reservation system or a meta-
scheduling system [5] and is driven by the provisioning workflow and related AuthZ policy [6]. At the

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
12
deployment stage the reserved resources are bound to the reservation ID, which we refer as the Global
Reservation Identifier (GRI). The decommissioning stage is considered as an important stage in the whole
resource provisioning workflow from the provider point of view and should include such important actions as
global provisioning/access session termination and user/process logout, log information sealing, accounting
and billing which are again currently considered as separates actions outside of the general provisioning
workflow. In this paper we are primary focused on the first three provisioning stages as the most related to the
applications operation.
Defining different CRP workflow stages will allow developing and using different security models for the policy
enforcement, trust and security context management.
In the discussed CRP model, domains are defined (as associations of entities) by a common policy of a single
administration, with common namespaces and semantics, shared trust, etc. In this case, the domain related
security context may include: namespace aware names and ID’s, policy references/ID’s, trust anchors,
authority references, and also dynamic/session related security context at the reservation and access stages
[6]. In general, domains can be hierarchical, flat or organized in the mesh, but all these cases require the same
basic functionality for the access control infrastructure to manage domain and session related security context.
In the remainder of the paper we will refer to the typical use case of the network domains that are connected as
chain (sequentially) providing connectivity between a user and an application.
The CRP model for the multi-domain distributed resource management model requires the following
functionality from the GAAA-AuthZ infrastructure:
• multiple policies processing and combination.
• attributes/rules mapping/converting based on inter domain trust management infrastructure.
• hierarchical roles/permissions management, including administrative policies and delegation.
• policy support for different logical organisation of resources, including possible constraints on resource
combination and interoperation.
Figure 2.1 illustrates major interacting components in the multi-domain 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) (typically related to
the Control plane).
• Inter-Domain Controller (IDC) and AAA service controlling access to the domain- related resources.
• Policy Enforcement Point (PEP), Policy Decision Point (PDP), and Policy Authority Point (PAP) as major
functional components of the AuthZ infrastructure.
• Token Validation Service (TVS) that allows efficient authorisation decision enforcement when accessing
reserved resources, and additionally can support token based service level signalling at the reservation
stage.

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
13


Figure 2.1. Components involved in multi-domain network resource provisioning and basic sequences (agent
(A), chain (C), and polling (P))

Figure 2.1 also illustrates different provisioning models or sequences that can be executed when composing a
complex resource:
• Chain reservation sequence (also referred to as a provider sequence). The user contacts only the local
network domain/provider that provides the destination address. Each consecutive domain provides a path
to the next domain.
• Polling sequence. The user client polls all resources or network domains, builds the path and makes the
reservation.
• Agent (or tree) sequence. The user delegates the network provisioning negotiation to an agent that will
take care of all necessary negotiations to provide the required network path to the user. A benefit of
“outsourcing” the resource provisioning is that the agents can maintain their own reservation and trust
infrastructure. This can be considered as a basic provisioning sequence for currently used Grid resource
management and advance reservation systems.
Access to the resource or service is controlled by the NRPS and protected by the AAA service that enforces a
resource access control policy. This is achieved by placing a PEP gateway at the NRPS. Depending on the
basic GAAA-AuthZ sequence (push, pull or agent) [1], the requestor can send a resource access request to the
resource or service (which in our case are represented by NRPS) or an AuthZ decision request to the
designated AAA server which in this case will act as a PDP. The PDP identifies the applicable policy or policy
set and retrieves them from the PAP, collects the required context information, evaluates the request against
the policy, and makes the decision whether to grant access or not.
Depending on the used authorisation and attribute management models, some attributes for the policy
evaluation can be either provided in the request or collected by the PDP itself. It is essential in the Grid/Web
services based environment that AuthN credentials or assertions are presented as a security context in the
AuthZ decision request and are evaluated before sending request to the PDP.
Based on a positive AuthZ decision (in one domain) the AuthZ ticket can be generated by the PDP or the PEP
and communicated to the next domain where it can be processed as a security context for the policy evaluation
in that domain.
AAA/IDC
PEP User
Client
NE
PEP
DC/NRPS
NE
PEP
NE
Agent
P
C
A
Service
(AAA)
plane
Control
plane
Dest
Host
Appli-
cation
Network
plane
AAA
PAP
PDP
PAP PAP
PDP PDP
TVS TVS TVS
AAA/IDC AAA/IDC
DC/NRPS DC/NRPS

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Although the above listed functionalities can be implemented under extended PEP or PDP functionality, such
an approach would significantly limit AuthZ service flexibility and potentially affect interoperability of different
implementations as the discussed functionalities require an agreement on a number of protocol issues,
messaging formats and attribute semantics.
Figure 2.2 illustrates the major GAAA-NRP/GAAA-AuthZ modules and how they interact when evaluating a
service request.
Obligation
Handler
Context
Handler
PEP
PDP
PAP
AuthZ Gateway
(AuthZ Handler)
Resource
NE/GMPLSServReq(Srv,An,Az)
XACMLAzResp
(AzDcsn,Oblig)
ServReq(Srv,Oblig2)
PDP
TVS
AzReq
(Srv,Subj,Act))
Validate
(AuthzToken)
XACMLAzResp
(AzDcsn)
NRPS/
Srv IF
GAAA-AuthZ
XACMLPolicy
(Target(S,R,A,E),
Rules(S,R,A,E),
Oblig0)
XACMLAzReq
(S,R,A,E)

Figure 2.2. GAAA-AuthZ components providing service request evaluation

The authorisation service is called from the service/application interface via the AuthZ gateway (that can 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/AuthZ
attributes. The AuthZ Gateway extracts necessary information and sends an AuthZ request AuthzRequest
(ServiceId, Subject, Action), that contains a service name ServiceId, the requestor’s identification and
credentials, and the requested Action(s), to the PEP. The major PEP’s task is to convert AuthZ request’s
semantics into the PDP request which semantics is actually defined by the used policy. When using an XACML
policy and correspondingly an XACML PDP, the PEP will send an XACML AuthZ request to the PDP in the
format (subject, resource, attributes, (environment)). If in general case the XACML policy contains obligations,
they are returned in the XACMLAzResponse (AuthzDecision, Obligations). The PEP calls the Obligation
Handler to process obligations which are defined as actions to be taken on the policy decision or in
conjunctions with the service access (like account mapping, quota enforcing, logging, or accounting).
If the service request contains an AuthZ token that may reference a local or global reservation ID, or just
identifies an AuthZ session in which context the request is sent, the token validation is performed by the Token
Validation Service (TVS). The TVS is typically called from the PEP and returns a confirmation if the token is
valid. Separating TVS as a separate function or service allows creating flexible token and/or ticket policy
enforcement infrastructures for on-demand network resource provisioning.
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
15

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
16
2.3 AuthZ Ticket formats for extended AuthZ Session
Management
2.3.1 AuthZ Ticket use in GAAA-NRP
The authorisation ticket (AuthzTicket) is a part of the GAAA-AuthZ framework functionality and allows the
transfer of a full AuthZ decision and policy enforcement context between a requestor and an AuthZ service or
between different AuthZ/security domains.
As discussed above, there are two types of sessions in the proposed CRP model that require a security context
management: reservation and provisioning session, and the reserved resource access session. Although the
provisioning session may require wider security context support, both of them are based on the (positive) AuthZ
decision, may have a similar AuthZ context and will require a similar functionality when considering distributed
multi-domain scenarios. In this case an AuthZ ticket should provide all necessary context information and will
serve as a session or access credentials.
To reduce possible high communication and processing overhead because of a potentially large size of an
AuthZ ticket, an AuthZ token can be used. In this case the AuthZ token should unambiguously reference the
original AuthZ ticket or instant AuthZ session context that must be securely stored at the resource or access
point. At the time of the authorised or reserved resource access, the original AuthZ ticket or AuthZ session
context object will be retrieved and used for the request evaluation. When used together, AuthzTicket and
AuthzToken share the SessionId attribute which can be either a global or a local reservation/session ID and are
cryptographically connected, e.g. the token value is a hash value of the ticket content. An AuthzTicket must be
digitally signed to keep its integrity.
In a particular use case of the Token Based Networking, the AuthzTicket is used for programming a TVS and
provides both a reservation ID/reference and detailed information for configuring a TBS (token based ForCES
switch) [10].
2.3.2 AuthzTicket data model and schema
An AuthzTicket has a complex but flexible format. The current AuthzTicket format and its implementation in the
GAAAPI supports extended functionality for distributed multi-domain hierarchical resources access control and
user roles/permissions management, in particular, administrative policy management (as defined in XACML 3.0
Administrative policy profile [11]), capabilities delegation and conditional AuthZ decision assertion (to support
XACML policy obligations). It is one of the general design suggestions that an AuthzTicket should be easy to
map to the SAML AuthzDecision Assertion [12] or to XACMLAuthzDecision Assertion defined by the SAML
profile of XACML [13, 14].

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
19
elements: TokenID = TicketID and TokenValue = SignatureValue, needed for the identification of
the cached AuthzTicket.
The current AuthzTicket functionality is supported by the GAAA-TK library (see chapter 4 for details).
2.4 Using AuthZ Tokens for Access Control and Signalling
The proposed GAAA-NRP architecture uses token extensively for access control and signalling at different
NRP stages considering it as a flexible and powerful mechanism for communicating and signalling security
context between domains.
We define token as an abstract reference to the reservation or the AuthZ session context in domains using an
abstract shared token meaning/context that is referenced by the token attributes. This definition is more
oriented for the NRP provisioning model/workflow and extends the proposed token definition as shared abstract
permission in earlier authors’ paper [4].
Tokens can be used for both access control when accessing the reserved resources and for signalling during
reservation and deployment stages and correspondingly we distinguish the two major types of token in the
GAAA-NRP architecture – access tokens and pilot tokens. Access tokens are used in rather traditional manner
and described in [4]. Pilot tokens functionality and format was proposed and defined as a result of the further
development of the AuthZ infrastructure as an integral component of the NRP.
Figure 2.4 illustrates the common data model of both access tokens and pilot tokens. Although sharing a
common data model they are different in the operational model and the way how they are generated and
processed. When processed by AuthZ service components they can be distinguished by the presence or value
of the token type attribute which is optional for access token and mandatory for pilot token.
Access tokens used in GAAA-NRP has a simple format and contains two mandatory elements: The SessionId
attribute that holds the GRI, and the TokenValue element, and optional a Condition element that may contain
two token validity time attributes notBefore and notOnOrAfter.
The GAAA-NRP architecture defines four types of pilot tokens that have different profiles of the common data
model and different processing/handling procedure:
Type1 – this pilot token type is used just as a container for communicating the GRI during the reservation
stage. It contains the mandatory SessionId attribute and an optional Condition element (it doesn’t contain a
TokenValue element).
Type2 – this pilot token type is the origin/requestor authenticating token. Its TokenValue element contains a
value that can be used as the authentication value for the token origin. The token value is calculated of the GRI
by applying e.g. HMAC function to the GRI together with the requestor symmetric secret or private key.

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Type3 – this pilot token type extends the Type2 with a Domains element that allows to collect domains security
context information (in the Domains/Domain element) when passing multiple domains during the reservation
process. Such information includes the previous token and the domain’s trust anchor or public key.
Type4 – this pilot token type is used at the deployment stage and can communicate between domains security
context information about all participating in the provisioned lightpath or network infrastructure resources. This
token type can be used for programming/setting up a TVS infrastructure for consistent access control tokens
processing at the resource access stage.



Figure 2.4. The access and pilot tokens data model.

The AuthzToken contains the following elements:
• The Root element attributes TokenID, SessionID, and Issuer that allows for the ticket unique
identification and defines its binding to the session and domains related processes/authorities.
• The Decisions/Decision element that holds the PDP AuthZ decision bound to the requested resource
or service expressed as the ResourceID attribute.
• The Resources extendable element that may hold proprietary description of the reserved resource.
• The Actions/Action complex element contains actions which are permitted for the subject or its
delegates.

Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
20

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
21
When used together with an AuthzTicket the ticket and token identification elements TokenID, SessionID,
and Issuer can be shared. Examples of different token types are provided in section 4.
2.5 Token Validation Service (TVS)
2.5.1 Basic TVS Functionality
The Token Validation Service (TVS) is a component of the GAAA-AuthZ infrastructure supporting token based
policy enforcement mechanism during the user access of the reserved service or network. Basic TVS
functionality allows checking if a service/resource requesting subject or other entity, that posses/presents
current token, has right/permission to access/use a resource based on advance reservation to which this token
refers. During its operation the TVS checks if a presented token has reference to a previously reserved
resource and a request resource/service confirms to a reservation condition. It is intended that extended TVS
functionality will also support policy enforcement for the consumable (or usable) resource.
In a simple/basic scenario, the TVS operates locally and checks a local reservation table directly or indirectly
using a reservation ID (typically a Global Reservation Id - GRI). It is suggested that in a multi-domain scenario
each domain may maintain its Local Reservation ID (LRI) and its mapping to the GRI.
In more advanced scenario the TVS should allow creation of a TVS infrastructure to support tokens and token
related keys distribution to support dynamic resource, users or providers federations.
The TVS functionality should support three basic use cases: Token Based Networking (TBN) using in-band
token based policy enforcement [15], Control Plane token based signalling in VLSR networks, and Service
Plane access control and signalling.
2.5.2 Token handling model
The token generation and handling model is based on the shared secret HMAC-SHA1 algorithm [16]. The
TokenKey is generated in the following way:
TokenKey = HMAC(GRI, tb_secret)
where
GRI – global reservation identifier,
tb_secret – shared Token Builder secret.
A token is created in a similar way but using TokenKey as a HMAC secret:
TokenValue = HMAC(GRI, TokenKey)

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
24
1) Obligation0 – (stateless) obligations are returned by the PDP in a form as they are written in the policy.
These obligations can be also considered as a kind of templates or instructions, tObligation. (Important to
mention that due to security reason obligations format and semantics should not use executable code or
reference to locally executed commands).
2) Obligation1 or Obligation2 – obligations have been handled by the obligation handler at the DCAS/PDP
side or at the PEP side, depending on implementation. In this case templates or instructions of the Obligation0
are replaced with the real attributes in Obligation1, e.g. in a form of “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. The result of obligations processing/enforcement, can be returned in a form of modified
AuthzResponce (Obligation1) or in a form of global resource environment changes that will be taken 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 return notification about fulfilled obligated actions, e.g. in
a form of Boolean value “False” or “True”, which will be taken into account by PEP or other processing module
to finally permit or deny service request by PEP.
3) Obligation3 – this is the final stage when obligations actually take effect, which can be defined as
obligations “termination” or “sink”. This is done by the resource itself or by services managed/controlled by the
resource.
In the proposed model, option with Obligation1 handling stage at the DCAS or PDP side is introduced to
illustrate a case when we need to implement a stateful PDP/DCAS what is important for the general CRP and
ONRP use cases in particular. However, this should not be considered as XACML specification violation as
distinguishing between PEP and PDP functions in the generic obligations handling model is based on what
module actually makes policy based request evaluation.

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
25
3 XACML policy profile for OLPP/CRP
This section provides information about the proposed and implemented in the GAAA-TK library the XACML-
NRP attributes and policy profile for network resource provisioning. The section starts with the definition of the
two basic use cases for access control and policy definition in the Phosphorus testbed. It provides a short
overview of the existing network topology description formats that has relations to the Phosphorus testbed. The
next section describes a set of resource, subject, actions and environment attributes that are considered
important/relevant to the policy definition in more general NRP use cases. Additionally, the section provides
suggestions about policy obligations that can be used in more complex policy definition and enforcement for
advance reservations and multi-domain and multi-provider use cases.
Policy examples and corresponding Request and Response messages are provided in Appendix D.
3.1 Access Control in NRP – Basic Use Cases
The access control system and infrastructure protects a resource to allow/ensure that only authorised users
can have access or execute specific actions on the resource. In general, the access control policy comprises of
rules and conditions that specify what user with what attributes may access or execute what action on the
resource with what attributes.
Two particular use cases for access control in Network Resource Provisioning (NRP) can be expressed in a
simple narrative form:
Use case 1: "User A is only allowed to use user endpoints X, Y and Z", or
Use case 2: "User A is only allowed to use endpoints in domain N and M".
The following assumptions are made to satisfy the two above use cases and to ensure effective management
of policies, user and resource identities and attributes:
• Users and resources are described/identified by their unique ID’s and may have also assigned attributes,
which for the user may include such attributes as user group, role, or federation, and for the resource may
include such attributes as domain/subdomain, resource type, level of service;

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
29
<ndl:connectedTo rdf:resource="#tdm1.amsterdam1.netherlight.net:12/1"/>
<ndl:capacity
rdf:datatype="http://www.w3.org/2001/XMLSchema#float">1.2E+9</ndl:capacity>
</ndl:Interface>

Example NDL-2
<rdf:Description rdf:about="">
<!-- meta data on this document itself -->
<rdfs:label xml:lang="en">Configuration of Speculaas</rdfs:label>
<dc:title xml:lang="en">Configuration of Speculaas</dc:title>
<dc:description xml:lang="en">Configuration of the Speculaas switch at
Netherlight. This file is semi-dynamically generated by a cron job that logs in the
devices and retrieves all information. You should expect this data to be stale for about 5
minutes. If you really need real-time data, then don't use NDL, but another mechanism
(e.g. a routing protocol).</dc:description>
<dc:publisher xml:lang="en">glimmerglassconfig.py script on
ndl.uva.netherlight.nl</dc:publisher>
<dcterms:issued>2007-01-31</dcterms:issued>
<dcterms:modified>2007-12-12T15:17:11+0100</dcterms:modified>
</rdf:Description>

<ndl:Device rdf:about="http://speculaas.uva.netherlight.nl#Speculaas">
<rdfs:label>Speculaas</rdfs:label>
<dc:description xml:lang="en">Speculaas Glimmerglass OXC</dc:description>
<ndl:hasInterface rdf:resource="http://speculaas.uva.netherlight.nl#intf01"/>
<ndl:hasInterface rdf:resource="http://speculaas.uva.netherlight.nl#intf02"/>
<ndl:hasInterface rdf:resource="http://speculaas.uva.netherlight.nl#intf03"/>

<ndl:hasInterface rdf:resource="http://speculaas.uva.netherlight.nl#intf19"/>
<capability:hasSwitchMatrix>
<capability:SwitchMatrix
rdf:about="http://speculaas.uva.netherlight.nl#FiberSwitchMatrix">
<capability:hasSwitchingCapability
rdf:resource="http://www.science.uva.nl/research/sne/ndl/wdm#FiberNetworkElement" />
<capability:hasSwappingCapability
rdf:resource="http://www.science.uva.nl/research/sne/ndl/wdm#FiberNetworkElement" />
<ndl:hasInterface
rdf:resource="http://speculaas.uva.netherlight.nl#intf01"/>
<ndl:hasInterface
rdf:resource="http://speculaas.uva.netherlight.nl#intf02"/>

<ndl:hasInterface
rdf:resource="http://speculaas.uva.netherlight.nl#intf12"/>
</capability:SwitchMatrix>
</capability:hasSwitchMatrix>
</ndl:Device>

<ndl:Interface rdf:about="http://speculaas.uva.netherlight.nl#intf01">
<rdf:type
rdf:resource="http://www.science.uva.nl/research/sne/ndl/wdm#FiberNetworkElement"/>
<!-- static FiberInterface -->
<rdfs:label>1</rdfs:label>
<dc:description xml:lang="en">Rembrandt0 (10GE)</dc:description>
<wdm:ingressPowerLevel rdf:datatype="http://www.w3.org/2001/XMLSchema#float">-
3.29</wdm:ingressPowerLevel>
<wdm:egressPowerLevel rdf:datatype="http://www.w3.org/2001/XMLSchema#float">-
53.03</wdm:egressPowerLevel>

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
3.3 XACML Policy and attributes format
The XACML policy format provides rich functionality for Network Resource Provisioning in its core specification
[14] and special profile for hierarchical resources [20], and for RBAC [21]. Hierarchical policy management and
dynamic rights delegation, that are considered as important functionality in multi-domain ONRP, can be solved
with the XACML v3.0 administrative policy profile [11]. XACML allows a flexible definition of authorisation rules,
conditions and use of different attribute formats.
A XACML policy is defined for the target tuple “Subject-Resource-Action” (S-R-A) which can also be completed
with the Environment element (S-R-A-E) to add additional context to instant policy evaluation (refer to Fig. 3.1).
The XACML policy can also specify actions that must be taken on positive or negative PDP decisions in the
form of an optional Obligation element. This functionality is important for the potential integration of the AuthZ
system with logging or auditing facilities.


Figure 3.1. XACML Policy data model.
A decision request sent in a request message provides a context for the policy-based decision. The policy
applied to a particular decision request may be composed of a number of individual rules or policies. Few
policies may be combined to form a single policy that is applicable to the request. XACML specifies a number
of policy and rule combination algorithms. The response message may contain multiple result elements, which
are related to individual resources.
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
31

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
33
otherwise when other entity is declared as a PolicyIssuer, the PDP should initiate checking administrative policy
and delegation chain what is a suggested functionality of the PIP module.
In order to use the XACML format for AuthZ in ONRP, a special XACML-NRP profile for Network Resource
Provisioning described in this section addresses the following issues:
• Namespace definition for the network resources, user attributes, and GAAA/AuthZ components
• Attribute semantics and expression format, including support list of enumerated values, if necessary
• Set of basic rules and policy templates (including possible mapping to existing policies in this domain)
To facilitate the XACML-NRP profile introduction the GAAA-TK library developed in WP4 provides a reference
implementation, in particular it addresses the following issues:
• namespace support, attribute formats and semantics, including enumerated values, typically provided by
profile related attribute handler or helpers
• support of underlying trust infrastructure/fabric.
Some general examples of the XACML policies are provided in the Appendix D.
3.4 Attributes used for Authorisation and XACML policy
definition
3.4.1 Attributes namespace
The XACML-NRP attribute profile will use the AuthZ interoperability namespace of the URL style “http://authz-
interop.org/” introduced in the recently released XACML-Grid profile [23]:
http://authz-interop.org/nrp/xacml
Note: Alternatively it can be considered to use the URN-style for proprietary or potentially to be registered
namespace:
x-urn:authz-interop:nrp:xacml
3.4.2 Network or Resource related attributes
Network related attributes allow building policy depending on the network topology or other network
characteristics. Network related attributes are considered as a part of the XACML Resource definition.
The following resource/network related attributes can be specified and used for authorisation:

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
34
Attribute nam ute ID ML attribu
ntics
(ns-prefix =
http://authz-
interop.org/nrp/xacml)
Notes
• Domain ID (network domain)
• Subdomain (or relationship)
• VLAN
• Node or TNA and TNA prefix, or
• Interface ID
• Device or resource-type
• Link ID
• Link parameters: average delay and maximum bandwidth
• ReservationEPR that may directly or indirectly define the resource federation or security/administrative
domain
Federation that defines a number of domains or nodes sharing common policy and attributes
e Attrib Full XAC
sema
teId
Domain ID domain-id {ns-prefix} /resourc -id Domain ID means full domain
identification including
resource realm or other
information. In this way it is
different from resource
domain
e/domain
Realm resource-realm {ns-prefix} /resource/resource-

Resource realm is associated
with a projec
typically has own
attributes and po g.
“testbed.ist-
phosphorus.eu“
realm t or profile and
sub-set of
licies (e.
)
Domain resource-domain {ns-prefix} /resource/resource-
domain
See note to dom
attribute
ain ID
Subdomain subdomain {ns-prefix} /resource/sub-domain
VLAN vlan {ns-prefix} /resource/vlan
TNA tna (+ tna-prefix) {ns-prefix} /resource/tna-
prefix/tna
Consider relation
TNA, EPR and node
between
Node node efix} /resource/no {ns-pr de
Link link-id {ns-prefix} /resource/lin k-id
avrDelay delay {ns-prefix} /resource/delay
maxBW bandwidth-max {ns-prefix} /resource/bandwidth Consider splittin
limits:
g on two

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
36
urn:oasis:name
subject:subject-id
s:tc:xacml:1.0:
Subject
confirmation
subject-confdata {ns-prefix} /subject/subject-confdata
Subject
federation
federation {ns-prefix} /subject/federation This attribute shoul
onsidered as simil
ubject-vo” in XAC
profile if network do in or
endpoint are members of a VO
d be
ar to the
ML-Grid
ma
c
“s
Subject group subject-group {ns-p } /subject/subject-grou refix p
Subject role subject-role {ns-prefix} /subject/subject-role onsider relation b
TNA, EPR and nod
C etween
e
Subject Context subject-context {ns-prefix} /subject/subject-context

Subject attributes are provided as Subject credentials which depending on user client implem
middleware may take a form of X.509 public key and attribute certificates (PKC, AC), SAML Authenticatio
Attribute assertions, proprietary AuthN system credentials.
ubject may also use attributes defined in the XACML-Grid profile or attributes originally defined in the XACML
ecifications. See Appendix for such candidate attributes.
Action related attributes represent a limited number of the specific actions that requesting party can ask to
initiate network resource reservation, access or management. Action related attributes are considered as a part
• Action type
Attribute name Attribute ID Full XACML attributeId semantics
(ns-prefix =
Notes
entation and
n and
S
and SAML sp
3.4.4 Action related attributes
of the XACML Action definition.
The following Action related attributes can be specified:
• Action ID
http://authz-interop.org/nrp/xacml)
Action ID action-id {ns-prefix} /action/action-id Consider using standard
XACML attribute ID:
es:tc:xacml:1.0:
action:action-id
urn:oasis:nam

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
37
ti
is used only together with the
enumerated action identifier
Ac on type action-type {ns-prefix} /action/action-type/{value} This type of attribute identifier


List of action type enumerated values:
Attribute
name
Enumerated
value
XACML attribute value
(ns-prefix =
http://authz-interop.org/nrp/xa
Notes
cml)
create-path {ns-prefix} /action/action-type ath /create-p
activate-path {ns-prefix} /action/action-type -path /activate
cancel {ns-prefix} /action/action-type/cancel
Action type
a s {ns-pr tion/action-type cces efix} /ac /access



3.4.5 Environment related attributes
Environment related attributes allow providing additional inform policy definition and evaluation.
Environment related attributes are con as a part of the XACML Environment definition.
There is no spec nvironment attributes identified for XACML-NRP profile at this mom
for list of the Environment attributes specified in XACML2.0 spe n and XACML-Gri
3.4.6 Policy Obligations used in NRP
Policy obligation is one of the authorisa policy enforcemen nisms that allows adding AuthZ decision
enforcement com ents that can not fined in the policy at the moment of making policy decision by the
PDP, or may not be known to the PDP or policy administrator/write
Suggested functionality that can be achieved with using obligations includes but not limited to:
ation for
sidered
ent. Refer to Appendix
d profile.
ific E
cificatio
tion
be de
t mecha
r
pon

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
38
• Intradomain rk/VLAN mappin ross-domain conn that can be used
external/inte in border links/T AN an etwork
• Account mapping
• Type of service (or QoS) assigned to a specific request or p sion
• Quota a t
• Service c on with implie ns (e.g., comp orage resourc
• Usable reso /quota
Below text provides current suggestion obligations definiti re details will be provided with wider
use and acceptance of the XACML-NRP profile.
3.4.6.1 Intradomain network/VLAN mapping
This obligation is returned by the PDP in case of positive decision with instruction to what type of or a specific
co apped when accessing a requested network resource.
me type may be limited, consequently a dynamically assigned account
counts. Such dynamic account assignment can not be
done by PDP. However, the access control policy may
n to PEP to do such mapping.
3.4.6.3 Usability and accounting
Usability and acc ng obligations all hat some usability mber of downloads, total time of
using network resource, amount of data transferred) assign ccounting instruction are applied to the
specific request decision.
3.5 Policy Expression Conventions
This section discribes the current policy expression conventio basic Phosphorus use cases described
in section 3.1.
netwo
rdoma
g for c
NA’s to internal VL
ections,
d sub-n
olicy deci
to map
ssignmen
ombinati
urces
d conditio
s for the
uting and st
on. Mo
es)
This may be needed for defining specific intra-domain mapping of cross-domain connections depending on
specific reservation, path or user attributes.
3.4.6.2 Network user identity mapping
pool ac unt the user identity should be m
The need of account mapping may exist in cases when domain based Network Resource Provisioning Systems
(NRPS) have pre-installed/built-in pool accounts to which are different types or quality of service are assigned.
In such situation authorised user need to use one of such accounts, e.g. “silver”, “golden”, “platinum”. A number
of different individual accounts of the sa
should be selected from the pool of available or free ac
specified in the typically stateless policy and cannot be
contain instructio
ounti ow t attributes (e.g. nu
ed or a

ns for the

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
41
osphorus.eu/phosphorus-policy-demo001.xml
licyId or PolicySetId is created in the same way using typical for URL/URN style
conventions:
orus.eu/viola/harmony/demo001/policy
orus.eu:viola:harmony:demo001:policy

ace-prefix = http://authz-interop.org/nrp/xacml
or namespace-prefix = x-urn:authz-interop.org:nrp:xacml
URL style:
I = ht p://au
us.eu hosp
e mony/demo001/policy
s/demo001/policy
olicyId = x-urn:authz-interop.org:nrp:testbed.ist-
phosphorus.eu:viola:harmony:demo001:policy
Given above examples the AuthZ Request containing ResourceId and SubjectCtx attributes will be resolved
into the following policy path/files:
<<root-dir>>/policy/nrp/testbed.ist-phosphorus.eu/viola-policy-nsp-demo001.xml
<<root-dir>>/policy/nrp/testbed.ist-phosphorus.eu/harmony-policy-demo001.xml
<<root-dir>>/policy/nrp/testbed.ist-ph

3.6.3 Policy identification
It is suggested that the Po
PolicyId = <<url-namespace-prefix/>>testbed.ist-phosph
PolicyId = <<urn-namespace-prefix:>>testbed.ist-phosph
where
<<namespace-prefix>> - can be dropped;
namesp

Example PolicyId expression:
Policy d t thz-interop.org/nrp/xacml/testbed.ist-
phosphor /p horus/demo001/policy
PolicyId = http://t stbed.ist-phosphorus.eu/viola/har
PolicyId = http://testbed.ist-phosphorus.eu/phosphoru

URN style:
P
PolicyId = x-urn:authz-interop.org:nrp:testbed.ist-phosphorus.eu:phosphorus:demo001:policy

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
42
GAAA-TK library components
The identified and described in the D4.1 report such as
ess
con handling with obligations handlers supporting the
Figure 4.1 illustrates the major GAAA-AuthZ modules and how they interact when evaluating a service request,
al structure of the ContextHandler module that
between PEP and PDP and with external services if

4 GAAA Toolkit Library
This section provides information about the current implementation of the basic GAAA-NRP functionality in the
pluggable GAAA Toolkit library.
4.1
library provide the major functionality and mechanisms
a Token Validation Service (TVS), authorisation/provisioning session security context management and acc
trol with AuthZ tickets and tokens, policy obligations
Obligation Handling Reference Model (OHRM), and the XACML policy and attributes profile for OLPP.
it is based on the Fig. 2.2 but provides more details about intern
supports all necessary communications and interaction
additional information is needed for the policy evaluation.

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
44
service s for on-demand network
se it as a pluggable component to other AuthZ frameworks.
4.2 AAA/AuthZ API and programming examples
services into target
nd simple XACML PDP
extracts necessary information from the service
ionality supports all necessary communication
mponents as PDP, PAP, Attribute Authority Service (AAS), TVS, and Obligation Handlers (OH).
Note: Currently available GAAAPI implementation supports only local call to internal/local components. Further
GAAAPI development will include external callouts to domain or site central AAA/AuthZ services.
4.2.1 PEP-GAAAPI interface
PEP-GAAAPI interface provides a few commands/methods to request policy based AuthZ decision depending
on the set of provided information:
a) Method #1 should either return a logical value "True" or "False", or throw the appropriate exception
Boolean org.aaaarch.gaaapi.PEP.authorizeAction
(String resourceURI, String actions, HashMap subjmap)
throws java.lang.Exception,
org.aaaarch.gaaapi.NotAuthenticatedException,
/* user subjconfdata (i.e. authenticationToken) is not valid */
org.aaaarch.gaaapi.NotAvailablePDPException;
/* PEP could not reach PDP, or other internal PDP error*/
where
@ resourceURI – Resource ID in a form of URI
@ actions – requested actions (currently supported only one action)
@ {subjmap} set of values (subject-id, subject-confdata, subject-role, subject-context)
@ subject-id - subject Id in form of RFC822
@ subject-confdata - AuthN token or SAML AuthN assertion
@ subject-role - role for the particular request (may be in a form either simple
attribute or RQAN)
@ subject-context - subject context, e.g. Experiment, VO, or VLab in which
the subject and resource attributes are defined

Note: This method uses complex resource URI that may consist of ResourceId part and additional parameters
in a form of “name=value” pairs (see section 4.2.4 for attribute expression conventions).
b) Method #2 should either return a logical value "True" or "False", or throw the appropriate exception
to allow creating flexible token based policy enforcement infrastructure
resource provisioning and possibly u
General
GAAAPI package provides all necessary functionality to smoothly integrate AAA/AuthZ
application. GAAAPI package is provided together with the PEP implementation a
implementation.
PEP-GAAAPI is called from the application AuthZ gateway that
request and creates AuthZ request to PEP. GAAAPI funct
b
o
etween PEP and PDP and depending on implementation may include also external callout to such
c

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
45
Boolean org.aaaarch.gaaapi.PEP.authorizeAction
(HashMap resmap, HashMap actmap, HashMap subjmap)
throws java.lang.Exception,
org.aaaarch.gaaapi.NotAuthenticatedException,
org.aaaarch.gaaapi.NotAvailablePDPException;
where
@ resmap – set of the Resource related attributes in a form or HashMap
@ resmap = (resource-id, resource-domain, resource-type) and other resource
related attributes
@ actmap – requested actions (currently supported only one action)

c) Method #3 should either return a logical value "True" or "False", or throw the appropriate exception
B
ring subjectId, String subjconfdata,
throws java.lang.Exception,
org.aaaarch.gaaapi.NotAuthenticatedException,
resource ID format. All additional parameters will be ignored and not used for
policy resolution.
ho se", or throw the appropriate exception
@ authzToken – access token in a form of XMLToken
ion
(String authzTicketToken, String sessionId, String resourceURI,
String actions)
throws java.lang.Exception,
org.aaaarch.gaaapi.NotAuthenticatedException,
org.aaaarch.gaaapi.NotAuthorizedException,
org.aaaarch.gaaapi.NotAvailablePDPException;
were
@ authzTicketToken – AuthZ ticket or token containing all necessary AuthZ session context
@ sessionId – Session ID that can be also a Global or Local reservation ID (LRI/GRI)

d) Method #6 should either return a valid AuthorisationTicket or AuthorisationToken (refer to section 2 and
Appendix for AuthzTicket and AuthzToken format and examples), or throw the appropriate exception
String org.aaaarch.gaaapi.PEP.authorizeAction
(String authzTicketToken, String sessionId, String resourceURI,
String actions, HashMap subjmap)
throws java.lang.Exception,
org.aaaarch.gaaapi.NotAuthenticatedException,
oolean org.aaaarch.gaaapi.PEP.authorizeAction
(String resourceId, String actions, St
String roles, String subjctx)
org.aaaarch.gaaapi.NotAvailablePDPException;

Note: This method uses simple
d) Met d #4 should either return a logical value "True" or "Fal
Boolean org.aaaarch.gaaapi.PEP.authorizeAction
(String authzToken, HashMap resmap, HashMap actmap, HashMap subjmap)
throws java.lang.Exception,
org.aaaarch.gaaapi.NotAuthenticatedException,
org.aaaarch.gaaapi.NotAvailablePDPException;
where

e) Method #5 should either return a valid AuthorisationTicket or AuthorisationToken (refer to section 2 and
Appendix for AuthzTicket and AuthzToken format and examples), or throw the appropriate exception
String org.aaaarch.gaaapi.PEP.authorizeAct

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
org.aaaarch.gaaapi.NotAuthorizedException,
org.aaaarch.gaaapi.NotAvailablePDPException;
4.2.2 Simple XACML PDP API
The main GAAA-TK use suggests that the XACML PDP is requested via PEP that converts the application
specific AuthZ request to XACML Request format. However, it is possible to request the XACMLPDPsimple
class directly via the following API:
a) Method #1 return XACML Response message as String, or throws an exception
String org.aaaarch.gaaapi.impl.pdp. XACMLPDPsimple.requ
(RequestCtx request, String policyref)
throws java.lang.Exception

a) Method #1 return XACML Response message as String, or throws an
estPDP
exception
String org.aaaarch.gaaapi.impl.pdp. XACMLPDPsimple.requestPDP
uestCtx or String
@ policyref – path to policy file location
(String requestStr, String policyref)
throws java.lang.Exception
were
@ request, or requestStr – XACML request in a form of the XACML Req

Examples of the XACML Request/Response messages and corresponding XACML policy are provided in
Appendix:
4.2.3 GAAA-PEP API programming examples
1) Preparing PEP request data
Two types of data are used as input to PEP.authoriseAc
set. The example below illustrates how to put String variable
tion methods – string variables and HashMap attributes
s into HashMap and how to extract individual
attribute from HashMap.

HashMap<String, String> subjmap = new HashMap<String, String>();
HashMap resmap = new HashMap();
HashMap actmap = new HashMap();

// Obtaining test set of the subject attributes
subjmap = SubjectSet.getSubjSetTest();
// extracting subject attrs from the subjmap
String subjectId = subjmap.get(ConstantsNS.SUBJECT_SUBJECT_ID).toString();
String subjconfdata = subjmap.get(ConstantsNS.SUBJECT_CONFDATA).toString();
String roles = subjmap.get(ConstantsNS.SUBJECT_ROLE).toString();
String subjctx = subjmap.get(ConstantsNS.SUBJECT_CONTEXT).toString();
// modifying subjctx for experiments

//Example Subject attributes
String subjectId = "WHO740@users.collaboratory.nl";
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
46

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
48
String ix); sessionId = GRIgenerator.generateGRI(32, gripref

// Composing session context vector
Vector gri, resmap, actmap, subjmap); sessionCtx = TVS.getSessionCtxVector (domainId,

/* If it is necessary, the TVSTable can be purged completely of for a selected domain
* Use this method
* TVSTable.purgeTVSTable(null, 0);
*/

// Adding a new TVS entry
TVS.setEntryTVSTable(domainId, gri, sessionCtx);

// checking TVS table content
String tablefile = TVS.getTVSTableFile ();
Document tabdoc = HelpersXMLsecurity.readFileToDOM(tablefile);
HelpersXM ng TVSTable context if you want Lsecurity.printDOMdoc(tabdoc); // pri

// Generating XMLToken (type 0)
// Set ration or obtain necessary variable for XMLToken gene
Boolean simple = false; // simple token format doesn’t contain time validity

Int validtime = TVS. getConfigValidityTimeDefault();
Int validtime = 1440; // validity time is 24 hrs

String tokenxml = TokenBuilder.getXMLToken(domainId, gri, null, validtime, simple);

//Request PEP with XMLToken (method #4)

boolea

n decision = PEP.authorizeAction (tokenxml, resmap, actmap, subjmap);
4.2.4 Attribute expression conventions
Information provided in the AuthZ request to PEP-PDP contains information about Resource, Subject, Action,
and optionally Environment.
a) Resource at
Current ne attribute ResourceId in the form of URI
string t of parameter used for policy-based request
main”,
The foll
a) http:/ e}/{parameters}
tributes
ly the Resource variable in the AuthZ request contains o
hat includes the network resource identifier and a list
evaluation. When sending a XACML Request to XACML PDP the input URI string is converted into the
levant HashMap resmap that contains a set of resource related attributes. The names for some of the re
source attribute identifiers are taken from the XACML-NRP profile, such as “resource-id”, “resource-dore
“resource-realm”, “resource-type”, “source”, “target”, etc., however it is responsibility of the application
developer to correctly format the ResourceId URI string.
owing ResourceId formats are supported:
/testbed.ist-phosphorus.eu/{domain}/{device | servic

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
50
servation context for dynamically configured
sted action in a form of simple string
s like proposed in the XACML-NRP
uest and in the policy must use the
) Token Builder commands
uilder.getXMLToken(String domainId, String gri, byte[]
olean simple)
gri, String
main, int validtime, byte[] tokenKey, int ptokentype, String tokenCtx)

ic boolean validateBinaryToken (String token, String gri, byte[] tokenKey)
throws Exception
(Document aztdoc, byte[] tokenKey)
MalformedXMLTokenException,
called from PEP and validates AuthZ Request (resmap, actmap, subjmap) against
oken,
String> subjmap)
Potentially this attribute can be extended to provide instant re
AuthZ service.
c) Action attributes
The Action element contains single attribute/value that defines reque
e enumerated action ID’attribute or using fully qualified name for som
profile.
Note. It is important to note that corresponding attributes in the AuthZ req
same attribute names/ID’s and format.
4.3 TVS API
4.3.1 TVS interface
a
public static byte[] TokenBuilder.getBinaryToken(String gri, byte[] tokenkey)

public static String TokenB
okenKey, int validtime, bot

ublic static String TokenBuilder.getXMLTokenPilot(String domainId, String p
do

b) TVS token validation interface - validates the binary or XML token thenselves;
public stat

public static boolean validateXMLToken
throws Exception,
NotValidAuthzTokenException

public static boolean validateXMLToken (String authzToken, byte[] tokenKey)
throws Exception,
MalformedXMLTokenException,
NotValidAuthzTokenException

) PEP-TVS interface: isc
XML token;

public static boolean validateAuthzRequestByToken (String authzT
HashMap resmap, HashMap actmap, HashMap<String,

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
51
String gri,
ashMap actmap, HashMap subjmap)
domainId, String gri)
i)
domainId, int expireTime)
nding particular reservation information in a
uest token generation from the calling application, use these commands/methods:

throws Exception,
MalformedXMLTokenException,
NotValidAuthzTokenException

d) Internal TVS programming interface use the follqwing basic commands:
TVS.setEntryTVSTable(String domainId,
HashMap resmap, H

TVS.getEntryTVSTable(String

VS.deleteEntryTVSTable(String domainId, String grT

public static boolean purgeTVSTable (String

Note, that TVS programming calls will be exposed as We Services.
e) External/WS TVS programming interface
External TVS interface will allow programming TVS table by se
SOAP message.
4.3.2 TVS programming examples
1
To req
) Generating binary token
// Prepare data for token generation
String gri = "".concat(org.aaaarch.gaaapi.common.IDgenerator.generateID(20).toString());
byte[] tokenkey = TokenKey.generateTokenKey(gri);

byte[] token = TokenBuilder.getBinaryToken(gri, null);


2) Generating XML token

// Set parameter for token generation
boolean simple = true; // simple token doesn’t contain Conditions element
int validtime = 0; // this variable sets token validity in minutes; default is 24 hrs
String domainId = "http://testbed.ist-phosphorus.eu/viola/harmony";
//
String gri = GRIgenerator.generateGRI(20).toString();

String tokenxml = TokenBuilder.getXMLToken(domainId, gri, null, validtime, simple);


3) Validating binary token

boolean valid = TVS.validateBinaryToken (

token, gri, null);
4) Validating XML token itself. Two methods can be used to validate full token va;idity and time validity:

XMLTokenType token = new XMLTokenType (tokendoc);

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
52
// Checking token validity time
boolean timevalid = token.isTimeValid(token);

// checking token validity
boolean valid = TVS.validateXMLToken (tokendoc, null);

4) Valid

ating AuthZ request context against XML token
//Prep ting TVS are input data for reques

// If s String XMLToken is received a
Documen ecuritry.readStringToDOM(String) (tokenString); t tokendoc = HelpersXMLS

XMLTokenType token = new XMLTokenType (tokendoc);

// Simple token time validity check
boolean timevalid = token.isTimeValid(token);

// Validating token against stored in TVS table session context
TVS.validateXMLToken(tokendoc, null);

// Validating AuthZ request against XML token and stored session context
boolean confirmed = TVS.validateAuthzRequestByToken (aztstr, resmap, actmap, subjmap);


4.4 Authorisation ticket and token examples
4.4.1 Authorisation ticket examples
GAAAPI supports AuthZ tickets (and additionally AuthN tickets) generation in a proprietary XML format and by

using the SAML assertion format. AuthZ ticket format was discussion in section 2.3. Examples of AuthZ tickets
are provided in the Appendix B.
4.4.2 TVS XML Token format and examples
Refer to the token data model and token types definition in section 2.4
a) Access token (type 0)
XML token format uses a special “TVS/TBN” profile of the more general AuthzToken format. Example of the full
TVS XML token is shown below:
<AAA:AuthzToken xmlns:AAA="http://www.aaauthreach.org/ns/#AAA"
Issuer="urn:aaa:gaaapi:token:TVS"
SessionId="a9bcf23e70dc0a0cd992bd24e37404c9e1709afb"
TokenId="d1384ab54bd464d95549ee65cb172eb7">

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
56
| +-- schemass
| +-- sql
+-- +-- wsdl
+-- etc
| +-- security
| +-- keystore
| +-- ibc
| +-- trusted
| +-- xmlsec
| +-- symkeystore
+-- gaaa-bin
| +-- gaaapi-nrp-v0*-release-date*.jar
+-- gaaa-lib
| +-- endorsed
| +-- lib-ibc
+-- x-output
+-- _aaadata
+-- cache
| +-- aztickets
| +-- sessions
+-- tmp

release-date*.jar is the GAAA-TK library ot the recent release (should be checked at the
w.ist-phosphorus.eu/wiki/index.php/Pluggable_GAAA-TK_library).
nstallation
l-libraries.zip – all required libraries including GAAA-TK library itself.
es.zip – all necessary supporting directories
d libraries to support core GAAAPI and TVS functionality:
where gaaapi-nrp-v0*-
WP4 wikipage http://ww
5.2 I
Current GAAA-TK library requires manual installation.
The installation package consists of the 3 archives:
• gaaa-tk-lib-externa
• gaaa-tk-lib-directori
• gaaa-tk-lib-test-calesses.zip – test classes that contains examples how to call the library functions.
Installation procedure is simple. To install GAAA-TK library, you need to unpack provided archives into the
selected <root-directory> from which the GAAA-TK functions will be run.
To run GAAA-TK library functions, use programming examples described in section 4.
5.3 Required external libraries
The list of currently use

bcprov-jdk15-130.jar
commons-codec-1.3.jar
commons-logging-1.0.3.jar
commons-logging-api.jar
dom3-xercesImpl-2.5.0.jar
dom3-xml-apis-2.5.0.jar

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
57
jaxrpc-1_1-fr-spec-api.jar
jaxrpc-sec.jar
joda-time-1.4.jar
junit-3.8.1.jar
log4j-1.2.8.jar
opensaml-2.0-TP1-jdk-1.5.jar
openws-1.0-alpha1-jdk-1.5.jar
resolver.jar
saaj-api.jar
saaj-impl.jar
soapprocessor.jar
xmldsig.jar
sunxacml-cvs1.6.jar
sunxacml-support-cvs1.6.jar
xmlsec-1.4.1.jar
xmlsecSamples.jar
xalan-2.6.jar
xercesImpl.jar
xml-apis.jar

The following libraries must be placed ito “endorsed” directory:

endorsed/resolver.jar
endorsed/xalan-2.6.jar
endorsed/xercesImpl.jar
endorsed/xercesSamples.jar
endorsed/xml-apis.jar
endorsed/xmlParserAPIs.jar


The following libraries are required to support use of Identity Based Cryptography for token key distribution in
multi-domain environment:

lib-ibc/IdentityBasedEncryptionJCA.1.0.38.jar

lib-ibc/library/jakarta-regexp-1.4.jar
lib-ibc/library/bcel-head.jar
lib-ibc/library/FieldTracker.jar
lib-ibc/library/artima/suiterunner-1.0beta6.jar
lib-ibc/library/nuimcscg/tender-dev.jar
lib-ibc/library/nuimcscg/ArtimaSuiteRunnerAntTask.1.1.3.jar
lib-ibc/library/nuimcscg/blitz-dev.jar
lib-ibc/library/nuimcscg/fault-dev.jar
Full set of libraries is provided next to the GAAA-TK jar-file at the WP4 wikipage http://www.ist-
phosphorus.eu/wiki/index.php/Pluggable_GAAA-TK_library

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
58
The report describes the results of the development and implementation of the Generic AAA Authorisation
format for extended AuthZ session management, an AuthZ token format for multi-domain access control and
signalling, the Token Validation Service (TVS) to enable token based policy enforcement, and a policy
OHRM).
The developed pluggable GAAA-TK Java library is designed in a such way that it could support the major
proposed architecture will allow a smooth integration
with other AuthZ frameworks as currently used and developed by NRENs and the Grid community.
te on the proposed XACML-NRP attributes and policy profile for general and
optical network resource provisioning.
rvices The Authorisation service can
Policy Decision Point (PDP).
an ling. A separate
rmat and
utomatic
ort for
ntext
nterface and SAML-XACML protocol to support
alls, adding XML database adaptors for storing XACML policies and TVS session
bases, adding SAML subject attribute validation (when information is received from WP3).
nt GAAA-NRP architecture development and the GAAA-TK library implementation, WP4 will
d assist other WP’s in integrating AAA/AuthZ services into

6 Conclusion
framework (GAAA-AuthZ) for ONRP developments. It describes the key functionalities to support multi-domain
ONRP and introduces a number of mechanisms and solutions to support them, in particular: an AuthZ ticket
Obligation Handling Reference Model (
Phosphorus testbed use cases and can be used at all networking layers: Data plane, Control Plane, Service
plane, and can be also integrated with applications. The
The report provides an upda
The deliverable describes a set of APIs used to call the main GAAA-TK se .
Lbe requested via the Policy Enforcement Point (PEP) or directly from the XACM
The TVS API provides rich functionality for handling token used for access control d signal
n. section 5 is devoted to the GAAA-TK library setup and configuratio
The following are suggested further GAAA-TK developments: adding an AuthZ request input fo
iguration file, providing an acontent checking, moving the library configuration to an XML conf
installation procedure together with the domain related keys installation (or generation), adding IBC supp
managing token keys distribution, adding support for pilot token type 4 (i.e. allowing GRI bound security co
istribution between domains), adding a Web Services id
external AuthZ request c
context in XML data
Based on the curre
focus on extending the GAAA Toolkit functionality an

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosphorus-WP4-M.4.1>
7
[1] R ., G. Gross, L. Gommans, J. Vollbrecht, D. Spence, "Generic AAA Architecture,”
E 2903, Internet Engineering Task Force, August 2000. - ftp://ftp.isi.edu/in-
] RF Framework" J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G.
G Holdrege, D. Spence, August 2000. - ftp://ftp.isi.edu/in-
n
[3] D C. de Laat, "Authorisation Infrastructure for On-Demand Network
R EE/ACM International Conference on Grid Computing (Grid 2008),
Tsukuba, Japan, Sept. 29 - Oct. 1, 2008. Accepted paper.
Y. Demchenko, A. Wan, M. Cristea, R. Meijer, C. de Laat, "Multi-domain Lightpath
Autho Systems, Special issue on OptiPuter.
A
[5] V vailable http://packcs-e0.scai.fhg.de/viola-project/
[6] D . Mulmo, “Using Workflow for Dynamic
S rcelona, Sept. 28-30,
2
] A ature schemes. In G.R. Blakley and D. Chaum,
H. Tanaka. A realization scheme for the identity-based cryptosystem. In C. Pomerance, editor,
Advances in Cryptology - Proceedings of CRYPTO'87, pages 340{349. Springer-Verlag LNCS 293,
1988.
[9] "Token-based authorization of connection oriented network resources", by Leon Gommans, Franco
Travostino, John Vollbrecht, Cees de Laat, and Robert Meijer, in Proceedings of GRIDNETS, San Jose,
CA, USA, Oct 2004.
References
FC2903 Laat de, C
xperimental RFC
notes/rfc2903.txt
[2 C 2904 - "AAA Authorization
ross, B. de Bruijn, C. de Laat, M.
otes/rfc2904.txt
emchenko Y, A. Wan, M. Cristea,
source Provisioning", The 9th IEe
[4] Gommans, L., L. Xu ,
rization using Tokens", Future Generation Computer
epted paper. cc
iola Meta Scheduling Service Project. [Online]. A
emchenko, Y., L. Gommans, C. de Laat, A. Taal, A. Wan, O
ecurity Context Management in Grid-based Applications,” Grid2006 Conf. Ba
006.
[7 . Shamir. Identity-based cryptosystems and sign
editors, Advances in Cryptology - Proceedings of CRYPTO'84, pages 47{53. Springer-Verlag LNCS
196, 1985.
[8]

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosphorus-WP4-M.4.1>
Appendix A Acronyms
AAA Authentication, Authorisation, Accounting
AAI Authentication, Authorization Infrastructure
ACL Access Control List
AuthZ Authorization
AuthN Authentication
CRP Complex Resource Provisioning
CVS Credential Validation Services
DCAS Domain Site Central Authorisation Service
e2e end to end
EGEE Enabling Grids for E-sciencE (European Grid Project)
GAAA-AuthZ Generic AAA Authorisation Framework
GAAAPI Generic Authentication/Authorisation Application Programming Interface
GEANT2 Pan-European Gigabit Research Network
gLite EGEE Grid middleware
GMPLS Generalized MPLS (MultiProtocol Label Switching)
GSI Grid Security Infrastructure
GT4 Globus Toolkit Version 4 (Web-Service based)
IdM Identity Manager
IdP Identity Provider
NREN National Research and Education Network
NRP Network Resource Provisioning
OLPP Optical LightPath Provisioning
NRPS Network Resource Provisioning System
OHRM Obligation Handling Reference Model
OSCARS On-demand Secure Circuits and Advance Reservation System
PAP Policy Authority Point
PDP Policy Decision Point
PEP Policy Enforcement Point
PIP Policy Information Point
PKC X.509 Public Key Certificate
PKI Public Key Infrastructure
QoS Quality of Service
SAAS Shibboleth Attribute Authority Service

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
63
SAML Security Assertion Markup Language
SCAS Site Central Authorisation Service
S-R-A (-E) Subject – Resource – Action (- Environment) in relation to the XACML policy and context definition
SSO Single Sign-On
TBN Token Based Networking
TBS Token Based Switch
TB Token Builder
TVS Token Validation Service
ship Service
UNICORE European Grid Middleware (UNIform Access to COmpute REsources)
VLAN Virtual LAN (as specified in IEEE 802.1p)
A
VPN ivate Network



VO Virtual Organisation
VOMS Virtual Organization Member
VIOL A German project funded by the German Federal Ministry of Education and Research (Vertically
Integrated Optical Testbed for Large Applications in DFN)
Virtual Pr
XACML eXtensible Access Control Markup Language
XML eXtensible Markup Language

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
64
Appe and
B.1

ndix B AuthZ Ticket XML Schema
Examples
Current AuthZ ticket schema (version 0.3)

<?xml tandalone="yes"?> version="1.0" encoding="UTF-8" s
<xs:sc /2001/XMLSchema" xmlns:AAA="http://www.aaauthreach.org/ns/#AAA" hema xmlns:xs="http://www.w3.org
targetNamespace="http://www.aaauthreach.org/ns/#AAA" elementFormDefault="qualified">
<xs:element name="AuthzTicket" type="AAA:AuthzTicketType"/>
<xs:complexType name="AuthzTicketType">
<xs:sequence>
<xs:element name="Decisions" type="AAA:DecisionsType"/>
nsType" minOccurs="0"/> <xs:element name="Conditions" type="AAA:Conditio
Occurs="0"/> <xs:element name="Subject" type="AAA:SubjectType" min
minOccurs="0"/> <xs:element name="Resources" type="AAA:ResourcesType"
<xs:element name="Actions" type="AAA:ActionsType" minOccurs="0"/>
<xs:element name="Delegation" type="AAA:DelegationType" minOccurs="0"/>
nt name="Obligations" type="AAA:ObligationsType" minOccurs="0"/> <xs:eleme
</xs:sequence>
<xs:attribute name="TicketID" type="xs:hexBinary" use="required"/>
<xs:attribute name="SessionID" type="xs:string" use="required"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
</xs:complexType>
<xs:complexType name="DecisionsType">
<xs:sequence>
<xs:element name="Decision" type="AAA:DecisionType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
me="DecisionType"> <xs:complexType na
<xs:attribute name="Result" type="xs:anyURI" use="required"/>
<xs:attribute name="ResourceID" type="xs:anyURI" use="optional"/>
type="xs:string" use="optional"/> <xs:attribute name="PolicyRef"
</xs:complexType>
<xs:complexType name="ConditionsType">
<xs:sequence>
<xs:element name="ConditionAuthzSession" type="AAA:ConditionAuthzSessionType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="NotBefore" type="xs:dateTime" use="optional"/>
<xs:attribute name="NotOnOrAfter" type="xs:dateTime" use="optional"/>
<xs:attribute name="renewal" type="xs:string" use="optional"/>
</xs:complexType>
<xs:complexType name="ConditionAuthzSessionType">

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
65
<xs:sequence>
<xs:element ref="AAA:SessionData" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="SessionID" type="xs:string" use="required"/>
</xs:complexType>
<xs:element name="SessionData" type="xs:anyType"/>
<xs:complexType name="SubjectType">
<xs:sequence>
<xs:element ref="AAA:SubjectID"/>
<xs:element name="SubjectConfirmation" type="AAA:SubjectConfirmationType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="SubjectAttribute" type="AAA:SubjectAttributeType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="AAA:SubjectContext" minOccurs="0"/>
</xs:sequence >
<xs:attribute name="Id" type="xs:anyURI " use="optional"/>
</xs:complexType>
<xs:element name="SubjectID" type="xs:string"/>
<xs:complexType name="SubjectConfirmationType">
<xs:sequence>
<xs:element ref="AAA:SubjectConfirmationData" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Method" type="xs:anyURI" use="optional"/>
</xs:complexType>
<xs:element name="SubjectConfirmationData" type="xs:anyType"/>
<xs:element name="SubjectAttributeType" type="xs:string"/>
<xs:complexType name="SubjectAttributeType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="AttributeId" type="xs:double" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="SubjectContext" type="xs:string"/>
<xs:complexType name="ActionsType">
<xs:sequence>
<xs:element ref="AAA:Action" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Action" type="xs:anyURI"/>
<xs:complexType name="ResourcesType">
<xs:sequence>
<xs:element ref="AAA:Resource" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Resource" type="AAA:ResourceType"/>
<xs:complexType name="ResourceType" mixed="true">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0"
maxOc ounded"/> curs="unb
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!--
******* entation for TBN simple message * Implem
********* ********************** ************
******** ins only obligatory elements AzTicket/Decisions/Decision/Conta Resources/Resource *********
******** and proprietary Resource attributes (as extensible) ResourceID, Key, Port
**************

<xs:complexType name="ResourceType" mixed="true">
<xs:sequence>
<xs:element name="LRI" type="AAA:LRIType"/>
<xs:element name="TokenKey" type="xs:string"/>
<xs:element name="Ports" type="AAA:Ports"/>
<xs:element name="ApplicationFlow" type="AAA:ApplicationFlowType"/>
</xs:sequence>
<xs:attribute nam e="ResourceID" type="xs:anyURI" use="required"/>

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
67
</AAA:Decisions>
<!-- SAML mapping: <AuthorizationDecisionStatement Decision="*" PolicyRef="*" Resource="*"> -->
<AAA:Resources><AAA:Resource ResourceID="http://www.aaaarch.org/TBS/ForceG">
<AAA:LRI purpose="String">text</AAA:LRI>
<AAA:TokenKey>String</AAA:TokenKey>
<AAA:Ports>
<AAA:port1>String</AAA:port1>
<AAA:port2>String</AAA:port2>
</AAA:Ports>
<AAA:ApplicationFlow>
<AAA:IPpacketMask>String</AAA:IPpacketMask>
<AAA:IPsource>String</AAA:IPsource>
<AAA:IPdestination>String</AAA:IPdestination>
<AAA:PortSource>String</AAA:PortSource>
<AAA:PortDestination>String</AAA:PortDestination>
</AAA:ApplicationFlow>
</AAA:Resource></AAA:Resources>
<AAA:Actions>
<AAA:Action>cnl:actions:CtrlInstr</AAA:Action> <!-- SAML mapping: <Action> -->
<AAA:Action>cnl:actions:CtrlExper</AAA:Action>
</AAA:Actions>
<AAA:Subject Id="subject">
<AAA:SubjectID>WHO740@users.collaboratory.nl</AAA:SubjectID>
<!-- SAML mapping: <Subject>/<NameIdentifier> -->
<AAA:SubjectConfirmationData>
IGhA11vwa8YQomTgB9Ege9JRNnld84AggaDkOb5WW4U=</AAA:SubjectConfirmati onData>
<!- SAML mapping: EXTENDED <SubjectConfirmationData/> --> -
<AAA:Role>analyst</AAA:Role>
<!-- SAML mapping:
<Evidence>/<Assertion>/<AttributeStatement>/<Assertion>/<Attribute>/<AttributeValue> -->
<AAA:SubjectContext>CNL2-XPS1-2005-02-02</AAA:SubjectContext>
<!-- SAML mapping:
<Evidence>/<Assertion>/<AttributeStatement>/<Assertion>/<Attribute>/<AttributeValue> -->
</AAA:Subject>
<AAA:Delegation MaxDelegationDepth="3" restriction="subjects">
<!-- SAML mapping: LIMITED <AudienceRestrictionCondition> (SAML1.1),
or <ProxyRestriction>/<Audience> (SAML2.0) -->
<AAA:DelegationSubjects>
<AAA:SubjectID>team-member-2</AAA:SubjectID>
<AAA:SubjectID>team-member-1</AAA:SubjectID>
</AAA:DelegationSubjects>
</AAA:Delegation>
<AAA:Conditions NotBefore="2006-06-08T12:59:29.912Z"
NotOnOrAfter="2006-06-09T12:59:29.912Z" renewal="no">
SA ping: <Conditions NotBefore="*" NotOnOrAfter="*"> --> <!-- ML map
<AAA:ConditionAuthzSession PolicyRef="PolicyRef-GAAA-RBAC-test001" SessionID="JobXPS1-2006-001">
<!-- SAML mapping: EXTENDED <SAMLConditionAuthzSession PolicyRef="*" SessionID="*"> -->
<AAA:SessionData>put-session-data-Ctx-here</AAA:SessionData>
<!-- SAML mapping: EXTENDED <SessionData/> -->
</AAA:ConditionAuthzSession>
</AAA:Conditions>
<AAA:Obligations>
<AAA:Obligation>put-policy-obligation(2)-here</AAA:Obligation>
<!-- SAML mapping: EXTENDED <Advice>/<PolicyObligation> -->
<AAA:Obligation>put-policy-obligation(1)-here</AAA:Obligation>
:O ions> </AAA bligat
</AAA:AuthzTicket>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo> ... </ds:SignedInfo>
<ds:SignatureValue>e4E27kNwEXoVdnXIBpGVjpaBGVY71Nypos...</ds:SignatureValue>
</ds:Signature>

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
69

Appendix C AuthZ Token XML Schema
Current AuthZ token schema.


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<x em ns:xs="http://www.w3.org/2001/XMLSchema" xmlns:AAA="http://www.aaauthreach.os:sch a xml rg/ns/#AAA"
targetNamespace="http://www.aaauthreach.org/ns/#AAA" elementFormDefault="qualified">
<xs:element name="AuthzToken" type="AAA:AuthzTokenType"/>
<xs:complexType name="AuthzTokenType">
<xs:sequence>
<xs:element ref="AAA:TokenValue" minOccurs="0"/>
<xs:element name="Conditions" type="AAA:ConditionsType" minOccurs="0"/>
<xs:element name="Domains" type="AAA:DomainsType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="TokenID" type="xs:hexBinary" use="required"/>
<xs:attribute name="SessionID" type="xs:string" use="required"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
</xs:complexType>
<xs:complexType name="ConditionsType">
<xs:attribute name="NotBefore" type="xs:dateTime" use="optional"/>
<xs:attribute name="NotOnOrAfter" type="xs:dateTime" use="optional"/>
</xs:complexType>
<xs:element name="TokenValue" type="xs:anyURI"/>
<xs:complexType name="DomainsType">
<xs:sequence>
<xs:element name="Domain" type="AAA:DomainType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="DomainType">
<xs:sequence>
<xs:element name="AuthzToken" type="AAA:AuthzTokenType"/>
<xs:element name="KeyInfo" type="AAA:KeyInfoType" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="domainId" type="xs:anyURI" use="optional"/ >
</xs:complexType>
xs:complexType name="KeyInfoType" mixed="true"> <
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="keytype" type="xs:string" use="optional"/>
</xs:complexType>
</xs:schema>

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
73
<Attribute At ributeId="http://authz-interop.org/AAA/xacml/subject/sut bject-confdata"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer="http://testbed.ist-
phosphorus.eu/phosphorus/aaa/AttributeIssuer" IssueInstant="2008-07-29T14:34:44.796000000+02:00">

<AttributeValue>IGhA11vwa8bUktYhuU9que+d4XLUvJFHrtDC/OE3Ui1bxtmuCxLldw==</AttributeValue>
</Attribute>
<Attribute AttributeId="http://authz-interop.org/AAA/xacml/subject/subject-role"
DataTyp "http://www.w3.org/2001/XMLSchema#string" Issuer="http://testbed.ist-e=
phosphorus.eu/phosphorus/aaa/AttributeIssuer" IssueInstant="2008-07-29T14:34:44.796000000+02:00">
<AttributeValue>researcher</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#anyURI" Issuer="http://testbed.ist-
phosphorus.eu/phosphorus/aaa/AttributeIssuer" IssueInstant="2008-07-29T14:34:44.765000000+02:00">
<AttributeValue>http://testbed.ist-phosphorus.eu/viola/harmony</AttributeValue>
</Attribute>
</Resource>
<Action>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer="http://testbed.ist-
phosphorus.eu/phosphorus/aaa/AttributeIssuer" IssueInstant="2008-07-29T14:34:44.765000000+02:00">
<AttributeValue>create-path</AttributeValue>
</Attribute>
</Action>
</Request>


c) Example Response message with returned decision “Permit”
<Response>
<Result ResourceId="http://testbed.ist-phosphorus.eu/viola/harmony">
<Decision>Permit</Decision>
<Status>
<StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
</Status>
</Result>
</Response>

D.2 Example 2 - XACML policy and corresponding
es
source and target TNA’s.
request/response messag
b) Policy example evaluating user roles and network
<Policy PolicyId="http://testbed.ist-phosphorus.eu/viola/harmony/demo010/policy2:tna"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
<Description>Permits reservation for a selected set of TNA address ranges: 10.3.*, 10.4.*,
10.7.*, 10.8.* (10.3.1.*, 10.4.1.*, 10.7.3.*, 10.7.12.*, 10.7.12.*, 10.7.13.*, 10.8.1.*)
and Permit actions for Phosphorus testbed users with specific roles</Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-
equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#anyURI">http://testbed.ist-
phosphorus.eu/viola/harmony</AttributeValue>

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
75
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">10.3.</AttributeValue>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-
one-and-only">
<ResourceAttributeDesignator AttributeId="http://authz-
interop.org/AAA/xacml/resource/source" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-
match">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">10.4.</AttributeValue>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-
one-and-only">
<ResourceAttributeDesignator AttributeId="http://authz-
interop.org/AAA/xacml/resource/source" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-
match">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">10.7.</AttributeValue>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-
one-and-only">
<ResourceAttributeDesignator AttributeId="http://authz-
interop.org/AAA/xacml/resource/source" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-
match">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">10.8.</AttributeValue>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-
one-and-only">
<ResourceAttributeDesignator AttributeId="http://authz-
interop.org/AAA/xacml/resource/source" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Apply>
</Apply>
<!-- target TNA -->
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:or">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-
match">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">10.3.</AttributeValue>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-
one-and-only">
<ResourceAttributeDesignator AttributeId="http://authz-
interop.org/AAA/xacml/resource/target" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-
match">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">10.4.</AttributeValue>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-
one-and-only">
<ResourceAttributeDesignator AttributeId="http://authz-
interop.org/AAA/xacml/resource/target" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-
match">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">10.7.</AttributeValue>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-
one-and-only">

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
76
<ResourceAttributeDesignator AttributeId="http://authz-
interop.org/AAA/xacml/resource/target" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-
match">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">10.8.</AttributeValue>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-
one-and-only">
<ResourceAttributeDesignator AttributeId="http://authz-
interop.org/AAA/xacml/resource/target" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Apply>
</Apply>
</Condition>
</Rule>

<Rule RuleId="http://testbed.ist-phosphorus.eu/viola/harmony/demo010/policy/rule/action-
type/create-path/tna-check-cancel" Effect="Permit">
<Target>
<Subjects>
<Subject>
<SubjectMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">admin</AttributeValue>
<SubjectAttributeDesignator AttributeId="http://authz-
interop.org/AAA/xacml/subject/subject-role" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</SubjectMatch>
</Subject>
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<Action>
<ActionMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">cancel</AttributeValue>
<ActionAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataTyp "http://www.w3.org/2001/XMLSchema#string"/> e=
</ActionMatch>
</Action>
</Actions>
</Target>
<Description>
Checks if TNA address (in a form of string) belongs to special range (10.3.*, 10.4.*,
10.7.*, 10.8.*)
</Description>

<Condition>
<!-- Repeating Condition content removed for easier readability -->
</Condition>

</Rule>

<Rule RuleId="http://testbed.ist-phosphorus.eu/viola/harmony/demo010/policy/rule/action-
type/create-path/tna-check-access" Effect="Permit">
<Target>
<Subjects>
<Subject>
<SubjectMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">researcher</AttributeValue>

GAAA toolkit pluggable components and XACML policy profile for ONRP

Project: Phosphorus
Deliverable Number: D.4.3.1
Date of Issue: 06/08/08
EC Contract No.: 034115
Document Code: <Phosporus-WP4-D.4.3.1>
78
<SubjectAttributeDesignator AttributeId="http://authz-
interop.org/AAA/xacml/subject/subject-role" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</SubjectMatch>
</Subject>
<Subject>
<SubjectMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">professor</AttributeValue>
<SubjectAttributeDesignator AttributeId="http://authz-
interop.org/AAA/xacml/subject/subject-role" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</SubjectMatch>
</Subject>
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<Action>
<ActionMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">activate-path</AttributeValue>
<ActionAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Description>
Checks if TNA address (in a form of string) belongs to special range (10.3.*, 10.4.*,
10.7.*, 10.8.*)
</Description>
<Condition>
<!-- Repeating Condition content removed for easier readability -->
</Condition>
</Rule>
</Policy>


b) XACML request message example:

<Request>
<Subject SubjectCategory="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer="http://testbed.ist-
phosphorus.eu/phosphorus/aaa/AttributeIssuer" IssueInstant="2008-07-29T14:34:44.796000000+02:00">
<AttributeValue>WHO740@users.testbed.ist-phosphorus.eu</AttributeValue>
</Attribute>
<Attribute AttributeId="http://authz-interop.org/AAA/xacml/subject/subject-context"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer="http://testbed.ist-
phosphorus.eu/phosphorus/aaa/AttributeIssuer" IssueInstant="2008-07-29T14:34:44.796000000+02:00">
<AttributeValue>demo041</AttributeValue>
</Attribute>
<Attribute AttributeId="http://authz-interop.org/AAA/xacml/subject/subject-confdata"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer="http://testbed.ist-
phosphorus.eu/phosphorus/aaa/AttributeIssuer" IssueInstant="2008-07-29T14:34:44.796000000+02:00">

<AttributeValue>IGhA11vwa8bUktYhuU9que+d4XLUvJFHrtDC/OE3Ui1bxtmuCxLldw==</AttributeValue>
</Attribute>
<Attribute AttributeId="http://authz-interop.org/AAA/xacml/subject/subject-role"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer="http://testbed.ist-
phosphorus.eu/phosphorus/aaa/AttributeIssuer" IssueInstant="2008-07-29T14:34:44.796000000+02:00">