Policy Based Dynamic Negotiation for Grid Services Authorization Infolunch, L3S Research Center Hannover, 29 th Jun. 2005 Ionut Constandache Daniel Olmedilla.

Policy Based Dynamic

Negotiation

for Grid Services

Authorization

Infolunch, L3S Research CenterHannover, 29th Jun. 2005

Ionut ConstandacheDaniel Olmedilla

Contents

GRID Security Infrastructure in GT4.0

Limitations of Current Authorization Mechanisms

Policy based Dynamic Negotiation for Grid Services Authorization

Current / Future Work

I. Grid Security Infrastructure

in GT4.0

Example Scenario

X.509 Certificates and Proxy Certificates

Proxy Certificates Delegation Chain

Grid Security Infrastructure

Grid Security Infrastructure (GSI) uses public key cryptography.

GSI uses X.509 End Entity Certificates to identify persistent entities and services Provide each entity with a unique identifier the

Distinguished Name (DN) in the certificate.

GSI supports delegation and single sign-on through the use of X.509 Proxy Certificates

MyProxy Server Store, retrieve, renew X.509 Proxy Certificates Store Chain of certificates

Community Authorization Service (CAS) Trust anchors defined (DN of trusted CA) Users are added to groups

- resources are added to the community- rights granted on the community resources- retrieve Restricted Proxy Credentials that includes all

the permissions granted to the user by the community Certificate with “User U belongs to Group G” and “Group G has

permissions P on Resource R”

Credential Repositories / Wallets

Security

GT4.0 uses SOAP for representing the data Exchanged between grid entities

Message protection achieved through Transport Level Security

SOAP messages transported over TLS Message Level Security

WS-Security standard

WS-SecureConversation specification

They provide integrity protection/encryption of SOAP messages

Alternatives for Authentication and Authorization in GT4.0

Authentication X.509 Certificates and public keys via TLS for transport level

security or via signature in conformity with WS-Security for message level security

username and password using WS-Security

Authorization gridmapfile, hostname, identity, self Services can use a callout using SAML to allow the use of a third

party authorization decision- CAS service issues SAML Authorization Decision assertions for

representing the rights entitled to the CAS clients by the Virtual Organization (VO)

MA: Mutual Authentication

II. Limitations of Current Authorization Mechanisms

Limitations / Service Side

Services do not advertise their authorization requirements:

What CA authority is trusted by the service

Where to obtain the credentials from

Authorization based on Identity: Difficult to maintain access control lists

Not Scalable

Decision regarding authorization based only on one certificate/chain of certificates

Limitations / Credential Repositories

MyProxy - Authorization based on Identity:

3 access control lists: accepted_credentials, authorized_retrievers, authorized_renewers

Regular expression matching between the client DN in the certificate provided and the entries in the list associated with the requested action

CAS Service:

Same limitations as a usual Grid service (see previous slide) Default uses the back-end database to determine if the call is permitted

Limitations / Client Side

Previous interactions assumed have the accounts set (mapping between the client DN

and the local Unix account)

known in advance what credentials have to be disclosed

Limited authorization constraints that can be required to the service (hostname, identity, self)

Keep track of many credentials and all the associations with the entities/services that require them

III. Policy based Dynamic Negotiation for Grid Services

Authorization

Policy Based Authorization

Parties define access control policies to protect

resources and certificates

Services/Clients - use and advertise policies for authorization

Policies are exposed and certificates disclosed iteratively and bilaterally during a trust negotiation process

Policy Syntax

First Order Horn rules:lit0 lit1, lit2, ... , litn

- delegation of evaluation @ - requester $ - guards |

lit0 $ Requester <- liti @ Issueri | litj @ Issuerj

submit(job,credential) $ Requester member(Requester,Project)@CAS1@Requester | valid(Project),usage(linuxCluster) < 80%.

valid(NEES Grid) valid(ESG Grid) ...

Integrating policy based dynamic negotiation for grid services authorization Descriptors:

- grid service descriptor (wsdl file):

<wsdl:import namespace="http://.../TrustNegotiation.wsdl" location="TrustNegotiation.wsdl"/>

<portType name=”GridService” wsdlpp:extends= "... wsntw:NotificationProducer wstn:TrustNegotiation ... ">

TrustNegotiation.wsdl - defines the data types and functions for exchanging trust negotiation messages

The grid service should extend the NotificationProducer port type (used for asynchronous communication with the client) and the TrustNegotiation port type(used for exposing the functions used by the client to push proofs/requirements to the grid service).

