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

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

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

4. User VOMS service service Java C authr LCAS pre-proc pre-proc acl acldn
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

5. User service Java delegation service authr pre-proc acl map authrdn
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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