Authorisation Infrastructurefor

On-Demand Network Resource Provisioning

Yuri Demchenko
System and Network Engineering Group
University of Amsterdam
Grid2008 Conference, 29 September- 1 October 2008, Tsukuba

Outline• AAA/AuthZ Architecture for Optical Network Resource Provisioning (NRP)• AAA/AuthZ mechanisms and functional components to support
multidomain NRP AuthZ ticket for extended AuthZ context management Token Validation Service (TVS) and token-based access control and signalling• XACML-NRP attributes and policy profile• Reference Model for Obligations Handling (OHRM)• Future developments
 Using Identity Based Cryptography (IBC) for building dynamic security associations forprovisioned resources
Background for this research• EU funded Phosphorus Project “Lambda User Controlled Infrastructure for European Research” (ECContract number 034115)• University of Amsterdam SNE Group ongoing research on GAAA-AuthZ – Generic Authentication,
Authorization, Accounting (GAAA) AuthZ Framework
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_2

Optical Network Resource Provisioning (NRP)
NRP as a use case of the general Complex Resource Provisioning (CRP)• ONRP and Network on-demand provisioning• Grid Computing Resource – Distributed and heterogeneous
3 major stages/phases in NRP/CRP operation/workflow• Provisioning consisting of 3 basic steps
 Resource Lookup
 Resource composition (including options) Component resources reservation (in advance), including combined AuthZ/policy

decision, and assigning a global reservation ID (GRI)• Deployment – reservation confirmation and distributing components/domain
configuration (including trusted keys)• Access (to the reserved resource) or consumption (of the consumable
resource)

Now considering two other stages: “decommissioning” and “relocation”• Topic for future research and discussions• Will allows integrating resource provisioning into the upper layer scientificworkflow in more consistent way
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_3

Multidomain Network Resource Provisioning (NRP)

Provisioning sequences

Agent
A
R

IDC/AAA

IDC/AAA

IDC/AAA

PAP

PAP

PAP

PDP

PDP
P
User
Client

TVS

TVS

TVS
PEP

DC/NRPS

DC/NRPS

DC/NRPS

NE

NE

IDC – Interdomain Controller
DC – Domain Controller
NRPS – Network Resource Provisioning
SystemApplication•••

Agent (A)Polling (P)Relay (R)

Token based policy
enforcement

Dest
Host
Control
plane

PEP

Grid2008, 29 September - 1 October 2008, Tokyo

Service
(AAA)
plane

PDP

PEP

NE

AAA

GRI – Global Reservation ID
AuthZ tickets for multidomain
context mngnt

Networkplane

AAA – AuthN, AuthZ, Accounting Server
PDP – Policy Decision Point
PEP – Policy Enforcement Point
TVS – Token Validation Service
KGS – Key Generation Service

AthZ Infrastructure for Network Provisioing

Slide_4

Multi-domain NRP – Domain definition
Domains are defined (as associations of entities) by a common policy undersingle administration, common namespaces and semantics, shared trust,etc.
Domain related security context may include• namespace aware names and ID’s
• policy references/ID’s• trust anchors• authority references• Additionally, each domain may have/create own dynamic/session related
security context (at the reservation and access stages)

Multi-domain NRP AuthZ infrastructure• Multiple policies processing and combination, including obligated/conditional
policy decisions and delegation• Attributes/rules mapping/converting based on inter domain trust management
infrastructure• Policy support for different logical organisation of resources, including possible
constraints on resource combination and interoperation
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_5

AAA/AuthZ mechanisms and functional components to support
multidomain ONRP
The proposed AAA/security mechanisms and functional components to extend generic
AAA AuthZ framework (PEP, PDP, PAP and operational sequences)
Token Validation Service (TVS) to enable token based policy enforcement andsignalling• Can be applied at all Networking layers (Service, Control and Data planes)

AuthZ ticket format for extended AuthZ session management• To allow extended AuthZ decision/security context communication between domains

XACML attributes and policy profile for NRP• Using reach functionality of the XACML policy format for controlling complex network andGrid resources• Can add dynamic path/topology information to policy definition

Policy Obligation Handling Reference Model (OHRM)• Used for account mapping, quota enforcement, accounting, etc.

Identity Based Cryptography (IBC) use for token key distribution in inter-domain
network resource provisioning is being investigated• Targeted for the “deployment” stage

The proposed architecture will allow smooth integration with other AuthZ frameworks ascurrently used and being developed by NREN and Grid community• Can provide basic AAA/AuthZ functionality for each network layer DP, CP, SP

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_6

GAAA Toolkit pluggable AAA/AuthZ components

AzReq ServReq (Srv,Subj,Act))ServReq(Srv,Oblig2)

Resource
NE/GMPLS

AuthZ Gateway(AuthZ Handler)

AzReq(Srv,Subj,Act))XACMLAzResp

PEP

Obligation
Handler

NRPS/

