R-GMA Security Principles and Plans Linda Cornwall WP3 meeting 13th May 2003 DataGrid Workshop - Barcelona

What is Authentication? Authentication is proof of identity. “where a principle is assured of the identity of another, typically making use of public key cryptography and a public key certificate” In the edg environment this is carried out via the use of certificates from one of the recognised CA’s. A user generates a public/private key pair. The public key is sent to the CA, the CA checks the user’s identity and signs the certificate with their private key. To accept the user’s certificate, any subject will decrypt it with the CA’s public key, and carry out an exchange of info to prove the user has the private key associated with the certificate. In reality – a proxy of the user’s certificate is used – which is a short lived version so that the user does not have to keep entering a password to decrypt the private key.

What is delegation? Delegation is the passing on of rights from one entity to another. Where principals pass part (Restricted Delegation) or all (impersonation) of their rights to other principals. In the edg environment, this is carried out via a chain of delegated proxies. E.g. a user delegates their rights to a workload manager The workload manager is then able to create a delegated proxy to submit a job on the user’s behalf. Delegation allows the end principal (such as a CE) proof of identity of the original principal (such as a user), when there is no direct connection between them.

User VOMS service service Java C authr LCAS pre-proc pre-proc acl acl dn User VOMS dn + attrs service authenticate service Java C authr LCAS pre-proc pre-proc acl acl map authr LCMAPS LCAS Coarse-grained e.g. Spitfire WP2 Fine-grained e.g. RepMeC WP2/WP3 Coarse-grained e.g. CE, Gatekeeper WP4 Fine-grained e.g. SE, /grid WP5

User service Java delegation service authr pre-proc acl map authr dn User dn + attrs authenticate service Java delegation service authr pre-proc acl map authr authr pre-proc map authr Coarse-grained e.g. Spitfire WP2 Fine-grained e.g. RepMeC WP2/WP3

edg-java-security This is an authentication and authorization package provided by WP2 for use in a java environment. The authentication part is called the trustmanager. This effectively allows the Grid certificates to be used in a tomcat/java environment. Authentication is in front of the servlet, i.e. authentication takes place prior to entering the servlet. Currently, there is no delegation. However, delegation is planned for later versions.

Authentication in R-GMA In R-GMA servlets connect onto other servlets – so to properly authenticate the client with all the servlet that get connected onto we need delegation. But, in it’s absence the trustmanager has been integrated such that the client authenticates with the first servlet they connect to, then each servlet authenticates with the next servlet. Each client and servlet has a trustproperties file – stating where to find the certificate and key.

Current Status Tests behave the same with SSL or non SSL (on my machine anyway!) Now only sets up the SSL socket once – so will need modification if end up using short-time certificates as service certificates. No delegation – a rogue r-gma can do what they like if they have a service certificate. (This is more serious for authorization.)

No host name verifier No default host name verifier That provided in httpsURLConnection checks the host name in the certificate against the host name connected to. So this has been replaced by always returning O.K. Need to decide on exact form of service certificates in edg to do this properly. No host name verifier means a user could connect to a rogue service and not know.

What is Authorization? Whereby a principal is allowed to or prevented from carrying out an action. In edg there are requirements to carry out an authorization decision based on Specific DN VO membership(s) Role within VO Group within VO By allowing anyone with an acceptable certificate to carry out an action Allowing anyone to carry out an action

VOMS certificate Voms certificate contains proof that a user is a member of a VO, is a member of certain groups in a VO, and has certain roles within a VO. A delegated VOMS certificate means that any servlet that is connected onto has proof of an entity’s VO membership, groups and roles as well as DN. Then an authorization decision can be made. Without a delegated VOMS certificate – authorization is not really secure – any hacked consumer can do what they like.

Authorization – EDG Principle Principle within EDG is that Authorization information goes with the resource or data. The authorization decision is made close to the resource or data, based on a combination of local Authorization information and attributes from the user This enables e.g. resource owner or administrator, or a file owner or administrator to keep control over it’s access. Hence e.g. a producer of information must make the decision as to whether or not the requestor of that information can have that information. Hence the end producer of the information must have information on the DN, VO membership, role(s) and groups of the end client in order to make an authorization decision.

Course grained vs fine grained authorization Course grained – authorization on front of service (I.e. y/n can the person connect). “Is the user allowed to use this service – if so – what role” Fine grained – authorization takes place within a service. E.g. can this user read this file? R-GMA could have services which decide whether or not a connection is allowed, as well as services which decide whether to satisfy the request within the service. For R-GMA authorization decisions being made within services – a combination will be rather cumbersome.

R-GMA Table Authz requirements R-GMA handles tables of info In some cases, certain rows of data may only be available to one user. Summary information on a table may be available to another group of users A user may only see certain job control information, but someone else may be entitled to see summary job control info. Simple e.g. GACL on table/row not adequate Complex decisions need to be made within the R-GMA process - still should be based on DN VO membership, Groups and roles

