indigo-iam
Indigo IAM incorrectly considers IGTF certs with same subject but different issuer as distinct
Not sure if this is still an open issue, and see also issue #1007 which seems related.
Using the dteam Indigo IAM-based voms server hosted at CERN, I noticed that it considers IGTF certificates with the same subjectDN but different issuerDN as different. This is contrary to the EGI & IGTF policy/requirement to skip the CA, since it causes problems e.g. with TCS certs where the CA and issuer often changes between generations (currently the 5th) while the subject DNs stay the same. Within IGTF it is safe to consider only the subjectDN since within IGTF this is guaranteed globally unique. See e.g.
- https://docs.egi.eu/providers/operations-manuals/howto01_using_igtf_ca_distribution/#reminder-notice-for-voms-aa-operators
- section 2 in https://www.eugridpma.org/newsletter/eugridpma-newsletter-20150601.txt
I was not aware of that IGTF policy, but #1007 was filed because if you tried to unlink one old certificate from your user profile, all certificates with that subject were unlinked, including the one still valid. Is there any other operation that is currently mismanaged, based on that IGTF policy?
I was not aware of that IGTF policy, but #1007 was filed because if you tried to unlink one old certificate from your user profile, all certificates with that subject were unlinked, including the one still valid. Is there any other operation that is currently mismanaged, based on that IGTF policy?
It sounds like #1007 is actually invalid (at least for the IGTF/EGI use cases): the user should be identified by the subjectDN alone, basically the --skipcacheck for VOMS. In other words, for IGTF and EGI, it doesn't make sense to have multiple certificates with the same subjectDN but different issuerDN linked. If there are use cases for having that, it probably should be configurable like it was for VOMS.
#1007 was triggered by the fact that I had in my profile two certificates linked, with the same subject and different issuers, one new, one old. And I wanted to remove the old one. Don't you agree that such situations is normal? If not, that would imply that when I added the new certificate, IAM would automatically remove the old one. And now that I think more about it, the fix is only partial, because one of course could have multiple certificates with the same subject+issuer, so we need something else to uniquely identify a linked certificate. Maybe we could leverage the label.
I'm not sure why you would want to pin/store a specific certificate? In grid use-cases we never do that, a user is identified by its subjectDN (and in non-IGTF the combination subjectDN/issuerDN). A specific certificate would by the way be identified by issuerDN and serial, so for pinning, you would need to store that too. I'd say you when the user wants to link a certificate based on input from a certificate, you verify the cert and register the subjectDN and issuerDN, and for subsequent identification either both (non-EGO/IGTF) or just subjectDN is used for checking it's the same user? It's like storing a saml assertion instead of just the ePPN, ePUId or subject-id in your database, that also isn't what you want to do/probably don't do?
The fact that I had two certificates with the same subject and different issuers is very likely due to having imported them from VOMS, although I cannot swear. IAM can store also full certificates; don't ask me why. IAM also allows to store a (long-term) proxy; I don't know if there is some interplay between that and storing the full EE certificate instead of just the subject. We may revisit this old business, but not now :-)
Hmm, but the fact remains that everyone with a TCS <5 cert will need to manually add their new cert. And if there will be similarly changes of issuerDN for other CAs, users of those CAs will also need to manually update the cert. This is highly non-ideal and affects at least the dteam VO.
Instead of pointing to #1007, which I consider correctly fixed for how things are done at the moment, you should have pointed to commit e0180df :-), where the following change was included in multiple places:
- Optional<IamAccount> account = accountRepository.findByCertificateSubject(principal);
+ Optional<IamX509Certificate> cert = x509CertRepository
+ .findBySubjectDnAndIssuerDn(credentials.getSubject(), credentials.getIssuer());
on request by people who were evidently also not aware of the IGTF policy. We'll review the change.
Instead of pointing to #1007, which I consider correctly fixed for how things are done at the moment, you should have pointed to commit e0180df :-), where the following change was included in multiple places:
- Optional<IamAccount> account = accountRepository.findByCertificateSubject(principal); + Optional<IamX509Certificate> cert = x509CertRepository + .findBySubjectDnAndIssuerDn(credentials.getSubject(), credentials.getIssuer());on request by people who were evidently also not aware of the IGTF policy. We'll review the change.
thanks for pointing to that one. Is there a corresponding issue by any chance?
Hi all, I keep having to solve issues for DTeam / Ops VO users with new certificates from different CAs, as also discussed in #527. Mind that we need to allow both a user's current and next certificate (with different subject and/or issuer) to be linked to the account at the same time, so IAM must be careful about when to check just the subject vs. when to check subject + issuer...
Hi all, I keep having to solve issues for DTeam / Ops VO users with new certificates from different CAs, as also discussed in #527. Mind that we need to allow both a user's current and next certificate (with different subject and/or issuer) to be linked to the account at the same time, so IAM must be careful about when to check just the subject vs. when to check subject + issuer...
And that is exactly the reason IGTF wants one to only consider the subject, since within IGTF subject uniqueness is guaranteed, i.e. if two CAs issue the same subject, it MUST be the same person etc.