Policy-driven Negotiation for Authorization in the Grid

Policy-driven Negotiationfor Authorization in the Grid

8th IEEE POLICYBologna, Italy, 15th June 2007

Ionut Constandache

Duke University

Daniel Olmedilla L3S Research Center

Frank SiebenList Argonne National Laboratory

June 15th, 20078th IEEE POLICY 2Daniel Olmedilla

Outline

Introduction

Motivation

Policy-driven Negotiations

Negotiations in the Grid

Implementation

Conclusions and Further Work


IntroductionVirtual Organization

Policy

Org 1Org 2

Org 3


IntroductionWhy Grid Security is Hard?

Resources being used may be valuable & the problems being solved sensitive Both users and resources need to be careful

Dynamic formation and management of virtual organizations (VOs) Large, dynamic, unpredictable…

VO Resources and users are often located in distinct administrative domains Can’t assume cross-organizational trust agreements Different mechanisms & credentials

Interactions are not just client/server, but service-to-service on behalf of the user Requires delegation of rights by user to service Services may be dynamically instantiated


MotivationLocal Administrative Domain

Ivan

Mallory

Alice

Can I have glass of lemonade?

Ivan’s policy: Alice is my friend and I’ll share my lemonade with her

Mallory is not my friend and he can go #$%^&

Sure, here is a glass


No way, I don’t like you

Resource Owner decides!(ultimate source of authority for access)


MotivationDistinct Administrative Domains

? Ivan

Ivan’s policy: Carol is my friend and I’ll share my lemonade with her

I’ll share my lemonade with any friend of CarolI don’t know any Bob…(?)


Bob


MotivationDistinct Administrative Domains – Pull (I)

Sure, here is a glass

Can Bob have glass of lemonade?

Sure, Bob is my friend

Ivan




Bob

CarolCarol’s policy:

Bob is my friend and I’ll share my lemonade with him


MotivationDistinct Administrative Domains – Pull (& II)

Can Bob have glass of lemonade?

Sure, Bob is my friend

Ivan

Ivan’s policy: I don’t know any Bob…(?)

I do know John, Mary, Carol, Olivia, …


Bob

CarolCarol’s policy:

Bob is my friend and I’ll share my lemonade with him

Olivia’s policy: If Carol likes Bob, I hate him!

Mary’s policy: I like Bob a little bit

Lucy’s policy: I sometimes like Carol

Ann’s policy: I like Ivan very much!

Jogger’s policy: I’d like a glass too

John’s policy: I don’t like girls

Bill’s policy: Lemonade is bad for you

Frosty’s policy: Only share lemonade with ice

Aunt’s policy: Sharing is good

Laura’s policy: Share if he pays!

David’s policy: Ask Laura

Accountant’s policy: Only if he signs here

Rita’s policy: No lemonade after eight

Neighbor's policy: Let’s party!

Emma’s policy: Only on his birthday

Ivan: HELPIvan


MotivationDistinct Administrative Domains – Push approach

Sure, here is a glass Ivan




And BTW, Carol is my friend

Bob

either Bob provides a list of all his friends or Privacy problems, superfluous disclosure

Bob knows in advance the friends from Ivan static service instances to be used may be selected at

run-time


Alice Smith

0aRequest previously

stored proxycertificate

MyProxy CredentialRepository

0bReceive proxy

certificate

NEESgrid Linux Cluster

1Mutual Authentication

(M.A.)

2Alice submits a job

job

3Delegate proxy

certificate

M.A. : Mutual Authentication

GridFTPServer

RLS

M.A.

SRBM.A.

M.A.

Shaketable

MotivationExample Scenario – Grid Limitations

- Too many Credentials to keep track of- Knowing which credential to use

Authorization may depend on user’s propertiesE.g. user’s affiliation with a project

In large projects, an account per user does not scale

Job must know in advance what credentials will have to be disclosed

- Different sites trust different CA- No way to determine automatically which issuers are trusted


Policy-Driven NegotiationsExample: Security & Privacy

Step 1: Alice requests a service from Bob

Step 5: Alice discloses her VISA card credential

Step 4: Bob discloses his BBB credential

Step 6: Bob grants access to the serviceService

BobAlice

Step 2: Bob discloses his policy for the service

Step 3: Alice discloses her policy for VISA


Negotiations in the GridRevisiting the example scenario

0. Alicesubmits a job

Alice Smith

Shake TableAccess Manager

3. Alicemembership?

CredentialRepository

4. Alicemembership?

