1. OAuth简介

OAuth 代表资源所有者向客户端应用程序提供对服务器资源的“安全委派访问”。实际上，OAuth 允许授权服务器在获得资源所有者或最终用户的批准后向第三方客户端颁发访问令牌。

OAUTH 协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是 OAUTH 的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此 OAUTH 是安全的。oAuth 是 Open Authorization 的简写。

GitLab目前支持以下授权流程：

• Web application flow：最安全和最常见的流程类型，专为具有安全服务器端的应用程序而设计。

• Implicit grant flow：此流程专为仅用户代理的应用程序（例如，在GitLab页面上运行的单页面Web应用程序）而设计。

• Resource owner password credentials flow：仅用于安全托管的第一方服务。

如果想使用其他 OAuth 身份验证服务提供商（例如 GitHub、Facebook 等）登录 GitLab，请参阅 OAuth2 客户端文档。

OAuth 主要用作单一登录服务（SSO），但也可以在此功能中找到许多不同的用途。例如，可以允许用户使用他们的 GitLab.com 帐户登录你的应用程序，或者可以使用 GitLab.com 对你的 GitLab 实例进行身份验证（请参阅 GitLab OmniAuth）。

GitLab Importer 功能还使用 OAuth 协议访问存储库，无需将用户凭据共享到您的 GitLab.com 帐户。

GitLab 支持两种向实例添加新的 OAuth2 应用程序的方式。你可以将应用程序添加为常规用户，也可以将其添加到管理员区域。这意味着 GitLab 可以具有实例范围和用户范围的应用程序。除了它们设置的不同权限级别（用户/管理员）之外，它们之间没有区别。默认回调网址是 http://your-gitlab.example.com/users/auth/gitlab/callback

>>> 几种常用的认证机制 | 理解OAuth 2.0 | OAuth认证原理与第三方登录

2. Gitlab OmniAuth 认证

配置 OmniAuth

配置 OmniAuth（默认禁用） 不会阻止标准的 GitLab 身份验证或 LDAP（如果已配置）继续工作。 用户可以选择使用任何已配置的机制来登录 GitLab。

在配置 OmniAuth providers 之前，有几个全局设置是需要考虑的：

• OmniAuth 默认禁用

• allow_single_sign_on 允许您指定要允许自动创建帐户的 providers，默认为 false。 如果为 false 的话，用户必须手动创建用户，否则他们将无法通过 OmniAuth 登录

• 如果已启用 LDAP/ActiveDirectory，则可以使用 auto_link_ldap_user，默认为 false。 启用后，通过 OmniAuth 自动创建的用户也将链接到其 LDAP 条目。

• block_auto_created_users 默认为 true。 如果为 true，那么自动创建的用户将被默认阻止，并且必须由管理员解除阻止才能登录。

注意：

• 如果将 block_auto_created_users 设置为 false，请确保只定义您能够控制的 allow_single_sign_on 下的 providers （如 SAML，Shibboleth，Crowd 或 Google），或将其设置为false，否则互联网上的任何用户都可以成功登录你的 GitLab。

• auto_link_ldap_user 要求 LDAP 和 OmniAuth provider 中用户的 uid 相同。

3. 添加 Application

Gitlab允许用户创建Applications， 这些Applications可以通过OAuth2授权来访问Gitlab的相应资源。

在Gitlab中， Applications分两种, 第一种是用户级别的Application，点击右上角的用户头像后，点击 Settings 进入设置页面，然后点击 Applications 开始创建 application。

第二种是系统级别的Application， 只有管理员权限的人通过Admin菜单进入创建,以系统级别的Application为例来注册一个Application：

在创建 application 的表单中，输入任意一个名称，并确保正确设置重定向 URI（用户在用 GitLab 授权后跳转到的 URL）。

选择合适的“Scopes”。

• api：访问经过身份验证的用户 API。以用户身份完全访问 GitLab，包括对其所有组和项目的读/写。

• read_user：阅读经过验证的用户的个人信息。以只读方式访问用户的个人资料信息，如用户名、公共电子邮件和全名。

• sudo：以系统中的任何用户身份执行 API 操作（如果经过身份验证的用户是 admin）。

• read_repository：读仓库。

• openid：使用 OpenID Connect 进行身份验证。使用 GitLab 进行身份验证的能力以及对用户个人资料信息和组成员身份的只读访问权限。

点击提交时，将获得 application ID 和 application secret，然后可以将其与连接到 GitLab 的应用程序一起使用。

GitLab 的 OAuth 应用程序支持范围（scopes），用来设置应用程序可以执行的操作。目前支持的范围有：api，read_user，sudo，read_repository 和 openid。 

将这个页面的信息分发给相应的Application应用负责人，开发人员将使用这些信息做认证。

应用授权

应用注册成功后， 应用的实例就可以作为一个认证实体向Gitlab认证自己， 如果认证成功， 就可以获取一个代表某个用户权限的access token对Gitlab的资源进行访问。

GitLab as an OAuth2 client这篇帮助文档其实说的就是这个过程，简单说下授权的过程：

首先， 我们创建了一个Web应用， 这个Web应用就是我们注册为Gitlab上的那个Application， 当用户初次访问这个Application的时候（比如访问http://your.application.host/)， 我们需要获得Gitlab上某个用户的授权，以便代表这个用户来访问Gitlab上的资源并做一些事情， 所以，我们直接将用户请求redirect到gitlab的某个url下， 这个url就是http://{your.gitlab.server}/oauth/authorize， 当然， 我们需要通过参数带上一些必要的请求信息，以便gitlab可以决定给谁授权， 这个url后面一般需要带上以下几个参数：

