policy based dynamic negotiation for grid services authorization infolunch, l3s research center...
TRANSCRIPT
Policy Based Dynamic
Negotiation
for Grid Services
Authorization
Infolunch, L3S Research CenterHannover, 29th Jun. 2005
Ionut ConstandacheDaniel Olmedilla
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
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
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 Organization (VO)
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 type(used for exposing the functions used by the client to push proofs/requirements to the grid service).
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)
Service wsdl file:
<wsdl:import namespace="http://linux.egov.pub.ro/ionut/TrustNegotiation.wsdl" location="TrustNegotiation.wsdl"/>
Service Deployment Descriptor:
<parameter name="providers" value="SubscribeProvider GetCurrentMessageProvider g4mfs.impl.gridpeertrust.net.server.TrustNegotiationProvider"/><parameter name="securityDescriptor" value="share/schema/gt4ide/MathService/mysec.xml"/><parameter name="foo1-operations" value="func1 func2 func3"/>
TrustNegotiationProvider
getNegotiationTopic() trustNegotiate()
NegotiationTopicsubscribe()
MyPDP
Service calls
AuthorizationException
MinervaPrologEngine
MinervaPrologEngine
X. 509 + ext
X. 509 + ext
Policies Policies
Nego
tiation
Mo
dule
Ne
gotiation M
odule
Grid Service
Client Service
Client
FactoryService
InstanceService
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.
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!