Validate(AuthzToken)

Srv IFAuthZ API

Context
HandlerTTVS

GAAA-AuthZ

The proposed model
intends to comply
with both the generic
AAA-AuthZ framework
and XACML AuthZ
model• ContextHandler functionality
can be extended to support
all communications between
PEP-PDP and with othermodules

XACMLAzResp

XACMLAzReq(S,R,A,E)(AzDcsn,Oblig)
XACMLPolicy

Supports remotecallout in case of
external AuthZ
service DCAS

PDP

PAP

(Target(S,R,A,E),
Rules(S,R,A,E),
Oblig0)TTVS – Ticket and token validation and handling service
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_7

AuthZ ticket/assertion for extended security context
management – Data model (1) - Top elements
Required functionality to support
multidomain provisioning scenarios• Allows easy mapping to SAML and
XACML related elements

Allows multiple Attributes format(semantics, namespaces)
Establish and maintain Trust relations
between domains• Including Delegation

Ensure Integrity of the AuthZ decision• Keeps AuthN/AuthZ context• Allow Obligated Decisions (e.g.
XACML)

Confidentiality• Creates a basis for user-controlled
Secure session

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_8

AuthZ ticket main elements<Decision> element - holds the PDP AuthZ decision bound to the requested resource orservice expressed as the ResourceID attribute.
<Conditions> element - specifies the validity constrains for the ticket, including validity
time and AuthZ session identification and additionally context<ConditionAuthzSession> (extendable) - holds AuthZ session context<Subject> complex element - contains all information related to the authenticated Subject
who obtained permission to do the actions<Role> - holds subject’s capbilities<SubjectConfirmationData> - typically holds AuthN context<SubjectContext> (extendable) - provides additional security or session related information,e.g. Subject’s VO, project, or federation.

<Resources>/<Resource> - contains resources list, access to which is granted by theticket<Actions>/<Action> complex element - contains actions which are permitted for the
Subject or its delegates<Delegation> element – defines who the permission and/or capability are delegated to:another DelegationSubjects or DelegationCommunity• attributes define restriction on type and depth of delegation<Obligations>/<Obligation> element - holds obligations that PEP/Resource should
perform in conjunction with the current PDP decision.
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_9

AuthZ ticket format (proprietary) for extended security context
management<AAA:AuthzTicket xmlns:AAA="http://www.aaauthreach.org/ns/#AAA" Issuer="urn:cnl:trust:tickauth:pep"
TicketID="cba06d1a9df148cf4200ef8f3e4fd2b3"><AAA:Decision ResourceID="http://resources.collaboratory.nl/Philips_XPS1">Permit</AAA:Decision><!-- SAML mapping: <AuthorizationDecisionStatement Decision="*" Resource="*"> --><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:SubjectConfirmationData><!-- 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:DelegationSubjects></AAA:Delegation><AAA:Conditions NotBefore="2006-06-08T12:59:29.912Z" NotOnOrAfter="2006-06-09T12:59:29.912Z" renewal="no"><!-- SAML mapping: <Conditions NotBefore="*" NotOnOrAfter="*"> --><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 EXTENDED: <SessionData/> --></AAA:ConditionAuthzSession></AAA:Conditions><AAA:Obligations><AAA:Obligation>put-policy-obligation(2)-here</AAA:Obligation> <!-- SAML EXTENDED: <Advice>/<PolicyObligation> --><AAA:Obligation>put-policy-obligation(1)-here</AAA:Obligation></AAA:Obligations></AAA:AuthzTicket><ds:Signature> <ds:SignedInfo/> <ds:SignatureValue>e4E27kNwEXoVdnXIBpGVjpaBGVY71Nypos...</ds:SignatureValue></ds:Signature>
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_10

General XML Token Format – Access and Pilot Tokens
Required functionality to support
multidomain provisioning scenarios• Allows easy mapping to SAML and
XACML related elements

Allows multiple Attributes format(semantics, namespaces)
Establish and maintain Trust relations
between domains• Including Delegation

Ensure Integrity of the AuthZ decision• Keeps AuthN/AuthZ context• Allow Obligated Decisions (e.g.
XACML)

Confidentiality• Creates a basis for user-controlled
Secure session

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_11

Pilot Token Types
Type 0 – Access token (refers to the reserved resources context)
Type 1 – Container for communicating the GRI during the reservation stage• Contains the mandatory SessionId=GRI attribute and an optional Condition element

Type 2 – Origin/requestor authenticating token• TokenValue element contains a value that can be used as the authentication value for thetoken origin• TokenValue may be calculated of the GRI (optionally concatenated with the Issuer’s
domainId) by applying e.g. HMAC function with the requestor’s symmetric or private key.

Type 3 – Extends Type 2 with the Domains element that allows collecting domains security
context information when passing multiple domains during the reservation process• Domains’ information may include the previous token and the domain’s trust anchor or
public key.

