Using XML based security
tickets and tokens
forperformance optimisation andsession management

Yuri Demchenko <demch@science.uva.nl>
AIRG, University of Amsterdam

Outline• Fine grained access control with Generic AAA Authorisation framework
and RBAC! Combined push-pull and agent-push models using AuthZ tickets and tokens• GAAAPI implementation detail and ticket/token examples! Collaboratory.nl Authorisation service

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_2

Requirements to Policy based Access Control• Multidomain and inter-institutional• Multiple policy formats• Policy combination• Multiple policy authority• Separate policy management• Dynamic policy association

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_3

(1) Generic AAA Architecture by AIRG (UvA)
Policy based Authorization
decision

Request/Response
Request/Response
Request/Response

Generic AAA
RBE

PolicyPolicyPolicy•Defined by
Resource owner
EGEE-Policy. June 6-7, 2005. Bologna

ASM
ASM
ASM

• Req {AuthNtoken, Attr/Roles,
PolicyTypeId, ConditionExt}• RBE (Req + Policy) =>=> Decision {ResponseAAA,
ActionExt}• ActionExt = {ReqAAAExt,
ASMcontrol}• ResponseAAA ={AckAAA/RejectAAA, ReqAttr,
ReqAuthN, BindAAA(Resource, Id/Attr)}•Translate logDecision => Action•Translate State => LogCondition
XML security tickets and tokens

Slide_4

RBAC: main components and dataflow – XACML model
PEP/AEF - Policy Enforcement
Point (authorisation
enforcement function)
PDP/ADF - Policy Decision
Point (authorisation
decision function)
PIP - Policy Information Point
AA - Attribute Authority
PAP - Policy Authority Point

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_5

Site AuthZ service implementing RBAC and combined pull-push
model
Site Services/Resources
AzTicket

Srv Req

Requestor
Srv Deliv

AzTicket

User
login
IF

PEP1

PEP2

Resource/
Service

AzTicket

Issues to be addressed:• PEP and PDP chaining• Policy combining• Multiple domains

AuthN Req
PDP
types
call

An
Req/
Resp

AuthN
and
IdentMngt

Decision

AuthN Req/Valid

AzReq

Ext
AuthZ
IF

Az
Tickt

PDP
(local)

PDP
PDP
PDP
(Master)

PDP(Secondary)
chain

PDP
(Secondary)chain

ExternPDP
chain

AzTicket

Attribute
Authority

PAP(local)Attr Req/Valid

PAP

EGEE-Policy. June 6-7, 2005. Bologna

PAP

XML security tickets and tokens

Slide_6

Site AuthZ service implementing combined agent and push model
for complex resource
Site Services/Resources
SrvDeliv

SrvDeliv

Resource/
Service
AzTicket

PEP1
(ASM)

Srv Req

Srv Req

Resource/
Service
PEP2(ASM)

Srv Req
AzTicket

AuthN Req/Valid
AuthNReq

AuthN
and
IdentMngt

AuthN Req

Issues to be addressed:• Multi-component andmultidomain resources• Policy push and/or
token based access
control

Srv Req
Srv Req

AzTicket

AzTicket

Srv Req

Requestor
AzTicket

Attribute
Authority

User
login/
AuthZ
IF

PDP
(Driving)

Recursive
PDP
flow/chain

Recurs
PDP
call

Attr Req/Valid

PAP

EGEE-Policy. June 6-7, 2005. Bologna

PDP2(Driving)

PAP

XML security tickets and tokens

Slide_7

Policy based AC: Implementation suggestions•••

PDP and PAP must share common namespace
Policy and respectively PAP should be referenced in the request message explicitly
or known to PEP and PDP a priory
Every PEP in the chain of policy enforcement should take care of the whole request
evaluation/enforcement by calling to a single (master) PDP.
!

•

Only one PDP should provide a final decision on the whole request!

••

PEP should not do multiple decision combination.
However, PEP may have a possibility to request different PDP types based onrequest semantics/namespace and referred policy

When using ticket/token based access control model, the PEP should understandand have a possibility to validate the AuthZ ticket issued by trusted PDP! The AuthZ ticket should have validity and usage restriction and contain
information about the decision and the resource.
For the further validation of the AuthZ tickets/token, the PEP may cache the ticket
locally to speed-up the validation procedure.

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_8