1. client_id， 也就是我们注册Application成功后分发给你这个Application的Application Id;

2. redirect_uri, 在注册Application的时候我们自己提交的Callback url， 因为我们在本地调试， 所以其实就是http://localhost:8080/callback这个url， 如果是线上应用，一般直接在注册的时候（或者之后Edit）输入对应的域名标识的url；

3. response_type=code, 固定字符串， 表示我们使用OAuth2的Authorization Code Grant授权模式；

当请求被重定向到以上gitlab的url的时候， gitlab会显示授权页面要求当前已经登录gitlab的用户授权当前Application代表它来访问Gitlab的各项资源。

不管用户是点击了“Authorize”同意授权还是“Deny”拒绝授权， gitlab都会将web请求重定向到Application注册的时候提供的Callback url地址上（例如：http://chegva.com/callback）， 然后Application的对应这个url地址的Action就可以根据授权结果来决定后继行为了。

如果用户授权， 则Application会收到一个授权code， 使用这个授权code结合之前分配的Secret（即client secret）和一些其它必要信息，就可以访问http://{your.gitlab.server}/oauth/token并从请求返回的响应(Response)中获得一个AccessToken(当然，还有其他信息，比如Expire时间窗口有多长， RefreshToken，以及授权访问的scope是什么等）， 之后， Application就可以使用这个AccessToken并结合gitlab的API来访问相应的资源（只要授权的这个用户有权限访问）。

获取Access Token流程

如上图，获取Acess Token需要经过的步骤如下：

• 带上clientId和回调地址，请求GitLab的auth认证Api。

• 跳转登录界面进行登录。

• 确认授权。

• 回调函数可以获取到GitLab返回的code。

• 遵循Oauth2认证机制，带上：ClientId、code、secret、RedirectURI。

• 获取到Access Token。

此时去查看gitlab服务器上Application的列表会发现我们注册的Application已经有Clients了，与Gitlab服务器正常交互的OAuth2处理流程就完成啦~！

4. Gitlab权限管理

Gitlab的权限主要包括组权限，项目权限，用户权限，角色等。

访问权限 - Visibility Level

这个是在建立项目时就需要选定的，主要用于决定哪些人可以访问此项目，包含3种：

• Private - 私有项目，只能由项目成员克隆和查看

• Internal - 内部项目，任何登录用户都可以克隆内部项目

• Public - 公共项目，无需任何身份验证即可克隆公共项目

如何更改项目可见性：转到项目仪表板，单击“Edit”选项卡，改变“Visibility Level”

行为权限

在满足行为权限之前，必须具备访问权限，行为权限是指对该项目进行某些操作，比如提交、创建问题、创建新分支、删除分支、创建标签、删除标签等操作.

角色

Gitlab定义了以下几个角色:

• Guest - 访客：能看概况，可以留言，但看不到源代码。

• Reporter - 报告者：能看到源代码，可以理解为测试员、产品经理等，一般负责提交issue等

• Developer - 开发者：负责开发，可读写，但不能推送(push)改动到受保护分支(protected branch)。

• Master - 主人：可读写，甚至推送(push)改动到受保护分支(protected branch)。有一些管理权限，比如管理成员，但不能删除Git库、不能调整Visibility Level等，一般是组长，负责对Master分支进行维护。

• Owner - 拥有者：拥有GitLab组及其所属Git库的所有读写和管理权限，一般是项目经理。

1.项目成员权限

The following table depicts the various user permission levels in a project.

关于保护分支的设置，可以进入 Settings -> Protected branches 进行管理

2.组成员权限

任何用户都可以从组中删除自己，除非他们是该组的最后一个所有者。下表描述了组中的各种用户权限级别。

3.组的可见性

注意：从GitLab 8.6开始，组可见性已更改，并且可以与项目相同的方式进行配置。在以前的版本中，所有用户始终可以看到组的页面。

与项目一样，可以设置组的可见性，以指示匿名用户，所有登录用户或仅显式组成员是否可以查看它。应用程序设置级别的可见性级别限制也适用于组，因此如果将其设置为内部，则匿名用户的探索页面将为空。组页面现在具有可见性级别图标。

Gitlab中项目的可用性 <= 组的可见性。比如组可见性设为Private,则该组下项目的可见性不能设置为Internal或Public。同理，如果该组有项目可见性为Public，是不能将该组的可见性调为Private或Internal的，会报如下错误。

4.用户的可见性

无论您是否登录，位于/ username的用户的公共页面始终可见。

访问用户的公共页面时，您只能看到您有权使用的项目。

如果公共级别受到限制，则用户配置文件仅对登录用户可见。

限制使用公共或内部项目

在“设置”（/ admin / application_settings）下的“管理”区域中，您可以限制用户在创建项目或代码段时使用可见性级别：

这有助于防止人们意外地将他们的存储库暴露给公众。受限制的可见性设置不适用于管理员用户。

如常见的权限问题：线上有些项目组的owner不能将组内的Private项目设置成Public。

解决：将该组的group visibility提高设置为Public，同时将Restricted visibility levels的Public的限制去掉即可设置。admin可以打开 /admin/application_settings 页面配置默认的权限配置。 

参考：

安志合个人博客，版权所有 丨 如未注明，均为原创 丨 转载请注明转自：https://chegva.com/3314.html | ☆★★每天进步一点点,加油!★★☆ |