Type 4 – Used at the deployment stage and can communicate between domains security
context information about all participating in the provisioned lightpath or network
infrastructure resources• Can be used for programming/setting up a TVS infrastructure for consistent access control
tokens processing at the resource access stage

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_12

Access XML token format - Example<AAA:AuthzToken xmlns:AAA="http://www.aaauthreach.org/ns/#AAA"
Issuer="urn:aaa:gaaapi:token:TVS"
SessionId="a9bcf23e70dc0a0cd992bd24e37404c9e1709afb"
TokenId="d1384ab54bd464d95549ee65cb172eb7"><AAA:TokenValue>ebd93120d4337bc3b959b2053e25ca5271a1c17e</AAA:TokenValue><AAA:Conditions NotBefore="2007-08-12T16:00:29.593Z" NotOnOrAfter="200708-13T16:00:29.593Z"/></AAA:AuthzToken>

where
SessionId = GRI (Global Reservation Id)
TokenId – unique identifier (serving for logging and accountability)
TokenValue – generated securely from GRI or AuthzTicket (digital
SignatureValue)• The element <TokenValue> and attributes SessionId and TokenId aremandatory, and the element <Conditions> and attributes Issuer, NotBefore,
NotOnOrAfter are optional• Binary token contains just two values – TokenValue and GRI
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_13

TVS functionality – Access control and signalling
Basic TVS functionality is checking validity of an access token received
from the PEP or AuthZ gateway/service• Extended TVS functionality allow token re-building when requesting service
from the next domain• Additionally, TVS may be required to support token or token key distribution at
the reservation stage or at the stage of the reserved resource deployment

TVS supports pilot tokens handling functionality used during thereservation stage• Can be used for building dynamic security association of the reserved
resources

Token building (TB) function generates the token as derivative from the
GRI and token key (which can also be generated based on GRI)
• Additionally, TB should allow generating token dynamically using token key andvariable dataflow data, e.g. IP packets payload as in case of TBS-IP

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_14

TVS Implementation (using shared secret)
TVS is implemented as a component of the GAAA Toolkit Java library• Supports token based AuthZ enforcement mechanism and signalling• TVS related classes are organised as a org.aaaarch.gaaapi.tvs package. Allinterfaces are supported by corresponding method of the TVS.java class• Can be integrated into the target network provisioning systems and applications,in particular OSCARS and DRAGON• Important practical convention
 GRI is generated in the first domain or by the Reservation service

The token generation and handling model is based on the shared secret
HMAC-SHA1 algorithm:
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)

This algorithm allows for chaining token generation and validation process
GRI-TokenKey-TokenValue => LRI-l_TokenKey-l_Token

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_15

XACML-NRP Profile
XACML Authorisation Interoperability profile for Network Resource
Provisioning•••

Defines a number of Subject, Resource, Action, Environment attributes
used in the XACML policy definition
Defines policy obligations format and handling model
Recent update (July 2008) http://staff.science.uva.nl/~demch/projects/aaauthreach/draft-interop-xacml-nrpprofile-012.pdf•••

Also a part of the Phosphorus project D4.3.1 deliverable
Reference implementation in the GAAA-TK library
Considered as an extension of the XACML-Grid profile“An XACML Attribute and Obligation Profile for Authorization Interoperability in
Grids" (Joint project by EGEE, OSG, GT). Version 1.0, May 16, 2008 -https://edms.cern.ch/document/929867/1
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_16

XACML Policy format
XACML standard specifies XACML policy
format and XACML request/response
messages

XACML Policy

Rule Combination
Algorithm

Target{S, R, A, (E)}

Policy consists of Policy Target and Rules• Policy Target is defined for the tuple
Subject-Resource-Action (-Environment)• Policy Rule consists of Conditions and may
contain Obligations• Obligation defines actions to be taken by PEP
on Policy decision by PDP

Policy obligation use examples• Account mapping• Quota or credit assignment• Logging, accounting
Grid2008, 29 September - 1 October 2008, TokyoXACML Policy

AthZ Infrastructure for Network Provisioing

Policy Target{S, R, A, (E)}

PolicySet
Rule ID#1
Policy{Rules}Rule Target{S, R, A}…

Condition
AttrDesignat

Policy{Rules}Match List

Obligations
Rule ID#n
Obligations
Slide_17

