Certificate and VOMS Based Authentication & Authorization - Work Binder Grid Service

From EGEE-see WIki

This Wiki page is a part of SEE-GRID Gridification Guide. It is contributed by Belgrade University Computer Centre.

1 Introduction
2 Certificates
3 Verification
4 Resources
5 Contact

Introduction

Here you can find some information about authentication & authorization that any grid service can implement through example of the Work Binder service. Work Binder is a generic service developed in Java whose main purpose is to quickly allocate new jobs for Grid users. More info on the Work Binder can be found at Work Binder Application Service.

Please note that this article should not in no way be considered as an official manual to authentication & authorization, its only intention is to provide developers of the grid applications/services some ideas and resources about understanding and perhaps implementing their own solutions.

[edit]

Certificates

Since X509 certificates are an integral part of the grid infrastructure it is only logical that most grid services use them for authentication & authorization purposes. Every grid user must own its own certificate and private key. Since many services do some work remotely on behalf of the user, some way of delegating credentials is required because sending the user's private key over the network is unacceptable. For this purpose proxy certificates are introduced. They contain a chain of certificates made from generated proxy certificates (in most cases this chain contains only one more certificate besides the user's original one) and the user's certificate, as well as unencrypted proxy key. Proxy certificate lasts some short time (usually from 12h to 24h), much shorter then the original user's certificate and can be distributed over a network to trusted machines. Even if it is somehow stolen, it is considered that it lasts short enough not to cause too much damage.

Proxy certificate is created by contacting the VOMS service from the user's original certificate and the information received from the VOMS service. It contains some more data then the raw certificate, called the Attribute Certificate.

Detailed information about X509 & Attribute Certificates as well as their verification can be found at RFC 3280 and RFC 3281.

[edit]

Verification

Verifying user's credentials consists of checking the certificate (or the certificate chain in case of the proxy certificate). These verification algorithms can be found in RFCs 3280 & 3281. Supposedly full implementation of this verification can be found at org.glite.security.voms cvs and more utils can be found at org.glite.security.util-java cvs. Repository of updated trusted CA certificates is usually kept on every grid server in the /etc/grid-security/certificates/ directory. Above mentioned implementations keep a store of trusted CA certificates refreshed periodically in the memory. User's certificate is then verified using the certificates in this store. For some purposes this implementation can have an undesired performance overhead.

In case of usage of the actual user's certificate, since the certificates are generally freely distributed over the networks, in order to finish the process of authentication of the user it is needed to verify whether the user has a proper private key associated with the certificate. For instance, this could be implemented by sending the user some randomly generated challenge encoded with the public key located in the certificate and demanding that the user responds by sending back the decoded challenge (which can only be decoded via the private key).

Should a proxy certificate be used, it is possible to read additional information received from the VOMS server included in the proxy. This information can be used to perform authorization of the user by mapping the user to some application dependent group or role. Benefit of using this approach is in the fact that both authentication & authorization can be performed in a single step by verifying user's certificate chain and the attribute certificate. Downside is in the fact that creating a proxy certificate can sometimes be difficult when users don't wish to run their clients from the grid UI.

Work Binder supports usage of both actual users' certificates and proxy certificates for user authentication & authorization. It implements its own lightweight verification of certificates by reading only the needed trusted CA certificates once the user has connected. The authorization is done by contacting the VOMS services to check whether the user has access to the supported applications. This is implemented by connecting to the SOAP interface of the appropriate VOMS web service. Every VOMS service has a WSDL file describing it. Using WSDL2Java it is possible to create stubs & data types to access the VOMS service and retrieve information about VO groups & roles (and much more!) using the provided methods. This way Attribute Certificate verification is ignored and users are allowed to use either their own certificates or proxy certificates. Of course, certain limitations are imposed in the usage of actual certificates since user's private key can (and should!) never be transferred over the network.

[edit]