Traditional Access Control model –setting up trust and authority relations• Policy, attributes semantics and namespaces are known a priory to allparticipating partiesoA requestor knows what information to present to adhere to a specific policy
and in what format• PEP and PDP locations are known and interacting parties are known• Trust relations between PDP, AA and resource are established
Resource trusts PDP’s decision that can be delivered to a Resource in aform of AuthzTicket or based on default trust between PEP and Resourceo Root of policy enforcement hierarchy, like in real life, belongs to the resourceownero• This approach is not sufficient for emerging Service Oriented
Architecture (SOA)

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_9

Open policy enforcement model in WSA/SOA using WS-Policy
attachment mechanisms
Services/Resources
AzTicket

Srv Req

Res/
Srv
IF

Requestor
Srv Deliv•

AzTicketResource/
ServicePEP•

WSDL interface

An
Req/
Resp

•

AuthN Req/Valid

AuthN
Attr Req/Valid

AttrAuth

AzReq

AuZ
IF

PDP
PDP
PDP
(Master)

AzTicket•

PolicyReq

PAP (ext.)

PolicyResp

PolicyReq

PAIF

Linking dynamically allcomponents of the access
control system
Policy is attached to any
component of the service
description in WSDL format
Interacting services will
fetch policy document andapply restrictions/rules toelements, which declared
policy compliancerequirements
Provides a basis for mutual
authorisation

PAP

PolicyResp

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_10

Attaching policy to WSDL - Example<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"< …. snip long namespace declaration …. >xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy"
xmlns:cnl="http://cnl.telin.nl/cnl" xmlns:policy="cnl-policy-schema.xsd"
targetNamespace="http://cnl.telin.nl/cnl"><message name="ViewExperimentRequest" wsp:PolicyURIs="cnl-policy-02example.xml"><part name="coordinateX" type="xs:string"/><part name="coordinateY" type="xs:string"/><part name="zoom" type="xs:int"/></message><<< snip >>>>

<wsp:PolicyAttachment ... ><wsp:AppliesTo><x:DomainExpression/> +</wsp:AppliesTo>( <wsp:Policy>...</wsp:Policy> |<wsp:PolicyReference>...</wsp:PolicyReference> ) +<wsse:Security>...</wsse:Security> ?
...
</wsp:PolicyAttachment><wsp:UsingPolicy wsdl:Required="true"/></definitions>
EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_11

Implementation: Authorisation Service operation in a CNL2 Demosystem

3. JNLP

Remote CNL
Instrument

Surabaya
5,10 startSession()
11,14 goLeft()Web
Client
2. JNLP
1. Login

CHEF
Job Mgt.

Instrument
Controller

4. getJobInfo()

6,9 startSession()
12,13 checkAuthZStatus()gAAA Server
7,8 requestDecision()

PDP

Note: we assume SSL TCP connections all over.

EGEE-Policy. June 6-7, 2005. Bologna

PEP

JNLP – Java Network
Launch Protocol
CHEF – Collaborative
tool
Surabaya –Collaborative
Workspaceenvironment

Locations/trust
domains

XML security tickets and tokens

Slide_12

Before deploying security infrastructure
Design conventions and agreements• Key distribution and trust establishing! Currently, in search of simple consistent model• Policy definition and format including subject, attributes/roles, actions
semantics and namespaces! Compatibility with existing formats, e.g. SAML, XACML! Policy format defines/defined by the PDP implementation• Secure credentials/ticket format! Standard vs proprietary• Protocols and Messages format! SOAP + XACML Request/Response! SOAP + SAMLP + XACML

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_13

Session management in CNL2 AuthZ system• Maintaining session is a part of generic RBAC functionality• Session can be started only by authorised Subject/Role! Session can be joined by other less privileged users• SessionID is included into AuthzTicket together with other decisionattributes! Signed AuthzTicket is cached by PEP or PDP• If session is terminated, cached AuthzTicket is deleted! Note: AuthzTicket revocation should be done globally for the AuthZ trust

domainEGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_14

Tickets/Tokens handling in AuthZ system• AuthzTicket is issued by PDP and may be issued by PEP• AuthzTicket must be signed• AuthzTicket contains all necessary information to make local PEP-Triage Request
verification• When using AuthzTokens, AuthzTickets must be cached; Resolution mechanism fromtoken to ticket must be provided
EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_15

Mapping between CNLAuthzTicket, XACML Request/Response andSAML2.0 Authorization Assertion
CNLAuthzTicket
XACMLRequest
PolicyRef{Subject}SubjectID
AuthnToken
JobID

SessionID
IssuerPolicyURIs

Decision
ResourceID{Roles}{Resource}
ResContent{ResAttribs}

