DIRAC uses X509 for authentication. Proxies are an extension to the traditional X509 certificate PKI infrastructure. For a detailed explanation, please see the RFC 3820.
Handling the proxies and certificates within DIRAC is done with the classes in
DIRAC.Core.Security. Please look inside the various classes documentation for details.
These classes are used only for manipulating the objects and the information they contains. The use of the X509 entity for establishing connections is done directly with the underlying libraries (openssl)
One important mechanism is the delegation mechanism. This allows to give credentials to a remote entity, without every having a private key going through the network. This principle is used everywhere: when uploading a proxy to the proxyDB, when retrieving it, when submitting a transfer to FTS, when getting VOMS attributes, etc. The principle goes as follow:
The client tells the server that it wants to delegate.
The server generates a certificate request containing the public key, and the corresponding private key.
The server sends to the client the request (containing the public key)
The client signs the request using its own private key, and sets the subject of this new certificate as its own, appending some CN field (here the clients also decides the lifetime of this certificate!)
The client sends the signed certificate, appending its own certificate chain, back to the server
The server stores the new certificate together with the private key it has from before. This is now a full proxy
The “magic” happens when the storage (or any other endpoint needing a certificate) gets the proxy certificate. It then start following up as this
/DC=cern/CN=user/CN=proxy/CN=proxy signed by /DC=cern/CN=user/CN=proxy, do I have the signer’s certificate?
Yes, it is part of the proxy chain. OK, /DC=cern/CN=user/CN=proxy is signed by /DC=cern/CN=user, do I have the signer’s certificate?
Yes, it is part of the proxy chain. OK, /DC=cern/CN=user is signed by /DC=cern, do I have the signer’s certificate?
Yes, it is a ROOT CA (/DC=cern) I know and trust, so the full chain can be trusted
Some proxy might be limited. a limited proxy has an extra flag set that, by convention, is checked by job submission services that, by convention, shall refuse limited proxies for further job submissions.
Such services shall accept regular proxies _and_ create limited delegations of those proxies that in turn will be used to equip the jobs. A limited proxy cannot lose its limitation in further delegations. All this machinery is needed to prevent that jobs can submit other jobs and thus create a job storm. That is particularly important to prevent such an abuse of stolen proxies.
Data management services shall simply ignore the flag.