Policy-driven Negotiation for Authorization in the Grid Ionut - PowerPoint PPT Presentation

Policy-driven Negotiation for Authorization in the Grid Ionut Constandache Duke University Daniel Olm edilla L3S Research Center Frank SiebenList Argonne National Laboratory 8 th IEEE POLICY Bologna, Italy, 15 th June 20 0 7

Outline � Introduction � Motivation � Policy-driven Negotiations � Negotiations in the Grid � Implementation � Conclusions and Further Work Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 2

Introduction Virtual Organization Org 3 Org 1 Org 2 Policy Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 3

Introduction Why Grid Security is Hard? Resources being used m ay be valuable & the problem s being solved sensitive � Both users and resources need to be careful Dynam ic form ation and m anagem ent of virtual organizations (VOs) � Large, dynamic, unpredictable… VO Resources and users are often located in distinct adm inistrative dom ains � 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 Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 4

Motivation Local 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 Alice I van Can I have glass of lemonade? Resource Ow ner decides! No way, I don’t like you (ultimate source of authority for access) Mallory Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 5

Motivation Distinct Administrative Domains 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 ? I van Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 6

Motivation Distinct Administrative Domains – Pull (I) 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 I van Can Bob have glass of lemonade? Sure, Bob is my friend Carol’s policy: Carol Bob is my friend and I’ll share my lemonade with him Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 7

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

Motivation Distinct Administrative Domains – Push approach 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? And BTW, Carol is my friend Bob Sure, here is a glass I van � either Bob provides a list of all his friends or � Privacy problem s, superfluous disclosure � Bob knows in advance the friends from Ivan � static � service instances to be used m ay be selected at run-tim e Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 9

Motivation Example Scenario – Grid Limitations - Too many Credentials to keep track of - Knowing which credential to use - Different sites trust different CA - No way to determine automatically which issuers are trusted MyProxy Credential Repository NEESgrid 0a RLS Job must know in advance what Linux Cluster Request previously stored proxy credentials will have to be disclosed certificate 0b M.A. Receive proxy 1 certificate M.A. Mutual Authentication SRB (M.A.) job 2 M.A. Alice submits a job 3 Delegate proxy certificate Shake Alice Smith Authorization may depend on user’s GridFTP In large projects, an account per table properties Server M.A. : Mutual Authentication user does not scale E.g. user’s affiliation with a project Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 10

Policy-Driven Negotiations Example: Security & Privacy Alice Bob 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 Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 11

Negotiations in the Grid Revisiting the example scenario The delegated certificate is used to retrieve the requested certificates Credential Repository 4. Alice 1. Authentication Shake Table membership? Access Manager 5. Alice 2. Request BigQuake 3. Alice 0. Alice membership membership? submits a job job 6. Alice BigQuake membership 7. Access granted NEESgrid Linux Cluster Shake 8. Alice’s job Shakes the table table Alice Smith With only one certificate to Server inform s the client access the online repository about its access control policy Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 12

Policy-Driven Negotiations Characteristics Both client and servers are sem antically 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 involvem ent is drastically reduced – autom ated interactions If required, for sensitive resources, negotiation can be longer � To obtain (access to) a certificate, I must satisfy its access Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 13 control policy which specifies --and so on recursively—

Implementation Current GT4’s new authZ framework Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 14

Implementation Architecture Client Grid Service Negotiation Module Negotiation Module subscribe() Notification Negotiation notify() Listener Topic PeerTrust PeerTrust Module negotiateTrust() Module Send Negotiation Wrapper Provider getNegotiationTopic() Inference Inference Client Call Engine Engine Interceptor operation() Client Interceptor Grid Negotiation Exception Program PDP Service Policies Policies Credentials Credentials Service wsdl file <wsdl:im port nam espace=“http:/ / linux.egov.pub.ro/ ionut/ TrustNegotiationwsdl” location=“TrustNegotiationwsdl”/ > Service Deploym ent Descriptor <param eter nam e=“providers” value=“SubscribeProvider GetCurrentMessageProvider g4m fs.im pl.gridpeertrust.net.server.TrustNegotiationProvider”/ > <param eter nam e=“securityDescriptor” value=“share/ schem a/ gt4ide/ MathService/ m ysec.xm l”/ > Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 15

Implementation Integration on Globus Toolkit 4.0 � Directed integrated with the grid services paradigm � Extension to GSI pluggable to any GT4.0 com pliant grid service or client � Only requirem ent: 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 Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 16

Conclusions & Future Work Conclusions Main Features � Self-describing resources for access requirem ents � Based on properties � Negotiation for service authorization � Dynam ic 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 Im plem entation in Java � Extension of GSI in GT4.0 � Backwards com patible Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 17

Conclusions & Future Work Further Work � Study perform ance im pact of negotiations � And approaches to m inim ize the extra load � Lim it num ber 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 Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 18

Thanks! Questions? olm edilla@L3S.de - http:/ / w w w .L3S.de/ ~olm edilla/ Daniel Olmedilla 8th IEEE POLICY June 15th, 2007 19