Policy Based Dynamic Negotiation for Grid Services Authorization

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

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

I. Grid Security Infrastructure in GT 4. 0

Example Scenario

X. 509 Certificates and Proxy Certificates Delegation Chain

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

Credential Repositories / Wallets My. Proxy 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

Security GT 4. 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-Secure. Conversation specification They provide integrity protection/encryption of SOAP messages

Alternatives for Authentication and Authorization in GT 4. 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

MA: Mutual Authentication

II. Limitations of Current Authorization Mechanisms

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

Limitations / Credential Repositories My. Proxy - 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

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

III. Policy based Dynamic Negotiation for Grid Services Authorization

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

Policy Syntax First Order Horn rules: lit 0 lit 1, lit 2, . . . , litn - delegation of evaluation @ - requester $ - guards | lit 0 $ Requester <- liti @ Issueri | litj @ Issuerj submit(job, credential) $ Requester member(Requester, Project)@CAS 1@Requester | valid(Project), usage(linux. Cluster) < 80%. valid(NEES Grid) valid(ESG Grid). . .

Integrating policy based dynamic negotiation for grid services authorization Descriptors: - grid service descriptor (wsdl file): <wsdl: import namespace="http: //. . . /Trust. Negotiation. wsdl" location="Trust. Negotiation. wsdl"/> <port. Type name=”Grid. Service” wsdlpp: extends= ". . . wsntw: Notification. Producer wstn: Trust. Negotiation. . . "> Trust. Negotiation. wsdl - defines the data types and functions for exchanging trust negotiation messages The grid service should extend the Notification. Producer port type (used for asynchronous communication with the client) and the Trust. Negotiation port

Integrating policy based dynamic negotiation for grid services authorization (II) Descriptors: - grid service deployment descriptor (wsdd file): <parameter name="providers" value="Subscribe. Provider Get. Current. Message. Provider Trust. Negotiation. Provider"/> Rely on GT 4. 0 providers for notification usage and use a Trust. Negotiation. Provider implementing the logic for policy based dynamic negotiation <parameter name="security. Descriptor" value=". /. . . /mysec. xml"/> Install a security descriptor specifying the use of a PDP for filtering client calls/managing authorization information.

Integrating policy based dynamic negotiation for grid services authorization (III) Resource: - the grid service should use a resource implementing Topic. List. Accessor - a topic would be added by Trust. Negotiation. Provider for trust negotiation (using this topic the service pushes proofs/requirements on the client side)

Client Service

9. Notify the client about service policies and further requirements 7. Register with Trust. Negotiation Topic for notifications Factory Service 5. Catch the exception 1. Requests create resource 2. Creates the resource Resource 10. Operation executed on resource if the trust negotiation process was successful Client 3. Operation called on the resource 4. Client is not authorized to make the call throw an exception. Exposes a topic like Trust. Negotiation. Topic for asynchronous communication with the client. Notify the client when his requests are fulfilled or further requirements are imposed by the service Instance Service Have the instance service extend the standard port types Subscribe and Get. Message (used by notifications) and a port type which we provide Trust. Negotiation. Provider which is going to expose 2 operations get. Negotiation. Topic() and trust. Negotiation(). Receive through them the client requests and proofs with regard to service authorization 6. Client call get. Negotiation. Topic() receive the QName of the negotiation topic. 8. Client call trust. Negotiation() operation for sending client policies and proofs PDP specified in the Instance service descriptor that intercepts operation calls. It checks if operation invoked is authorized. Operations get. Negotiation. Topic() and trust. Negotiate() are permitted by default and all the other operations are denied unless a trust negotiation process has succeeded.

IV. Current / Future Work

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) Hpc. Linux. Cluster policy 1(request(Operation), Requester) driving. License(Requester)@ ca. State @ Requester, policy 3(request(Operation), Requester) manager(Requester) @ ibm @ Requester. policy 3(request(Operation), Requester) employee(Requester) @ ibm @ Requester. bbb. Member(hpclinuxcluster) @ bbb signed by bbb. Alice manager(alice) @ ibm $ Requester bbb. Member(Requester) @ bbb @ Requester. driving. License(alice) @ ca. State signed by ca. State. manager(alice) @ ibm signed by ibm.

Future Work (I) To achieve Delegation of Evaluation Policy Based Dynamic Authorization front end service for the My. Proxy credential repository (PBDA My. Proxy) Wrappers for calls to the PBDA My. Proxy Wrappers for calls to CAS Services Retrieve credentials at runtime from PBDA My. Proxy and CAS Services. If member(Requester, Project)@CAS 1 is required to be fulfilled, finding out at runtime how to contact/retrieve such a credential.

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)

Thank You!