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

2. Contents GRID Security Infrastructure in GT4.0 Limitations of Current Authorization Mechanisms Policy based Dynamic Negotiation for Grid Services Authorization Current / Future Work

3. I.Grid Security Infrastructure in GT4.0

4. Example Scenario

5. X.509 Certificates and Proxy Certificates Proxy Certificates Delegation Chain

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

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

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

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

10. MA: Mutual Authentication

11. II. Limitations of Current Authorization Mechanisms

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

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

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

15. III. Policy based Dynamic Negotiation for Grid Services Authorization

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

17. Policy Syntax First Order Horn rules: lit 0 lit 1, lit 2,..., lit n - delegation of evaluation @ - requester $ - guards | lit 0 $ Requester <- lit i @ Issuer i | lit j @ Issuer j submit(job,credential) $ Requester member(Requester,Project)@CAS1@Requester | valid(Project), usage(linuxCluster) < 80%. valid(NEES Grid) valid(ESG Grid)...

18. Integrating policy based dynamic negotiation for grid services authorization Descriptors: - grid service descriptor (wsdl file): 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).

19. Integrating policy based dynamic negotiation for grid services authorization (II) Descriptors: - grid service deployment descriptor (wsdd file): Rely on GT4.0 providers for notification usage and use a TrustNegotiationProvider implementing the logic for policy based dynamic negotiation Install a security descriptor specifying the use of a PDP for filtering client calls/managing authorization information.

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

21. Client Service

22. Client Factory Service Instance Service 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.

23. IV. Current / Future Work

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

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

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

27. Thank You!