1 / 27

Policy Based Dynamic Negotiation for Grid Services Authorization

Policy Based Dynamic Negotiation for Grid Services Authorization. Ionut Constandache Daniel Olmedilla. Infolunch, L3S Research Center Hannover, 29 th Jun. 2005. Contents. GRID Security Infrastructure in GT4.0 Limitations of Current Authorization Mechanisms

tad
Télécharger la présentation

Policy Based Dynamic Negotiation for Grid Services Authorization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Policy Based Dynamic Negotiationfor Grid Services Authorization Ionut Constandache Daniel Olmedilla Infolunch, L3S Research CenterHannover, 29th Jun. 2005

  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. 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. 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 permissions P on Resource R”

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

  18. 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 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): <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.

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

  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! Thank You!

More Related