20070615 POLICY grid

Policy-driven Negotiationfor Authorization in the Grid: 

Policy-driven Negotiation for Authorization in the Grid 8th IEEE POLICY Bologna, Italy, 15th June 2007

Outline: 

Outline Introduction Motivation Policy-driven Negotiations Negotiations in the Grid Implementation Conclusions and Further Work

IntroductionVirtual Organization: 

Introduction Virtual Organization Policy Org 1 Org 2 Org 3

IntroductionWhy Grid Security is Hard?: 

Introduction Why 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: 

Motivation Local Administrative Domain 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 Can I have glass of lemonade? No way, I don’t like you Resource Owner decides! (ultimate source of authority for access)

MotivationDistinct Administrative Domains: 

Motivation Distinct Administrative Domains Can I have glass of lemonade?

MotivationDistinct Administrative Domains – Pull (I): 

Motivation Distinct Administrative Domains – Pull (I)

MotivationDistinct Administrative Domains – Pull (& II): 

Motivation Distinct Administrative Domains – Pull (& II)

MotivationDistinct Administrative Domains – Push approach: 

Motivation Distinct Administrative Domains – Push approach Can I have glass of lemonade? And BTW, Carol is my friend 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

MotivationExample Scenario – Grid Limitations: 

Motivation Example Scenario – Grid Limitations

Policy-Driven NegotiationsExample: Security & Privacy: 

Policy-Driven Negotiations Example: Security & Privacy Bob Alice

Negotiations in the GridRevisiting the example scenario: 

Negotiations in the Grid Revisiting the example scenario 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: 

Policy-Driven Negotiations Characteristics 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: 

Implementation Current GT4’s new authZ framework

ImplementationArchitecture: 

Implementation Architecture 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: 

Implementation Integration 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: 

Conclusions & Future Work Conclusions 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: 

Conclusions & Future Work Further 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

Thanks!: 

Questions? olmedilla@L3S.de - http://www.L3S.de/~olmedilla/ Thanks!

Implementation in GT4Easy Integration with Current Grid Services: 

Implementation in GT4 Easy 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: 

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: 

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: 

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)

Slide24: 

Client Service

Slide25: 

9. Notify the client about service policies and further requirements 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: 

Policy Assertions from Everywhere CAS Shib LDAP Handle VOMS PERMIS XACML SAML SAZ PRIMA Gridmap XACML ???

Policy Evaluation Complexity: 

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, ???

Slide28: 

Can I have glass of lemonade? Master PDP