Restrict omni auth to admins only

we want to be able to use the “clone project from github, bitbucket, etc” functionality, but need to restrict that capability to admins only. (ideally a new role, not admins, but thats another problem for another day) for now, admins. Is this possible?

Here’s the end result I want.

  1. Developers can login with ldap and ldap only. I can’t stress that enough, LDAP only, no other option what-so-ever.

  2. If a developer wants to play with OSS code, they file the ticket with our internal tech council. If our tech council approves the request, the request is forwarded to our Platform Build and Deploy team, who are the gitlab system admins. They then can clone the project into our gitlab system, grant appropriate permissions and close the ticket.

As an alternate, It would also work if I could enable the functionality and only allow it to happen thru the REST API. That way our tech council can add the new project in our automation system and our automation system hits the REST api and instructs GitLab to clone down the project. This is how I imagine we will keep the projects that are pulled down in sync with their parent github projects.

Either way, the developer must not have this capability. I would prefer it if they didn’t even know it was possible.

Can this be done?

I definitely know you can configure Gitlab to only accept LDAP. The problem I had with rolling that out, is that I still want to log in with non-LDAP accounts when LDAP is down, and be able to administer the system.

I ended up leaving both LDAP and non-LDAP login options open and told my users to use the LDAP page. I disabled signups and now regular users effectively have to use LDAP to get going.

As far as restricting the clone feature, I think that’s a silly idea. If you restrict users from doing that, you can’t STOP them from creating another repo, empty, and pulling from github and then pushing to you, unless you block them from pushing. What did you hope to accomplish?


first, with 35,000 users, if LDAP goes down, i assure you, GitLab will be the least of our concerns. so making it 100% LDAP is and absolute requirement.

2, Our developers are free to create projects within their personal group. For public (to us) groups, no human can create new repos by corp policy. Only our automated ticket systems can create those repos thru the REST service. That’s the only way that we can ensure that our asset inventory is square with reality. All new apps and libraries must be passed thru the asset inventory system.

3, We already solved the gitlab, bitbucket, maven central, mvnrepository,, etc problem years ago. We block the sites thru our firewall. No developer can get to them at all. Even disconnected from our network, systems on the laptops themselves prevent you from going to github, etc. And you must have an admin password (which only desktop services has) in order to mount a USB stick plugged into the system. And the Windows policy is tweaked to prevent anyone from mounting a drive that isn’t in their corp login policy.

Now, all that in place keeps our security auditors happy, our third party auditors happy, the feds happy, everyone’s happy. But, no one can deny that sometimes its easier to look at the code for a library to figure out how to use it. So, I got the handshake approval from my security department that they will sign off on putting the gitlab server on the net for outgoing only (of thousands of servers, only a handful are actually on the internet) and allowing the build and deploy admins to clone approved projects into an OSS group for developers to access the code, but ONLY if i can make a 100% guarantee that developers cannot use this feature. Only admins can use it. That’s it.