Policy-driven Negotiation for Authorization in the Grid

1. Policy-driven Negotiationfor Authorization in the Grid 8th IEEE POLICY Bologna, Italy, 15th June 2007

2. Outline • Introduction • Motivation • Policy-driven Negotiations • Negotiations in the Grid • Implementation • Conclusions and Further Work 8th IEEE POLICY

3. IntroductionVirtual Organization Org 3 Org 1 Org 2 Policy 8th IEEE POLICY

4. 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 8th IEEE POLICY

5. Ivan Alice Mallory MotivationLocal Administrative Domain Ivan’s policy: Alice is my friend and I’ll share my lemonade with her Mallory is not my friend and he can go #$%^& Can I have glass of lemonade? Sure, here is a glass Resource Owner decides! (ultimate source of authority for access) Can I have glass of lemonade? No way, I don’t like you 8th IEEE POLICY

6. Ivan’s policy: Carol is my friend and I’ll share my lemonade with her I’ll share my lemonade with any friend of Carol I don’t know any Bob…(?) Bob ? Ivan MotivationDistinct Administrative Domains Can I have glass of lemonade? 8th IEEE POLICY

7. Ivan’s policy: Carol is my friend and I’ll share my lemonade with her I’ll share my lemonade with any friend of Carol I don’t know any Bob…(?) Can I have glass of lemonade? Bob Sure, here is a glass Can Bob have glass of lemonade? Ivan Sure, Bob is my friend Carol’s policy: Bob is my friend and I’ll share my lemonade with him Carol MotivationDistinct Administrative Domains – Pull (I) 8th IEEE POLICY

8. Aunt’s policy: Sharing is good Frosty’s policy: Only share lemonade with ice Neighbor's policy: Let’s party! Ivan’s policy: I don’t know any Bob…(?) I do know John, Mary, Carol, Olivia, … Bill’s policy: Lemonade is bad for you Can I have glass of lemonade? Jogger’s policy: I’d like a glass too Bob Laura’s policy: Share if he pays! Ivan: HELP Can Bob have glass of lemonade? Ivan Ivan Rita’s policy: No lemonade after eight John’s policy: I don’t like girls Accountant’s policy: Only if he signs here Mary’s policy: I like Bob a little bit Sure, Bob is my friend Olivia’s policy: If Carol likes Bob, I hate him! Emma’s policy: Only on his birthday Ann’s policy: I like Ivan very much! Carol’s policy: Bob is my friend and I’ll share my lemonade with him Lucy’s policy: I sometimes like Carol David’s policy: Ask Laura Carol MotivationDistinct Administrative Domains – Pull (& II) 8th IEEE POLICY

9. Ivan’s policy: Carol is my friend and I’ll share my lemonade with her I’ll share my lemonade with any friend of Carol I don’t know any Bob…(?) Bob Sure, here is a glass Ivan MotivationDistinct Administrative Domains – Push approach • 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 Can I have glass of lemonade? And BTW, Carol is my friend 8th IEEE POLICY

10. MotivationExample Scenario – Grid Limitations 8th IEEE POLICY

11. Step 1: Alice requests a service from Bob Step 2: Bob discloses his policy for the service Step 3: Alice discloses her policy for VISA Step 4: Bob discloses his BBB credential Step 5: Alice discloses her VISA card credential Step 6: Bob grants access to the service Service Policy-Driven NegotiationsExample: Security & Privacy Alice Bob 8th IEEE POLICY

12. Negotiations in the GridRevisiting the example scenario The delegated certificate is used to retrieve the requested certificates With only one certificate to access the online repository Server informs the client about its access control policy 8th IEEE POLICY

13. 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— 8th IEEE POLICY

14. ImplementationCurrent GT4’s new authZ framework 8th IEEE POLICY

15. ImplementationArchitecture • 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”/> 8th IEEE POLICY

16. 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 8th IEEE POLICY

17. 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 8th IEEE POLICY

18. 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 8th IEEE POLICY

19. Thanks! Questions? olmedilla@L3S.de - http://www.L3S.de/~olmedilla/ 8th IEEE POLICY

20. 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 8th IEEE POLICY

21. 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). 8th IEEE POLICY

22. 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. 8th IEEE POLICY

23. 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) 8th IEEE POLICY

24. Client Service 8th IEEE POLICY

25. 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 Factory Service Resource Client 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 Instance Service 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. 9. Notify the client about service policies and further requirements 7. Register with TrustNegotiation Topic for notifications 2. Creates the resource 1. Requests create resource 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. 6. Client call getNegotiationTopic() receive the QName of the negotiation topic. 8. Client call trustNegotiation() operation for sending client policies and proofs 8th IEEE POLICY

26. Policy Assertions from Everywhere PERMIS XACML SAML SAZ PRIMA Shib LDAP Handle VOMS CAS ??? Gridmap XACML 8th IEEE POLICY

27. 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, ??? COMPLEXITY 8th IEEE POLICY

28. Frosty Bill Aunt Lucy Laura Carol Bob Mary Jogger Ivan Rita Accountant Olivia John Decision Helper Emma Ann David Master PDP Can I have glass of lemonade? 8th IEEE POLICY