XACML Request message - Example<xacml-context:Request xmlns:xacml="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xacmlcontext="urn:oasis:names:tc:xacml:1.0:context" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context aaa-msg-xacml-01.xsd"><xacml-context:Subject Id="subject"
SubjectCategory="urn:oasis:names:tc:xacml:1.0:subjectcategory:access-subject"><xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer=" admin@gaaa.virtlab.nl "><xacml-context:AttributeValue>WHO740@users.project.organisation.nl</xacmlcontext:AttributeValue> </xacml-context:Attribute><xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-confdata"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer=" admin@gaaa.virtlab.nl "><xacml-context:AttributeValue>2SeDFGVHYTY83ZXxEdsweOP8Iok)yGHxVfHom90</xacmlcontext:AttributeValue> </xacml-context:Attribute><xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-role"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer=" admin@gaaa.virtlab.nl "><xacml-context:AttributeValue>Analyst</xacml-context:AttributeValue></xacml-context:Attribute> </xacml-context:Subject><xacml-context:Resource><xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer="admin@gaaa.virtlab.nl"><xacml-context:AttributeValue>Resource-ID-here</xacml-context:AttributeValue></xacml-context:Attribute></xacml-context:Resource><xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer="admin@gaaa.collaboratory.nl"><xacml-context:AttributeValue>assign-time</xacml-context:AttributeValue></xacml-context:Attribute></xacml-context:Action> </xacml-context:Request>
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_18

Subject related Attributes
Attribute name

Attribute ID

