Support email in othername attribute of smartcard SAN extension
Problem to solve
In GitLab's smartcard authentication integration, SAN extensions with the following format are supported:
X509v3 Subject Alternative Name:
email:gitlab-user@example.com
This issue proposes supporting SAN extensions with the email in the othername
field:
X509v3 Subject Alternative Name:
othername:<unsupported>, othername:<unsupported>, URI:urn:uuid:XXXXXX
A Premium customer is requesting this feature in ticket https://gitlab.zendesk.com/agent/tickets/152349 (internal use only). This customer has their email defined in an othername
field, as a Microsoft User Principal Name (msUPN) encoded as a UTF8 string.
It was discussed in a previous issue that the email could be found in this othername
field, and that a possible iteration would be to make this field configurable, so the user can identify what field the email is in.
Intended users
Also anyone who logs in via Smartcard authentication
Further details
For the customer above, if I query their PEM certificate from the Smartcard authentication, I get the following:
$ openssl x509 -text -noout -in certificate.pem
Certificate:
...
X509v3 Subject Alternative Name:
othername:<unsupported>, othername:<unsupported>, URI:<REDACTED>
...
$ openssl asn1parse -in certificate.pem
...
856:d=4 hl=3 l= 136 cons: SEQUENCE
859:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Subject Alternative Name
864:d=5 hl=3 l= 128 prim: OCTET STRING [HEX DUMP]:<REDACTED>
...
$ openssl asn1parse -in certificate.pem -strparse 864
0:d=0 hl=2 l= 126 cons: SEQUENCE
2:d=1 hl=2 l= 39 cons: cont [ 0 ]
4:d=2 hl=2 l= 8 prim: OBJECT :2.16.840.1.101.3.6.6
14:d=2 hl=2 l= 27 cons: cont [ 0 ]
16:d=3 hl=2 l= 25 prim: OCTET STRING [HEX DUMP]:<REDACTED>
43:d=1 hl=2 l= 36 cons: cont [ 0 ]
45:d=2 hl=2 l= 10 prim: OBJECT :Microsoft Universal Principal Name
57:d=2 hl=2 l= 22 cons: cont [ 0 ]
59:d=3 hl=2 l= 20 prim: UTF8STRING :<REDACTED>
81:d=1 hl=2 l= 45 prim: cont [ 6 ]
Proposal
Add support to the SAN Extension code in the Smartcard integration to get emails from othername
fields in the SAN extension, such as the msUPN
OR, have the SAN field be configurable, so users can set which field in the SAN contains the email
Documentation
Smartcard Documentation: https://docs.gitlab.com/ee/administration/auth/smartcard.html
Availability & Testing
Smartcard RSpec Tests: https://gitlab.com/gitlab-org/gitlab/-/tree/v12.9.2-ee/ee/spec/lib/gitlab/auth/smartcard
What does success look like, and how can we measure that?
Customers can use their Common Access Cards (CAC) that have this style of SAN extension for the GitLab Smartcard Authentication, and successfully authenticate to GitLab.
What is the type of buyer?
Premium and above feature
Is this a cross-stage feature?
No, just Manage