Policy Based Dynamic Negotiation for Grid Services Authorization by I0FVNFi

VIEWS: 4 PAGES: 27

									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!

								
To top