Full XACML attributeId semantics(ns-prefix = http://authz-interop.org/nrp/xacml)

Subject ID

subject-id{ns-prefix} /subject/subject-id
http://authz-interop.org/nrp/xacml/subject/subject-id

Subject confirmation

subject-confdata

http://authz-interop.org/nrp/subject/subject-confdata

Subject context

subject-context

http://authz-interop.org/nrp/subject/subject-context

Subject groupsubject-grouphttp://authz-interop.org/nrp/subject/subject-group

Subject role

subject-role

http://authz-interop.org/nrp/subject/subject-role

Subject federation

federation

http://authz-interop.org/nrp/subject/federation

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_19

Resource related attributes
Attribute name

Attribute ID

Full XACML attributeId semantics(ns-prefix = http://authzinterop.org/nrp/xacml)

Domain ID

domain-id{ns-prefix} /resource/domain-id

Subdomain

subdomain{ns-prefix} /resource/sub-domain

VLAN

vlan

{ns-prefix} /resource/vlan

TNA

tna (+ tna-prefix){ns-prefix} /resource/tna-prefix/tna

Node

node

{ns-prefix} /resource/nodeLinklink-id{ns-prefix} /resource/link-id

avrDelaydelay{ns-prefix} /resource/delay

maxBW

bandwidth-max{ns-prefix} /resource/bandwidth

Resource typeresource-type{ns-prefix} /resource/resource-type({ns-prefix} /resource/device)

Resource
federation

federation{ns-prefix} /resource/federation

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

•
•
•
•
•
•
•
•
•

•

Domain ID (network
domain)Subdomain (orrelationship)
VLAN
Node or TNA and TNA
prefix, orInterface 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
domainFederation that defines anumber of domains or
nodes sharing common
policy and attributes

Slide_20

XACML Obligations - Definition
Policy Obligation is one of the policy enforcement mechanisms• Obligations are a set of operations that must be performed by the PEP in
conjunction with an authorization decision [XACML2.0]

Obligations semantics is not defined in the XACML policy language but left tobilateral agreement between a PAP and the PEP
PEPs that conform with XACMLv2.0 are required to deny access unless they
understand and can discharge all of the <Obligations> elements associated withthe applicable policy
Element <Obligations> / <Obligation>• The <Obligation> element SHALL contain an identifier (in the form of URI) for the
obligation and a set of attributes that form arguments of the action defined by the
obligation. The FulfillOn attribute SHALL indicate the effect for which this obligationmust be fulfilled by the PEP

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_21

XACML Obligations – Implementation suggestions
Obligation = Apply (TargetAttribute, Operation (Variables)), or
Obligation = Apply (TargetAttribute, Operation (Variables), Chronicle)

Obligations enforcement scenarios• Obligations are enforced by PEP at the time of receiving obligated AuthZ
decision from PDP• Obligations are enforced at later time when the requestor accesses the resourceor service• Obligations are enforced before or after the resource or service
accessed/delivered/consumed

Obligation handling model proposed in the process of interoperability
workshop between OSG, EGEE, and Globus• ObligationId (of type URI) has to be mapped to a specific handler that is calledby the PEP• Obligation parameter values are passed to handler• Handler returns True/False that determines PEP’s Permit/Deny
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_22

Proposed Obligations Handling Reference Model
Resource Site
ServReq(Srv,Oblig2)
ServReq(Srv,An,Az)

1

Service/Resource

20

AuthZ Gateway(AuthZ Handler)

AzReq(Srv,Subj,Act))

Resource
ObligHdlr(OH-R)

19

Rsr Environm, state

AzResp(Dcsn,Oblig2)

2

PEP

17
18

Obligation
Handler(OH-PEP)

State DB
(UsageController)

16
CVS(extern)

XACMLAzResp(Dcsn,Oblig1)

Context
Handler

XACMLAzReq(S,R,A,E)

3
SAML-XACML
RR

4

5

WSDL AuthZ PT(SOAP/SSL)

SAMLXACMLReq(S,R,A,E)
15

SAMLXACMLResp(Decsn,Oblig)

PEP – Policy Enforcement Point
PDP – Policy Decision Point
PAP – Policy Authority Point
OH – Obligation Handler
CtxHandler – Context Handler(S, R, A, E) – components of the AuthZ
request (Subject, Resource, Action,
Environment)

Site Central AuthZ
Service (SCAS)

14

6

Generic AuthZ service model

SAML-XACMLRRXACMLAzResp(Dcsn,Oblig1)

7
PIP(Ctx Hdlr)

XACMLAzReq(S,R,A,E)
8

12
13

11

Obligation
Handler(OH-PDP)State DB
(UsageController)

XACMLAzResp(Dcsn,Oblig0)
9

PDP

PAP
10

Grid2008, 29 September - 1 October 2008, TokyoXACMLPolicy(Target(S,R,A,E),
Rules(S,R,A,E),
Oblig0)AthZ Infrastructure for Network Provisioing

Slide_23

Obligations Handling Stages
Obligation0 = tObligation => Obligation1 (“OK?”, (Attributes1 v Environments1))=> Obligation2 (“OK?”, (Attributes2 v Environments2))=> Obligation3 (Attributes3 v Environments3)
Obligation0 – (stateless or template)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.
Obligation1 and Obligation 2
Obligations have been handled by Obligation handler at the SCAS/PDP side or at the PEP side,
depending on implementation. Templates or instructions of the Obligation0 are replaced with the real
attributes in Obligation1/2, e.g. in a form of “name-value” pair.
• The result of Obligations processing/enforcement is returned in a form of modified
AuthzResponce (Obligation1) or global Resource environment changes• 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.
• Note. Obligation1 handling at the SCAS or PDP side allows stateful PDP/SCAS.
Obligation3
Final stage when an Obligation actually takes effect (Obligations “termination”). This is done by the
Resource itself or by services managed/controlled by the Resource.

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_24

XACML Obligations – Examples of expression for pool accountmapping in Grid – Option 1 (simple, used in XACML-Grid)<!-- Obligations format option 1 (simple): UID, GID explicitly mentioned as
separate XML elements inside AttributeAssignment element --><xacml:Obligations><xacml:Obligation
ObligationId=http://authz-interop.org/xacml/obligation/uidgid
FulfillOn="Permit"><xacml:AttributeAssignment
AttributeId=http://authz-interop.org/xacml/attribute/posix-uid
DataType="http://www.w3.org/2001/XMLSchema#integer">
2501</xacml:AttributeAssignment><xacml:AttributeAssignment
AttributeId=http://authz-interop.org/xacml/attribute/posix-gid
DataType="http://www.w3.org/2001/XMLSchema#integer">
2101</xacml:AttributeAssignment></xacml:Obligation><xacml:Obligations>

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_25

XACML Obligations – Examples of expression for poolaccount mapping in Grid – Option 2<Obligations><Obligation ObligationId="http://authz-interop.org/xacml/obligation/map.poolaccount"
FulfillOn="Permit"><!-- Specifies to what kind of attribute the next ‘map.to’ action is applied to --><AttributeAssignment
AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute: requesting-subject"
DataType="http://www.w3.org/2001/XMLSchema#string">&lt;SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string"/&gt;</AttributeAssignment><!-- This is actual account attribute name/value to which it should be mapped --><AttributeAssignment
AttributeId="http://authz-interop.org/xacml/obligation/attribute/uidgid"
DataType="http://www.w3.org/2001/XMLSchema#string">&lt;UnixId DataType="http://www.w3.org/2001/XMLSchema#string"&gt;okoeroo&gt;UnixId&gt;&lt; GroupPrimary DataType="http://www.w3.org/2001/XMLSchema#string"&gt;computergroup&gt;GroupPrimary&gt;&lt;GroupSecondary DataType="http://www.w3.org/2001/XMLSchema#string"&gt;
datagroup&gt;GroupSecondary&gt;</AttributeAssignment></Obligation></Obligations>
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_26

Implementation – GAAA-TK pluggable Java library• All proposed AuthZ mechanisms and service components are
implemented as the GAAA Toolkit pluggable Java library (GAAA-TK) Uses best of the gLite (and Globus Toolkit) AuthZ service implementation
 Supports XACML policy profile and SAML-XACML profile AuthZ service

protocol Part of the Phosphorus project deliverable D.4.3.1 - "GAAA toolkit pluggable
components and XACML policy profile for ONRP“
http://staff.science.uva.nl/~demch/worksinprogress/Phosphorus-WP4-D4.3.1-GAAATK-library-NRP-v02.pdf• Integrated into the Phosphorus project Network Service Plane (NSP)
test-bed and uses simple XACML policy model• Currently being integrated into Grid-enabled GMPLS Control Plane
service (Phosphorus project) that motivates a number of the specificcross-domain use case scenarios

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_27

Future developments• Defining network topology aware XACML-NRP policy model• Combining network and Grid resources into one provisioning and AuthZ
workflow/session• Extend AuthZ session management model and related AuthZ ticket
functionality and XACML policy model to support multidomain
reservation process and (restricted) delegation• GAAA-TK library interoperability and integration with major Grid
middleware and GN2/NRENs eduGAIN AAI• Using Identity Based Cryptography (IBC) for cross-domain trust
relations management

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_28

PKI vs Identity Based Cryptography (IBC)
Uses publicly known remote entity’s identity as a public key to send encrypted message
or initiate security session• Idea was proposed by Shamir in 1984 as an alternative to PKI and implementation by Dan
Boneh and Matthew K. Franklin in 2001
• Identity can be email address, domain name, IP address• Allows conditional private key generation

Requires infrastructure different from PKI but domain based (doesn’t require trusted 3rdparty outside of domain)• Parties may encrypt messages (or verify signatures) with no prior distribution of keys
between individual participants• Private key generation service (KGS)
Generates private key to registered/authenticated users/entities
 To operate, the KGS first publishes a master public key, and retains the corresponding master
private key (referred to as master key).
 Given the master public key, any party can compute a public key corresponding to the identity ID
by combining the master public key with the identity value.
• Exchange inter-domain trust management problem to intra-domain trust
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_29

Identity Based Cryptography (IBC) - Operation
Four algorithms form a complete IBE system (asproposed by Dan Boneh and Matthew K.
Franklin):
Setup: This algorithm is run by the PKG one time forcreating the whole IBE environment.
• The master key is kept secret and used toderive users' private keys, while the systemparameters are made public. It accepts asecurity parameter k (i.e. binary length of
key material) and outputs:• A set P of system parameters, including themessage space and ciphertext space M andC, a master key Km (master) .
Extract: This algorithm is run by the PKG when auser requests his private key.
• It takes as input P, Km and an identifier
ID={0,1} and returns the private key D foruser ID.
• Requires strong authentication and out of
IBE model scope
Encrypt: Takes P, a message m={M} and ID={0,1}and outputs the encryption c={C}.
Decrypt: Accepts d, P and c={C} and returns m={M}

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_30

