Analysis of usage of short lived certificates in UNICORE

Objective

Short lived certificates are going to be used in EMI middlewares as a part of a unified solution allowing for AAI integration. The aim of the task was to verify whether the usage of short lived certificates will be anyhow problematic in UNICORE. The work was concentrated on the server side as it is already known that modifications on the client side will need to be performed.

Verification process

For the verification purposes a complete installation of UNICORE was used, comprising of Unicore/X with Perl TSI, Workflow service, Services Orchestrator, Shared Registry. All services were installed behind UNICORE Gateway. Two UNICORE attribute sources were evaluated: XUUDB and UVOS. The simple File attribute source was not used as it is not aware of certificates at all and operates exclusively on DNs so there is nothing to check in its case.

The following list of actions was executed:

1. submit a workflow job using certificate A to the workflow service,
2. get the workflow's status using certificate B,
3. get output files using certificate B.

The workflow job executed a simple 'sleep' command and after the wait was completed produced a random text saved to a file. Finally the file was exported to the UNICORE global storage. Such an approach guarantees usage of all installed components, most of them several times.

Certificate A and B had the same DN, were issued by the same CA and had different validity periods. The above list of actions was performed several times:

1. using XUUDB in DN-mode; certificate A and B were valid through the whole test.
2. using XUUDB in DN-mode; certificate B was valid through the whole test, certificate A was valid only at the beginning of the test and was expired before the job completed.
3. using UVOS storing DN-type identities; certificate A and B were valid through the whole test.
4. using UVOS storing DN-type identities; certificate B was valid through the whole test, certificate A was valid only at the beginning of the test and was expired before the job completed.

Results

In general all the results were exactly as expected.

Cases 1. and 3. were performed without any problems.

Cases 2. and 4. were performed partially successfully: UNICORE workflow service was unable to export job's result file to the global storage as ETD trust delegation assertion issued at the beginning of the job expired together with the certificate used to sign it. Nevertheless when using certificate B, access to all workflow artefacts (e.g. job's status, job's working directory) was possible.

It was also noted that the client (UCC in this case) was issuing a warning for certificates expiring soon (exactly - in one week):

WARNING: your certificate will soon expire! The validity period ends Sat Apr 23 16:00:00 CEST 2011

There were no unexpected warnings or errors in log files of server components.

Conclusions

No server side work is required in UNICORE when adopting short lived certificates on the client side. All UNICORE attribute sources may be used, however identities should be stored as distinguished names, not full certificates. This should not be a problem as this is a suggested and common approach also for long lived certificates, which makes users maintenance simpler.

The expiration of ETD assertions at the moment of its associated certificate expiration is a correct behaviour. This should not be a problem in vast majority of cases unless a user starts to submit jobs with certificate expiring before the expected job termination. Support for this on the client side is simple to be implemented. Additionally a new functionality planned anyway for UNICORE, namely the feature to have a centralized ETD store per container, will be able to further reduce the problem's severity. Container would be able to use the best (here having the longest validity) ETD assertion, not the one originally submitted with the job.

It may be also noted that the current client's behaviour to print a warning when the client's certificate is expiring in one week should be changed. Simple solution is to print such a warning when the expiration moment is close, but not using the constant threshold of one week. Instead dynamically computed threshold may be used, being a fraction of a total certificate validity.