### Problem to solve The [domains whitelisting](https://gitlab.com/gitlab-org/gitlab/issues/7297) feature was implemented after one of our employees requested it - however we've been unable to enable / use this feature as we often need to bring users who do not have a corporate e-mail account at our company's domain (e.g. clients) into our GitLab projects, and so with the current behaviour it's not possible to enable the domain whitelist because we are unable to add more than a single domain to the whitelist. ### Intended users Initially GitLab admins will use this feature, to allow them to specify a list of domains from which users can be added from - the users actual vertical (e.g. Product Manager, Developer) isn't clear to me at this point. ### Further details This minor change makes the domain whitelisting feature more flexible and therefore hopefully more useful to users who work collaboratively with external stakeholders. It also promotes improved security/privacy in that it could help more users lock down their GitLab organisations and prevent them from accidentally granting access to people who should not be given access. ### Proposal It was proposed in https://gitlab.com/gitlab-org/gitlab/issues/7297#note_174792745 that the values in the input could simply be separated by a delimiter (e.g. `;` or `,`). I'm not sure if you already have a UI pattern for this sort of multi-input so if that's inline with the existing pattern if one exists then fine. #### First iteration A comma separated list of email domains  #### Second iteration Implement the GitLab UI "Token Selector" component: #220567 ### Permissions and Security The permissions required to edit the domain whitelist field should not be changed as part of this proposal. ### Documentation I couldn't find any docs for the existing domain whitelist configuration (but I'm not sure if I was looking in the right place), so that should probably be added and expanded upon for this change. ### Testing TBD ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### What is the type of buyer? This is an additional security feature, so should probably belong to Gold/Ultimate. ### User reports/requests 1. https://gitlab.zendesk.com/agent/tickets/133973 1. https://gitlab.zendesk.com/agent/tickets/134012 1. https://gitlab.my.salesforce.com/00161000004xUpi ## Issue readiness * [x] Product: issue description is accurate with an acceptable proposal for an MVC * [x] Engineering: issue is implementable with few remaining questions, is sufficiently broken down, and is able to be estimated