Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab GitLab
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 38,037
    • Issues 38,037
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 1,345
    • Merge requests 1,345
  • Requirements
    • Requirements
    • List
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #33907

Closed
Open
Created Oct 11, 2019 by Sebastián Arcila Valenzuela@sarcilaContributor0 of 1 task completed0/1 task

Smartcards allow to use SAN extensions without matching emails and URI

Problem to solve

The solution as implemented in #8605 (closed) got the email address from the Subject Alternative Name (SAN) field of the EMAIL cert, as anticipated. However, it also required that the SAN contain the URI that matched the hostname of the GitLab server. This won’t work for CACs that are issued globally, and so won’t be tailorable specifically to GitLab.

Intended users

Further details

Proposal

Only do URI check if there's multiple email definitions

Permissions and Security

Documentation

Testing

  • Need to check that this doesn't introduce opportunities to impersonate or deface users

What does success look like, and how can we measure that?

Users using smartcards with SAN extensions should be able to login into gitlab, on the following two scenarios:

  1. The user certificate only has one email entry in the SAN extensions and it should be used to login into gitlab
  2. The user certificate has multiple email entries and should only use the one that match the URI as described here https://docs.gitlab.com/ee/administration/auth/smartcard.html#authentication-against-a-local-database-with-x509-certificates-and-san-extensions-premium-only

What is the type of buyer?

Premium

Links / references

/label feature

Edited Oct 11, 2019 by Liam McAndrew
Assignee
Assign to
12.6
Milestone
12.6 (Past due)
Assign milestone
Time tracking