Identity Based Cryptography (IBC) infrastructure operation when
distributing token keys in multidomain NRP

Intra-domain Trust
IBC
KGS
IDC/AAA
PAP

GRI

IBC
KGS
IDC/AAA
GRI

PAP

PDP

PDP
TVS

IDC/AAAPAP GRI

IDC/
AAA

PDP
TVS

T
User
Client

IBC
KGS

T

PEP

PEP

DC/NRPS

DC/NRPS

TVS
PEP

T

Service
(AAA)
plane

Dest
Host
Controlplane

DC/NRPS

T
NE

NE

NE

Application

Trust

PKI CA

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Uses intra-domain trust
relation without priorpublic key exchange
Simplifies key
management
problemAllows flexibility indeploying/configuring
intra-domain network
path/infrastructure
Used at deployment
stage

Networkplane

IBC KGS are setup
independently but
publish their publicparameters
Slide_31

Questions and Discussion

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_32

Additional information• Detailed AuthZ ticket data model• SAML-XACML Request-Response format• XACML-NRP profile

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_33

AuthZ ticket/assertion for extended security context
management – Data model (1) - Top elements
Required functionality to support
multidomain provisioning scenarios• Allows easy mapping to SAML and
XACML related elements

Allows multiple Attributes format(semantics, namespaces)
Establish and maintain Trust relations
between domains• Including Delegation

Ensure Integrity of the AuthZ decision• Keeps AuthN/AuthZ context• Allow Obligated Decisions (e.g.
XACML)

Confidentiality• Creates a basis for user-controlled
Secure session

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_34

AuthZ ticket Data model (2) - Mandatory elements

•
•
•
•

TicketID attribute
Decisions element andResourceID attribute
Conditions Element andvalidity attributes
Extensible element
ConditionAuthzSession• Any AuthZ session related
data

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_35

AuthZ ticket Data model (3) – Subject and Delegation elements••

Grid2008, 29 September - 1 October 2008, Tokyo

Subject element to keep AuthN
security context and Subject
Attributes
Delegation element to allow
permissions/AuthZ decisiondelegation to other Subjects orgroups/community

AthZ Infrastructure for Network Provisioing

Slide_36

AuthZ ticket main elements<Decision> element - holds the PDP AuthZ decision bound to the requested resource orservice expressed as the ResourceID attribute.
<Conditions> element - specifies the validity constrains for the ticket, including validity
time and AuthZ session identification and additionally context<ConditionAuthzSession> (extendable) - holds AuthZ session context<Subject> complex element - contains all information related to the authenticated Subject
who obtained permission to do the actions<Role> - holds subject’s capbilities<SubjectConfirmationData> - typically holds AuthN context<SubjectContext> (extendable) - provides additional security or session related information,e.g. Subject’s VO, project, or federation.