Authz on tables Really need something like an GACL on an SQL view. But does MySQL support views? Probably means we need to write our own. If info from 1 service is needed to prove a right to access another another – rather like Steve’s ‘Friends’ table – that is effectively another credential. In DataGrid proof if a right only through VOMS – assume we are not handling pseudo credentials.

Some Other WP3 specific requirements It must be possible to restrict knowledge of the existence of producers of information to specific authorized users Solution – authorization necessary to obtain information from the registry – only those authorized are granted info on the producer A producer must be able to restrict the publishing of information to specific authorized users. Solution – each time a user attempts to publish – check against a list of users.

Other WP3 requirements - contd A user can only see certain information on their own job Solution – when job control info is requested, the producer only passes the info back if dn matches dn. A producer must be able to restrict read access to information to specific authorized users. This is a generalization of above

Confidentiality There are certain requirements on confidentiality. To satisfy these an authorization decision at the source of info AND a delegated VOMS proxy is needed. If a third party can say ‘tell me if Linda is banned’ without the use of a delegated certificate – then the fact Linda is banned can be found out without Linda’s permission. Similarly for any info – a hacked or rogue R-GMA can get any info they want. Can only make things difficult.

Copied information Information copied must have the access control copied with it. Information copied should only be copied to sites which we trust to enforce the security rules. E.g. Registry replication – only copies to authorized DN’s, which we trust to enforce the rules and not copy info to anywhere else! For archived information – rules must be preserved. Probably need 2 way authorization – given that we have Archiver and ConsumerProducers. This is a big complication.

Authz Strategy Summary for R-GMA Authz decisions all made within Service Use Delegated VOMS proxy’s (when available). Need ability to extract DN, VO, Groups and Roles . Publish Policy in Registry Allows ability to only ask producers questions they are likely to answer. (Mediator Functionality) Mediator can make a first decision e.g. re-formulate a request Which means that the mediator can have non-confidential authorization information on general policy Final Authorization Decision made by the end producer of the information

Authz strategy summary contd We will need some sort of policy language based on a view. Can we use GACL? Producer will need to publish the access control on the views. When a table is created, the access control on the various views will also have to be created Producer, Registry and the Mediator Function will need to understand Authorization based on views. Some confidential authorization information will have to go with the end producer E.g. the mediator should not know if a user is banned. Combination of delegation AND decision being made by the provider of information preserves confidentiality

? Application Code Consumer Instance Consumer API Registry Producer Delegation (from application’s cert) Delegation (from producer’s cert) Application Code Consumer Instance Registry decides consumer y/n? Consumer API Registry API Consumer decides- application y/n? Registry Schema API Producer decides- application y/n? Producer decides- sensor y/n? ? Producer makes a decision “can this sensor write to here” Registry makes a decision “can this producer register here” or possibly “can this sensor write to here” Consumer makes a decision “Can this application client access me” If so, it makes the request to the registry. Registry makes the decision “can this application client have access to producer info requested” If O.K. the Consumer contacts the Producer – the producer decides “can this application client have the information requested” if yes, passes it on. Producer API Registry API Schema Producer Instance Sensor Code Registry decides producer to register y/n?

Without Delegation it is possible to obtain info one is not authorized to see. But it requires a consumer to be hacked or written. DN DN info matches Rogue Consumer has acceptable Certificate. Rogue Consumer

How to prevent copying to unauthorized sites? 2 way authorization been talked about in context of storing sensitive data Have to trust a user who has access to data not to copy it to somewhere that is not secure. Thus – we should only allow data to be archived/replicated/copied to consumer/producer if those are trusted. Better only allow sensitive data to be accessed directly? The more I think about it, the more I think we are opening a can of worms.

Authorization without delegation First just have user’s only seeing their own jobs. Only way to do this in the absence of delegation is extract the DN of the user when they connect to the consumer Pass this onto the producer Add to job info table that DN must match Only allow the user to see the job if DN matches Not secure – anyone with an acceptable certificate could get the info – but they would have to write their own consumer code I don’t think there’s that much point in implementing authorization without delegation – except as a step forwards.

Mixing secure and non-secure access Allowing different access rules after authentication fits quite well into R-GMA. Allowing a mixture of secure and non secure access is more difficult. Authentication happens before connection Authorization happens within the servlet So for non-secure access – would need a different copy of R-GMA on a different port. Problem is for us – 1 R-gma does everything. Ideally, would need different service for non-secure access, I.e. a cut down R-GMA which just allows certain things.

Plan We should find out EXACT minimum requirements on job info What is confidential What needs archiving What needs accessing by who Work out what we need to do to satisfy this Favour the solution being as general as possible, e.g. 1 rule that is defined – extend to a whole load of rules later Make an estimate of the manpower needed

1st Version Authz for R-GMA Based on DN only – no VOMS No Mediator Authz function Producer (and Archiver and/or Producer/Consumer if necessary) carry out Authz based on DN only Need Authz to copy from the producer. Policy language based on a view. GACL on a view probably has the functionality we need How to implement Views? This is probably the minimum worth doing.