Policy Based Dynamic Negotiation for Grid Services Authorization Ionut Constandache Daniel Olmedilla Infolunch, L3S Research Center Hannover, 29th Jun. 2005 Contents GRID Security Infrastructure in GT4.0 Limitations of Current Authorization Mechanisms Policy based Dynamic Negotiation for Grid Services Authorization Current / Future Work I. Grid Security Infrastructure in GT4.0 Example Scenario X.509 Certificates and Proxy Certificates Proxy Certificates Delegation Chain 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 Credential Repositories / Wallets 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 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 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 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 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 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: lit0 lit1, lit2, ... , litn - delegation of evaluation @ - requester $ - guards | lit0 $ Requester <- liti @ Issueri | litj @ Issuerj submit(job,credential) $ Requester member(Requester,Project)@CAS1@Requester | valid(Project), usage(linuxCluster) < 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://.../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 Integrating policy based dynamic negotiation for grid services authorization (II) 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. 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) Client Service 9. Notify the client about service policies and further requirements Exposes a topic like TrustNegotiationTopic for asynchronous communication with the client. Notify the 7. Register with client when his requests are fulfilled or further TrustNegotiation Topic for requirements are imposed by the service notifications Factory 2. Creates the resource Service Resource 5. Catch the 1. Requests create exception resource 10. Operation executed on resource if the trust negotiation process was successful Client Have the instance service extend the standard 3. Operation called on the port types Subscribe and GetMessage (used by resource notifications) and a port type which we provide TrustNegotiationProvider which is going to 4. Client is not authorized to expose 2 operations getNegotiationTopic() and make the call throw an Instance trustNegotiation(). Receive through them the exception. Service client requests and proofs with regard to service authorization 6. Client call getNegotiationTopic() receive the QName of the negotiation topic. PDP specified in the Instance service descriptor that intercepts operation calls. It checks if operation invoked is authorized. Operations getNegotiationTopic() and 8. Client call trustNegotiation() trustNegotiate() are permitted by default and all the other operation for sending client policies operations are denied unless a trust negotiation process has and proofs 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) 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. 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. 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! Thank You!
Pages to are hidden for
"Policy Based Dynamic Negotiation for Grid Services Authorization"Please download to view full document