<Resources>/<Resource> - contains resources list, access to which is granted by theticket<Actions>/<Action> complex element - contains actions which are permitted for the
Subject or its delegates<Delegation> element – defines who the permission and/or capability are delegated to:another DelegationSubjects or DelegationCommunity• attributes define restriction on type and depth of delegation<Obligations>/<Obligation> element - holds obligations that PEP/Resource should
perform in conjunction with the current PDP decision.
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_37

AuthZ ticket format (proprietary) for extended security context
management<AAA:AuthzTicket xmlns:AAA="http://www.aaauthreach.org/ns/#AAA" Issuer="urn:cnl:trust:tickauth:pep"
TicketID="cba06d1a9df148cf4200ef8f3e4fd2b3"><AAA:Decision ResourceID="http://resources.collaboratory.nl/Philips_XPS1">Permit</AAA:Decision><!-- SAML mapping: <AuthorizationDecisionStatement Decision="*" Resource="*"> --><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:SubjectConfirmationData><!-- 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:DelegationSubjects></AAA:Delegation><AAA:Conditions NotBefore="2006-06-08T12:59:29.912Z" NotOnOrAfter="2006-06-09T12:59:29.912Z" renewal="no"><!-- SAML mapping: <Conditions NotBefore="*" NotOnOrAfter="*"> --><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 EXTENDED: <SessionData/> --></AAA:ConditionAuthzSession></AAA:Conditions><AAA:Obligations><AAA:Obligation>put-policy-obligation(2)-here</AAA:Obligation> <!-- SAML EXTENDED: <Advice>/<PolicyObligation> --><AAA:Obligation>put-policy-obligation(1)-here</AAA:Obligation></AAA:Obligations></AAA:AuthzTicket><ds:Signature> <ds:SignedInfo/> <ds:SignatureValue>e4E27kNwEXoVdnXIBpGVjpaBGVY71Nypos...</ds:SignatureValue></ds:Signature>
Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_38

XACML-NRP Profile – Work in Progress
XACML Authorisation Interoperability profile for Network Resource
Provisioning. Phosphorus technical document••

Recent release (July 2008) http://staff.science.uva.nl/~demch/projects/aaauthreach/draft-interopxacml-nrp-profile-012.pdf
Also a part of the Phosphorus project D4.3.1 deliverable

Related document“An XACML Attribute and Obligation Profile for Authorization Interoperability in Grids"(Joint project by EGEE, OSG, GT). Version 1.0, May 16, 2008.
• https://edms.cern.ch/document/929867/1

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_39

Basic use cases for policy definition in NRP
Use case 1: "User A is only allowed to use user endpoints X, Y and Z", orUse case 2: "User A is only allowed to use endpoints in domain N and M"

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_40

Policy definition assumptions•

Users and resources are described/identified by their unique ID’s and may
have also assigned attributes, e.g.
•Users and resources (domains and endpoints) may be organised/associatedinto administrative and/or security domains or federations
••User authentication is confirmed by issuing AuthZ assertion by trusted AuthN service
or creating user related security context environment of the started process

User authentication may be resulted in the following:•

A user and a resource can be a member of one or multiple associations

Different domains and endpoints participating in network connection (for which
the authorisation is requested) may belong to different federations or security
associations
Only authenticated user may have access to protected resources•

User attrs: user group, role, federation
Resource attrs: domain/subdomain, resource type, level of service

service or process session initiation;
release of the user attributes or credentials;

Depending on the user attributes (federations, groups, roles) the user can be
assigned specific level of serviceTo access a network resources a user identity may need to be mapped to a specific(pool) accountGrid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_41

XACML Policy format
Policy consists of Policy Target and Rules• Policy Target is defined for the tuple
Subject-Resource-Action (-Environment)• Policy Rule consists of Conditions and may
contain Obligations• Obligation defines actions to be taken by PEP
on Policy decision by PDPXACML Policy

XACML Policy
Rule Combination
Algorithm

Target{S, R, A, (E)}

Policy obligation use examples• Account mapping• Quota or credit assignment• Logging, accounting

Policy Target{S, R, A, (E)}

PolicySet
Rule ID#1
Policy{Rules}Rule Target{S, R, A}…

Condition
AttrDesignat

Policy{Rules}Match List

Obligations
Rule ID#n
Obligations

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_42

SAML-XACML Request/Response messages
SAML AssertionXACML Request-Response Messages

XACMLRequest (Resource, Subject, Action, Environment)
XACML Request-Response messages are enclosed into the SAML2.0 Assertion or SAML2.0
protocol messages

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_43

