User self-service of uploading DNs

[bbockelm]

Currently in VOMS-Admin users can upload their own DNs manually. This is often used for robot certificates today as we assume all users already have their certificate in the browser.

IAM cannot do this - certificates can only be linked to the identity if they are taken from the TLS connection. This makes it difficult to upload a robot certificate for a user (assuming that users aren't invoking REST APIs).

Additionally, as we transition to tokens, I don't think it's safe to assume users will still have certificates in their browsers... meaning this will become an important issue.

[vokac]

In the near future (summer) we'll rely exclusively on IAM VOMS AA and that means resolution of this issue is getting more important.

[federicaagostini]

Hi all, we are setting up priorities for VOMS Admin EOL related issues and this one is on our roadmap.

Please just remember that right now an IAM admin can upload any certificate (the full one, not only DN and issuer) to any user, so this workaround is already in place. Anyway, to my understanding what is missing compared to VOMS is:

• a user can upload not only its certificate, but also DN + Issuer
• then, a request is automatically sent to admins, who have to approve this "certificate linking"
• an admin can link a DN + Issuer without any approval step.

Do you agree with the modifications needed in IAM?

[maarten-litmaath]

Hi all,
today, an admin can paste a certificate into any account except the admin's own account --> that needs to be fixed...

When we allow a user to paste DN + CA strings, we will again open the door to errors, in particular w.r.t. to the format of those strings: classic format with '/' separators vs. modern comma-separated formats (forward or backward)...

I therefore do not mind that the actual certificate has to be pasted by users.

However, admins could be given the DN + CA option, but then there should either be clear instructions provided next to the input panels, or the code should accept multiple reasonable formats...

[maarten-litmaath]

Hi all,
I also would like to see an option for VO admins to be at least informed of certificate operations, as there may be follow-up actions needed in other services of the VO...

Even better would be an option for VO admins to approve such operations...

[vokac]

May be IAM could validate that user certificate is really "grid personal certificate" (using CaNL & /etc/grid-security/certificates), because we already saw cases where user took personal certificate from their institution which can't work with voms-proxy-init (this can be detected only later with our gridCert validation tool). For our experiment with many users we would like to avoid additional load on VO admins.

[darcato]

Hello,
currently we are implementing the functionality this way:

• Both the user and the admin can link a certificate to their account
• The admin must approve certificate linking requests from normal users
• The certificate can be added via PEM or subject and issuer
• The issuer can be chosen among a list of "known" CAs (igtf and system certificates).
• The subject format will be checked to be compliant with the comma-separated standard (rfc 2253)

Other features will be considered later:

• We can add the support for other formats of the subject at insertion time and convert them.
• Inform the admins when the user links a certificate automatically through the browser. We can discuss how to do this, but we are thinking about adding it to the AUDIT log. In the other cases the admin is already informed, since he has to approve the request.
• Add some validation on the content of the subject?

Do you see any major problem with this approach?

[maarten-litmaath]

Ciao Davide,
would it be possible to add an option to prevent the automatic linking through the browser?

That is, configure IAM not to offer that functionality?

It would allow an admin to:

1. do a sanity check of the proposed certificate;
2. update other places with the new DN, if it looks OK.

[darcato]

It's surely doable but I'm not sure if it's planned. I ask @giacomini about this.

Otherwise you can already disable this functionality by adding a reverse proxy in front of IAM.

[giacomini]

Could it be possible to add an option to prevent the automatic linking through the browser?

That is, configure IAM not to offer that functionality?

Yes, but I would prefer not with this PR. However:

It would allow an admin to:

1. do a sanity check of the proposed certificate;

What kind of sanity check do you have in mind? I think that you can only link a certificate that has been issued by one of the CAs that are trusted by IAM (system ones and IGTF).

2. update other places with the new DN, if it looks OK.

My preferred mechanism to make an admin aware of this (and other events) is to use the audit log. Alternatively we could send a mail notification.

[maarten-litmaath]

Hi all,
a user could still present the wrong IGTF certificate, or one from a problematic CA (e.g. based on a SHA-1 root that is not supported everywhere).

Admins cannot be expected to browse the audit log for such events; there has to be an e-mail notification, OK?

[giacomini]

Hi all, a user could still present the wrong IGTF certificate, or one from a problematic CA (e.g. based on a SHA-1 root that is not supported everywhere).

So we should transform the "link certificate" action to a request to be approved, if IAM is so configured. Is that ok?

Admins cannot be expected to browse the audit log for such events; there has to be an e-mail notification, OK?

In an ideal future world I expect that notifications are available in multiple ways based on what appears in the audit log. But in the meantime we can extend our notification mechanism, like we are doing for user suspension/restoration.

[maarten-litmaath]

OK & OK, thanks!