Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup of linked certificates #15

Open
vokac opened this issue Dec 12, 2022 · 6 comments
Open

Cleanup of linked certificates #15

vokac opened this issue Dec 12, 2022 · 6 comments
Assignees

Comments

@vokac
Copy link
Contributor

vokac commented Dec 12, 2022

New certificates are added with link_certificate, but for full synchronization it is also necessary to remove DNs that no longer exists in the source VOMS. We are just aggregating in IAM bad / incorrect DNs that were cleanup long time ago from VOMS and to be able to use IAM SCIM as account source for other services (e.g. Rucio) we should get rid of these problematic entries that sometimes even don't have correct encoding for DN.

@giacomini
Copy link
Contributor

In practice this would mean removing all certificates from IAM before adding the ones present in VOMS. But in this way you can't add a certificate only in IAM.

@vokac
Copy link
Contributor Author

vokac commented Jan 13, 2023

I'm able to delete individual problematic certificate with

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "operations": [{
      "op": "remove",
      "path": "certificates",
      "value": {
        "urn:indigo-dc:scim:schemas:IndigoUser": {
        "certificates": [{
          ... all cert details ...
        }]
      }
    }
  }]
}

@giacomini
Copy link
Contributor

Sure, you can also do it from the dashboard. But how does this address the issue?

Before finding a solution, we should probably answer the question: what is a problematic certificate?

@vokac
Copy link
Contributor Author

vokac commented Jan 13, 2023

People in the past got certificate from CN=TERENA eScience Personal CA 3,O=TERENA,L=Amsterdam,ST=Noord-Holland,C=NL issuer which is now replaced with CN=GEANT eScience Personal CA 4,O=GEANT Vereniging,C=NL. Certificates issued by these CAs have same subject and that mean due to indigo-iam/iam#454 new certificate can't be imported in IAM without cleaning old one first.

@giacomini
Copy link
Contributor

Ok, but assuming indigo-iam/iam#454 is fixed, would this be enough to consider also this issue (and #8) fixed? I fail to see how the importer can be changed to address this issue (and #8).

Maybe we can run a one-time campaign to clean from IAM the certificates with issuer "CN=TERENA eScience Personal CA 3". That should be possible with the APIs.

@vokac
Copy link
Contributor Author

vokac commented Jan 13, 2023

With indigo-iam/iam#454 fixed import is still not perfect, but we can live with that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

2 participants