XACML Request message - Example<xacml-context:Request xmlns:xacml="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xacmlcontext="urn:oasis:names:tc:xacml:1.0:context" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context aaa-msg-xacml-01.xsd"><xacml-context:Subject Id="subject"
SubjectCategory="urn:oasis:names:tc:xacml:1.0:subject-category:accesssubject"><xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer=" admin@gaaa.virtlab.nl "><xacml-context:AttributeValue>WHO740@users.project.organisation.nl</xacml-context:AttributeValue></xacml-context:Attribute><xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subjconfdata"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer=" admin@gaaa.virtlab.nl "><xacml-context:AttributeValue>2SeDFGVHYTY83ZXxEdsweOP8Iok)yGHxVfHom90</xacml-context:AttributeValue></xacml-context:Attribute><xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:role"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer=" admin@gaaa.virtlab.nl "><xacml-context:AttributeValue>Analyst</xacml-context:AttributeValue></xacml-context:Attribute></xacml-context:Subject><xacml-context:Resource><xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer="admin@gaaa.virtlab.nl"><xacml-context:AttributeValue>Resource-ID-here</xacml-context:AttributeValue></xacml-context:Attribute></xacml-context:Resource><xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string" Issuer="admin@gaaa.collaboratory.nl"><xacml-context:AttributeValue>assign-time</xacml-context:AttributeValue></xacml-context:Attribute></xacml-context:Action></xacml-context:Request>

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_44

Resource related Attributes – Topology description formats• Actually depends on the used/target topology description format• 3 topology description formats were reviewed
 Phosphorus NSP/WP1 topology description
 NDL by UvA
 OSCARS (currently used)• Examples AuthZ decision request Is user A allowed to access this reserved path given known (multidomain)

network topology?
 Needs to put some topology attributes into the policy definition

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_45

Example of the Resource attributes expression
Attribute name

Attribute ID

Full XACML attributeId semantics(ns-prefix = http://authzinterop.org/nrp/xacml)

Domain ID

domain-id{ns-prefix} /resource/domain-id

Subdomain

subdomain{ns-prefix} /resource/sub-domain

VLAN

vlan

{ns-prefix} /resource/vlan

TNA

tna (+ tna-prefix){ns-prefix} /resource/tna-prefix/tna

Node

node

{ns-prefix} /resource/nodeLinklink-id{ns-prefix} /resource/link-id

avrDelaydelay{ns-prefix} /resource/delay

maxBW

bandwidth-max{ns-prefix} /resource/bandwidth

Resource typeresource-type{ns-prefix} /resource/resource-type({ns-prefix} /resource/device)

Resource
federation

federation{ns-prefix} /resource/federation

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

•
•
•
•
•
•
•
•
•

•

Domain ID (network
domain)Subdomain (orrelationship)
VLAN
Node or TNA and TNA
prefix, orInterface 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
domainFederation that defines anumber of domains or
nodes sharing common
policy and attributes

Slide_46

Administrative vs Security domain vs Security Association• Domains can be considered as administrative and security
 Domains are more static
 Administrative domain is managed by the resource owner (or user

administration)
 Security domain is defined by common trusted identity or attribute
management authority• Security association
 Security association can be created dynamically, e.g. for managing project,resource provisioning agreement– VO or Shibboleth federation are two examples
 Authorisation session

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_47

Subject related Attributes
Attribute name

Attribute ID

Full XACML attributeId semantics(ns-prefix = http://authzinterop.org/nrp/xacml)

Subject ID

subject-id{ns-prefix} /subject/subject-id

Subject confirmation

subject-confdata{ns-prefix} /subject/subject-confdata

Subject Context

subject-context{ns-prefix} /subject/subject-context

Subject groupsubject-group{ns-prefix} /subject/subject-group

Subject role

subject-role{ns-prefix} /subject/subject-role

Subject federation

Federation{ns-prefix} /subject/federation

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_48

Action related Attributes and Enumerated values
Attribute name

Attribute ID

Full XACML attributeId semantics(ns-prefix = http://authz-interop.org/nrp/xacml)

Action ID

action-id{ns-prefix} /action/action-id

Action type

action-type{ns-prefix} /action/action-type/{value}

Attribute name

Enumerated value

XACML attribute value(ns-prefix = http://authz-interop.org/nrp/xacml)

Action typecreate-path{ns-prefix} /action/action-type/create-path

activate-path{ns-prefix} /action/action-type/activate-path

cancel{ns-prefix} /action/action-type/cancel

access{ns-prefix} /action/action-type/access

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_49

Environment related Attributes• Last-domain conformation• Authorisation context
 AuthZ session credentials or AuthZ ticket• Delegation or Obligations from the previous domain
 User ID or group to which access is delegated Actions which need to be taken when processing request or granting access

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_50

Policy Obligations
Suggested policy obligations for multidomain NRP• User identity/account mapping• Intra-domain VLAN mapping• Accounting, logging• Usability

Grid2008, 29 September - 1 October 2008, Tokyo

AthZ Infrastructure for Network Provisioing

Slide_51