job

1. Authentication

5. AliceBigQuake

membership

6. AliceBigQuake

membership

8. Alice’s jobShakes the table

7. Accessgranted

2. Request

Shaketable

NEESgrid Linux Cluster

With only one certificate to access the online

repository

The delegated certificate is used to retrieve the requested

certificates

Server informs the client about its access control

policy


Policy-Driven NegotiationsCharacteristics

Both client and servers are semantically annotated with policies

Annotations specify constraints and capabilities – access control

requirements which certificates must be presented to gain access to it who is responsible for obtaining and presenting these certificates

are used during a negotiation to reason about and to communicate the requirements to determine whether credentials can be obtained and revealed.

User involvement is drastically reduced – automated interactions

If required, for sensitive resources, negotiation can be longer To obtain (access to) a certificate, I must satisfy its access

control policy, which specifies … --and so on, recursively—


ImplementationCurrent GT4’s new authZ framework


ImplementationArchitecture

negotiateTrust()

NegotiationTopic

subscribe()

Interceptor PDPNegotiation Exception

Negotiation Provider

Notification Listener

PeerTrustModule

Send Wrapper

Grid Service

Client Program

InferenceEngine

notify()

getNegotiationTopic()

operation()

CredentialsPolicies Policies

Credentials

PeerTrustModule

InferenceEngine

Negotiation Module Negotiation Module

Client Call Interceptor

Client Grid Service

Service wsdl file<wsdl:import namespace=“http://linux.egov.pub.ro/ionut/TrustNegotiationwsdl” location=“TrustNegotiationwsdl”/>

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”/>


ImplementationIntegration on Globus Toolkit 4.0

Directed integrated with the grid services paradigm

Extension to GSI pluggable to any GT4.0 compliant grid service or client

Only requirement: Java based grid services

We use: Custom PDP as part of the Client Call Interceptor

- Redirects to a negotiation if required Asynchronous negotiations are achieved through

WS-Base Notification and WS-Topics

CAS integration into negotiations API for easy integration within client code


Conclusions & Future WorkConclusions

Main Features Self-describing resources for access requirements

Based on properties Negotiation for service authorization Dynamic credential fetching

Now possible to use discovery and scheduling services to locate the best available resources

Otherwise, impossible to predict before hand what exact service instances would be used and which certificates required

Monitoring and explanation of authorization decision

Implementation in Java Extension of GSI in GT4.0 Backwards compatible


Conclusions & Future WorkFurther Work

Study performance impact of negotiations

And approaches to minimize the extra load Limit number of iterations

- E.g. 2 steps negotiations Advertise policies before the service is invoked

Investigate the use of XACML Delegation not yet supported but planned


Questions?

[email protected] - http://www.L3S.de/~olmedilla/

Thanks!


Implementation in GT4Easy Integration with Current Grid Services

Service - include one jar file containing the policy based trust

negotiation engine - minor add-ons to the service wsdl file (import one wsdl

file and extend one port type) and wsdd file (add one more provider and install a security descriptor)

- have a resource (if not available) - re-deploy the service

Client- use one jar file containing the policy based trust

negotiation engine- invoke the service as usual / or call directly for a trust

negotiation process- look for authorization exceptions and if one triggered by

trust negotiation failure make simple calls to the negotiation engine


Integration into Globus Toolkit 4.0 (I)Grid Service Descriptor

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).


Integration into Globus Toolkit 4.0 (II)Grid Service Deployment Descriptor

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.


Integration into Globus Toolkit 4.0 (& III)Requirements

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.


Policy Assertions from Everywhere

CAS

ShibLDAPHandleVOMS

PERMISXACMLSAMLSAZPRIMA

Gridmap

XACML

???


Policy Evaluation Complexity

Single Domain & Centralized Policy Database/Service Meta-Data Groups/Roles membership maintained with Rules Only Pull/push of AuthZ-assertions

…

Challenge is to find right “balance”(driven by use cases…not by fad/fashion ;-) )

…

Split Policy & Distribute Everything Separate DBs for meta-data, rules & attribute mappings Deploy MyProxy, LDAP,VOMS, Shib, CAS, PRIMA,

XACML, PRIMA, GUMS, PERMIS, ???


Ivan


Bob

Olivia

Mary

Lucy

AnnJogger

John BillFrosty

AuntLaura

David

Accountant

Rita

EmmaCarol

Decision Helper

Master PDP

Documents

Policy-driven Negotiation for Authorization in the Grid