Action{ActionAttrs

Environment{EnvirAttrs}

Validity
ValidityTime
ValidityTime
AuthnToken
CommunRestr

Subject
SubjectID
AuthnToken
JobID{Roles}XACMLResponse
ResultResourceID

Resource
ResourceID

Action{Actions}

Decision
StatusStatus/Msg
StatusDetail

Obligations

Obligations{Obligation}

SAML20AuthzAssertion
IssuerSubject
SubjNameID
SubjConfirm

Conditions
ValidityTime
ValidityTime

SAML 2.0 vs SAML 1.1•
Better security features•
Issuer and Subject are top
level elements•
Encrypted elements for
Subject, Attributes, Evidence•
Special profile for XACML

AudienceRstr
Proxy/1Time{Condition}

AdviceSAML11AuthzStat{Assertions}
Decision
OtherInfo
Resource

SAMLAuthzStatm
Subject
Decision
SubjNameID
ResourceID
SubjConfirm

ActionAction{ActionID}{ActionID}

General problems for AuthZ•
Attributes can be placed only
as deep as 5 level down:Assert/AzStm/Evid/AttrAsrt/At
tr/AttrValue•
Ambiguous location for
PolicyURIs and SessionID•
SAML1.1 ConfirmationData
element is extensible type –compatibility problems

Evidence
Evidence
AttrAssertion
AttrAssertion
AuthnToken{Assertion}{Assertions}
AuthnToken{Obligation}

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_16

Using SAML 1.1/2.0 for AuthzTicket expression
SAML 2.0 vs SAML 1.1••••

Better security features
Issuer and Subject are top level elements
Encrypted elements for Subject, Attributes, Evidence
Special profile for XACMLAuthzStatement

General problems for Authorisation assertion• Attributes can be placed only as deep as 5 level down:Assertion/AuthzStatement/Evidence/AttributeAssertion/Attribute/AttributeValue• Ambiguous location for PolicyURIs and SessionID• Ambiguous mapping for XACML/Obligation to SAML/(Condition or Advice)• SAML1.1 ConfirmationData element is an extensible type – compatibility problems• XACML Obligation element! Can be mapped to SAML Condition element or SAML Advice element

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_17

CNLAuthzTicket example – 1011 bytes<cnl:CNLAuthzTicket xmlns:AAA="http://www.AAAarch.org/ns/AAA_BoD"
xmlns:cnl="http://www.aaauthreach.org/ns/#CNL" Issuer="http://www.AAAarch.org/servers/AAA"
PolicyURIs="CNLpolicy01" SessionIndex="JobXPS1-2005-001"
TicketID="c24d2c7dba476041b7853e63689193ad"><!-- Mandatory elements --><cnl:Decision
ResourceID="http://resources.collaboratory.nl/Philips_XPS1">Permit</cnl:Decision><cnl:Validity NotBefore="2005-02-13T01:26:42.699Z" NotOnOrAfter="2005-0214T01:26:42.699Z"/><!-- Additional elements --><cnl:Subject Id="subject"><cnl:SubjectID>WHO740@users.collaboratory.nl</cnl:SubjectID><cnl:SubjectConfirmationData>SeDFGVHYTY83ZXxEdsweOP8Iok</cnl:SubjectConfirmationData><cnl:JobID>CNL2-XPS1-2005-02-02</cnl:JobID><cnl:Role>analyst@JobID;expert@JobID</cnl:Role></cnl:Subject><cnl:Resource>http://resources.collaboratory.nl/Philips_XPS1</cnl:Resource><cnl:Actions><cnl:Action>cnl:actions:CtrlInstr</cnl:Action><cnl:Action>cnl:actions:CtrlExper</cnl:Action></cnl:Actions><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ... </ds:Signature></cnl:CNLAuthzTicket>

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_18

CNLAuthzTicket XML Signature element – 957 bytes(total signed ticket 1968 bytes)<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI=""><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>nrNrZZDiw/2aDnKXFEHSeoixnsc=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>
0IZt9WsJT6an+tIxhhTPtiztDpZ+iynx7K7X2Cxd2iBwCUTQ0n61Szv81DKllWsq75IsHfusnm56
zT3fhKU1zEUsob7p6oMLM7hb42+vjfvNeJu2roknhIDzruMrr6hMDsIfaotURepu7QCT0sADm9If
X89Et55EkSE9oE9qBD8=</ds:SignatureValue><ds:KeyInfo> << ... snip ... >> </ds:KeyInfo></ds:Signature>

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_19

RSA <ds:KeyInfo> element – 1010 bytes(total signed ticket with KeyInfo - 3078 bytes)<ds:KeyInfo><ds:X509Data><ds:X509Certificate>
MIICADCCAWkCBEGX/FYwDQYJKoZIhvcNAQEEBQAwRzELMAkGA1UEBhMCTkwxGTAXBgNVBAoTEENv
bGxhYm9yYXRvcnkubmwxHTAbBgNVBAMTFEFBQXV0aHJlYWNoIFNlY3VyaXR5MB4XDTA0MTExNTAw
NDYxNFoXDTA1MDIxMzAwNDYxNFowRzELMAkGA1UEBhMCTkwxGTAXBgNVBAoTEENvbGxhYm9yYXRv
cnkubmwxHTAbBgNVBAMTFEFBQXV0aHJlYWNoIFNlY3VyaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdDrBhVmr1nD9eqi7U7m4yjIRxfvjAKv33EpuajvTKHpKUgLjbcBC3jNJ4F7a0GiXQ
cVbuF/aDx/ydIUJXQktvFxK0Sm77WVeSel0cLc1hYfUSAg4mudtfsB7rAj+CzNnVdr6RLFpS9YFE
lv5ptGaNGSbwHjU02HnArEGL2K+0AwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBADHKqkOW4mP9DvOi
bMvf4oqXTth7yv8o3Zol7+nqlB9Tqf/bVNLMk8vNo5fWRHbpnHIFFgTk31nrJf8kEZEofvwAeW9s
1gQtYfs1oxvsMPKHxFjJDiZlLkHRViJl/slz5a7pkLqIXLRsPFRziTksemRXB/fT8KDzM14pzQZg
HicO</ds:X509Certificate></ds:X509Data><ds:KeyValue><ds:RSAKeyValue><ds:Modulus>
3Q6wYVZq9Zw/Xqou1O5uMoyEcX74wCr99xKbmo70yh6SlIC423AQt4zSeBe2tBol0HFW7hf2g8f8
nSFCV0JLbxcStEpu+1lXknpdHC3NYWH1EgIOJrnbX7Ae6wI/gszZ1Xa+kSxaUvWBRJb+abRmjRkm
8B41NNh5wKxBi9ivtAM=</ds:Modulus><ds:Exponent>AQAB</ds:Exponent></ds:RSAKeyValue></ds:KeyValue></ds:KeyInfo>
EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_20

CNLAuthzToken example – 293 bytes<cnl:CNLAuthzToken TokenID="ed9d969e1262ba1d3a7f33dbd670dd94"><cnl:TokenValue>
0IZt9WsJT6an+tIxhhTPtiztDpZ+iynx7K7X2Cxd2iBwCUTQ0n61Szv81DKllWsq75IsHfusnm56
zT3fhKU1zEUsob7p6oMLM7hb42+vjfvNeJu2roknhIDzruMrr6hMDsIfaotURepu7QCT0sADm9If
X89Et55EkSE9oE9qBD8=</cnl:TokenValue></cnl:CNLAuthzToken>• CNLAuthzToken is constructed of the CNLAuthzTicket TicketID and SignatureValue• CNLAuthzToken use suggests caching CNLAuthzTicket’s

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_21

CNLSAMLAuthzTicket example – 2254 bytes<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" AssertionID="c236b047d62db5cecec6b240996bcb90" IssueInstant="2005-0215T14:53:23.542Z" Issuer="cnl:subject:CNLAAAauthority" Version="1.1"><Conditions NotBefore="2005-02-16T14:32:12.506Z" NotOnOrAfter="2005-02-17T14:32:12.506Z"><Condition xsi:type="typens:cnl:session-id">JobXPS1-2005-001</Condition><Condition xsi:type="typens:cnl:policy-uri">CNLpolicy01</Condition></Conditions><AuthorizationDecisionStatement Decision="Permit" Resource="http://resources.collaboratory.nl/Philips_XPS1"><Action Namespace="urn:oasis:names:tc:SAML:1.0:action:cnl:action">cnl:actions:CtrlInstr</Action><Action Namespace="urn:oasis:names:tc:SAML:1.0:action:cnl:action">cnl:actions:CtrlExper</Action><Evidence><Assertion AssertionID="f3a7ea74e515ffe776b10a7eef0119d7" IssueInstant="2005-02-15T14:53:23.542Z"
Issuer="cnl:subject:CNLAAAauthority" MajorVersion="1" MinorVersion="1"><Conditions NotBefore="2005-02-15T14:53:11.745Z" NotOnOrAfter="2005-02-16T14:53:11.745Z"/><AttributeStatement><Subject><NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
NameQualifier="cnl:subject">WHO740@users.collaboratory.nl</NameIdentifier><SubjectConfirmation>==="" moved to attr in SAML 2.0<ConfirmationMethod>signed-subject-id</ConfirmationMethod><ConfirmationData>
PBLIR0aZRtdZmq979lj8eDpJ5VT6BxxWBtSApC5BPnIsfHRUcOOpWQowXBw2TmOZdJGNzFWhMinz
XU3/wSdLjv+siO2JGfyZ7U9eqkM0GqY8VizMl5uRuUAsrr7AIHv9/DP1ksJMNDZ5DnGosMc+Zyqn
KogfMqhK+DKqPwfHF6U=</ConfirmationData></SubjectConfirmation></Subject><Attribute xmlns:typens="urn:cnl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" AttributeName="AttributeSubject" AttributeNamespace="urn:cnl">==="" level 5 of element<AttributeValue xsi:type="typens:cnl:job-id">CNL2-XPS1-2005-02-02</AttributeValue><AttributeValue xsi:type="typens:cnl:role">analyst@JobID;expert@JobID</AttributeValue></Attribute></AttributeStatement></Assertion></Evidence></AuthorizationDecisionStatement></Assertion>

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_22

CNLAuthnTicket example – 1752 bytes<cnl:CNLAuthnTicket xmlns:AAA="http://www.AAAarch.org/ns/AAA_BoD"
xmlns:cnl="http://www.aaauthreach.org/ns/#CNL" Issuer="http://www.AAAarch.org/servers/AAA"
TicketID="f35585dfb51edec48de0c7eadb11c17e"><!-- Mandatory elements --><cnl:Validity NotBefore="2005-02-15T14:33:10.548Z" NotOnOrAfter="2005-02-16T14:33:10.548Z"/><cnl:Subject Id="subject"><cnl:SubjectID>WHO740@users.collaboratory.nl</cnl:SubjectID><cnl:SubjectConfirmationData>
0+qQNAVuZW4txMi8DH6DFy7eLMGxSfKDJY6ZnY4UW5Dt0JFtatlEprUtgnjCkzrJUMvWk9qtUzna
sDdUG+P4ZY7dgab+PHiU91ClusZbztu/ZIjNqCnw5su1BQLTumC8ZTtYKKJi4WWs+bMMbP8mFNQm+M7F4bJIPBfLcxf0bk4=</cnl:SubjectConfirmationData><!--Optional elements --><cnl:SubjectAttribute attrname="urn:cnl:subject:attribute:job-id">
CNL2-XPS1-2005-02-02</cnl:SubjectAttribute><cnl:SubjectAttribute attrname="urn:cnl:subject:attribute:role">
analyst@JobID;expert@JobID</cnl:SubjectAttribute></cnl:Subject></cnl:CNLAuthnTicket>

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_23

CNLAuthnToken signed/encrypted – 401/269 bytes<cnl:CNLAuthnToken xmlns:cnl="http://www.aaauthreach.org/ns/#CNL"TokenID="f35585dfb51edec48de0c7eadb11c17e"><cnl:SubjectID>WHO740@users.collaboratory.nl</cnl:SubjectID><cnl:TokenValue>
0+qQNAVuZW4txMi8DH6DFy7eLMGxSfKDJY6ZnY4UW5Dt0JFtatlEprUtgnjCkzrJUMvWk9qtUzna
sDdUG+P4ZY7dgab+PHiU91ClusZbztu/ZIjNqCnw5su1BQLTumC8ZTtYKKJi4WWs+bMMbP8mFNQm+M7F4bJIPBfLcxf0bk4=</cnl:TokenValue></cnl:CNLAuthnToken>• CNLAuthnToken is constructed of the CNLAuthnTicket TicketID and SubjectConfirmationData
which is encrypted SubjectID value• CNLAuthzToken must be self-sufficient and doesn’t require caching CNLAuthnTicket’s<cnl:CNLAuthnToken xmlns:cnl="http://www.aaauthreach.org/ns/#CNL"TokenID="a392a20157698d201d77b2c6e8e444ef"><cnl:SubjectID>WHO740@users.collaboratory.nl</cnl:SubjectID><cnl:TokenValue>qij9zJgKZp9RiJxYN1QJAN0vhjLJSMGVLD/doQtmCsk=</cnl:TokenValue></cnl:CNLAuthnToken>

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_24

Discussion• What can be re-used in G-Pbox?

EGEE-Policy. June 6-7, 2005. Bologna

XML security tickets and tokens

Slide_25