Integrating policy based dynamic negotiation for grid services authorization (II) Descriptors:

- grid service deployment descriptor (wsdd file):

<parameter name="providers" value="SubscribeProvider GetCurrentMessageProvider TrustNegotiationProvider"/>

Rely on GT4.0 providers for notification usage and use a TrustNegotiationProvider implementing the logic for policy based dynamic negotiation

<parameter name="securityDescriptor" value="./.../mysec.xml"/>

Install a security descriptor specifying the use of a PDP for filtering client calls/managing authorization information.

Integrating policy based dynamic negotiation for grid services authorization (III) Resource:

- the grid service should use a resource implementing TopicListAccessor

- a topic would be added by TrustNegotiationProvider for trust negotiation (using this topic the service pushes proofs/requirements on the client side)

Service wsdl file:

<wsdl:import namespace="http://linux.egov.pub.ro/ionut/TrustNegotiation.wsdl" location="TrustNegotiation.wsdl"/>

Service Deployment Descriptor:

<parameter name="providers" value="SubscribeProvider GetCurrentMessageProvider g4mfs.impl.gridpeertrust.net.server.TrustNegotiationProvider"/><parameter name="securityDescriptor" value="share/schema/gt4ide/MathService/mysec.xml"/><parameter name="foo1-operations" value="func1 func2 func3"/>

TrustNegotiationProvider

getNegotiationTopic() trustNegotiate()

NegotiationTopicsubscribe()

MyPDP

Service calls

AuthorizationException

MinervaPrologEngine

MinervaPrologEngine

X. 509 + ext

X. 509 + ext

Policies Policies

Nego

tiation

Mo

dule

Ne

gotiation M

odule

Grid Service

Client Service

Client

FactoryService

InstanceService

Resource

Exposes a topic like TrustNegotiationTopic for asynchronous communication with the client. Notify the client when his requests are fulfilled or further requirements are imposed by the service

9. Notify the client about service policies and further requirements

PDP specified in the Instance service descriptor that intercepts operation calls. It checks if operation invoked is authorized. Operations getNegotiationTopic() and trustNegotiate() are permitted by default and all the other operations are denied unless a trust negotiation process has succeeded.

Have the instance service extend the standard port types Subscribe and GetMessage (used by notifications) and a port type which we provide TrustNegotiationProvider which is going to expose 2 operations getNegotiationTopic() and trustNegotiation(). Receive through them the client requests and proofs with regard to service authorization

5. Catch the exception 10. Operation executed on resource if the trust

negotiation process was successful

3. Operation called on the resource

4. Client is not authorized to make the call throw an exception.

8. Client call trustNegotiation() operation for sending client policies and proofs

1. Requests create resource

2. Creates the resource

7. Register with TrustNegotiation Topic for notifications

6. Client call getNegotiationTopic() receive the QName of the negotiation topic.

IV. Current / Future Work

Current Status

√ Policy Based Dynamic Negotiation for Authorization between clients and services as long as all credentials are available locally. (No delegation of evaluation to other parties)

HpcLinuxCluster

policy1(request(Operation),Requester) drivingLicense(Requester)@ caState @ Requester,policy3(request(Operation),Requester).

policy3(request(Operation),Requester) manager(Requester) @ ibm @ Requester.

policy3(request(Operation),Requester) employee(Requester) @ ibm @ Requester.bbbMember(hpclinuxcluster) @ bbb signed by bbb.

Alice

manager(alice) @ ibm $ Requester bbbMember(Requester) @ bbb @ Requester.drivingLicense(alice) @ caState signed by caState.manager(alice) @ ibm signed by ibm.

Future Work (I)

To achieve Delegation of Evaluation Policy Based Dynamic Authorization front end service for

the MyProxy credential repository (PBDA MyProxy) Wrappers for calls to the PBDA MyProxy Wrappers for calls to CAS Services

Retrieve credentials at runtime from PBDA MyProxy and CAS Services.

If member(Requester,Project)@CAS1 is required to be fulfilled, finding out at runtime how to contact/retrieve such a credential.

Future Work (& II)

Express our policies in standard language XACML

Support for general service authorization assertion providers - Let entities define their own web services for providing

assertions - Find out at runtime how to obtain/negotiate for these

assertions

E.g.: employee(Alice)@IBM

How it can be derived? What is IBM? (web service)How can it be accessed? (wsdl file has the syntax of the service, needs its semantics)

Thank You!

Thank You!