使用Nexus搭建Maven仓库私服的权限配置心得
最近在学习Maven，学习到使用Nexus搭建私服，通过Nexus的权限机制可以实现较细粒度的权限控制，这对组织内部的团队开发很有帮助。通过实验，我总结了以下一些经验，可以实现一些权限控制的需求，在此分享也作为自己的备忘录。
一、Nexus的权限控制机制
Nexus的权限控制采用的是典型的权限（Privilege）和角色（Role）机制。角色与权限是一对多的关联，用户与角色也是一对多的关联。由于Nexus的主要功能就是管理Maven仓库，所以其权限（Privilege）主要是对仓库进行CRUD（增查改删）操作的权限。作为Nexus的用户，我们能进行管理的就是对仓库的增删改查权限，其他的例如UI权限等是Nexus内建的，用户无法增删改，这个在下一节会讲到。
单个权限（Privilege）所能控制的级别是一个仓库（Repository，包括Group）中存储路径匹配指定正则表达式的一组项目（Artifact）的增删查改（create，delete，read，update）中的某一个操作。正因为其使用了正则表达式来选定要控制的Artifact所以非常灵活。
二、Nexus内建的权限与角色
Nexus的权限分为三类：
1. 应用权限（Application Privilege）：主要是用户的UI操作权限和系统管理权限，例如通过UI登录、进行用户管理等。
2. 仓库目标权限（Repository Target Privilege）：我们作为用户能自定义的唯一一种权限，就是对仓库中的项目的CRUD操作权限
3. 仓库浏览权限（Repository View Privilege）：通过UI界面浏览一个仓库的权限，在创建每个仓库时，Nexus会自动创建一个对应该仓库的View权限，拥有该仓库的view权限才能在系统的Repositories视图中看到该仓库。
以上三类权限中，应用权限和仓库浏览权限两种是由Nexus创建的，我们并不能对这些权限进行增删改操作，只能选择使用或不使用它们。我们能自定义的权限只有仓库目标权限，一个仓库目标权限的作用在上一节最后一句话做了解释。
Nexus在系统中内建了大量的权限和角色，对系统的权限做了初始化的配置，也可以方便我们用户的权限配置过程。
内建的角色由内建的权限组合而成。
内建的一个角色往往包含多个权限，其中应用权限的顾名思义很好理解，主要是管理仓库的权限，例如权限管理的权限，用户管理的权限，仓库的增删改权限等。
仓库浏览角色（角色名称中包含 (View) 的角色），例如 "Repo: All Maven2 Repositories (View)" 这个角色，一般包含了一个或多个仓库的浏览（View）权限。
内建的仓库目标角色，即那些以"Repo:"开头，以“(Read)”, "(Full Control)"结尾的角色，用于控制仓库中的指定项目的访问。
应用权限的配置就不多讲了，我们的重点是如果控制仓库中项目的访问。通常我们需要自定仓库目标、权限和角色来完成较细粒度的控制，但是我们也会结合内置的这些权限角色来方便我们的配置。内置的权限和角色有以下几个可能入门的时候不太容易直观理解的点：
1. 配置了某个仓库的View角色，只能在界面的仓库列表中看到这个仓库的存在，并不能读取其中的Artifact或者进行Artifact的增删改，只有配置了Read角色才可以进行读取，配置了Full Control角色才能进行增删查改全部操作
2. 其实Read角色中已经包含了View权限，也就是说，如果配置了某个仓库目标的Read角色，则不需要再额外配置View角色了
3. 除了内建的权限和角色，其实还有内建的仓库目标（Repository Target），内建的仓库目标权限就是针对这些内建的仓库目标设置的
三、自定义仓库目标（repository target）、权限、角色
只使用内建的权限和角色必然无法满足我们的需求，通常我们希望各个项目组的成员只能看到自己参与的项目并对其进行操作。
刚开始我们一般会想为每个项目创建一个仓库，再为项目组的成员赋予配置了该仓库对应操作权限的角色。采用这种做法，我们会发现仓库列表里会有一大堆仓库，不利于管理。好在Nexus为我们提供了仓库目标（Repository Target）的概念。
一个仓库目标通过一组正则表达式来指定某个仓库（组）中匹配的那些项目。实际上Nexus的权限也是对仓库目标进行控制，而不是直接控制仓库。有了仓库目标，我们就可以为每个项目创建一个仓库目标，并对这个仓库目标进行权限控制，实际上多个项目是存储在同一个仓库，例如Releases或者Snapshots，但是不同的用户能看到并操作的只有我们配置给他的仓库目标所指定的那些Artifact。
我们可以在菜单 【Views/Repositories】->【Repository Targets】中进行仓库目标的管理，我们可以在这里看到系统内建的目标，也可以创建（Add）新的目标。创建目标的时候我们可以指定不止一个Pattern Expression（即正则表达式）来匹配仓库中的Artifact路径。注意，仓库目标并不直接跟仓库关联，也就是说，仓库目标只是指定了一组匹配规则，这组规则可以被用来匹配不同仓库中的Artifact，其通过仓库目标权限（Repository Target Privilege）与具体的仓库或仓库组进行关联。创建仓库目标的时候需要不需要指定仓库，但是需要指定仓库的类型，虽然类型中有一个选项是Any Content，猜测设置类型可能是为了检索的效率和可读性。
关于仓库目标中指定的正则表达式的规则有以下几点要说明：
1. 使用的正则表达式是Java的正则表达式语法，与Perl的正则表达式语法有一定差异
2. 匹配的是路径，不要写成Java包的语法。路径的根目录表示的是指定仓库的根目录，例如，GroupId为com.somecom.somegroup的Artifact就可以用 ^/com/somecom/somegroup/.* 来匹配。
3. 我们还可以使用正则表达式的反模式（ ?! 关键字）来排除一些Artifact，这个非常有用，下面举个例子。例如有个仓库组（名字为 All Release）用于存储所有的发行版本的Artifact，该组包含了Maven 中央仓库、存储第三方Artifact的仓库、存储组织内部Artifact的仓库。我们想让用户自由访问Maven中央仓库和存储第三方Artifact的仓库，但是对存储内部Artifact的仓库进行更细粒度的控制。假设组织内部Artifact的GroupId前缀总是org.somegroup，那么我们可以使用以下这个正则表达式 ^(?!/org/somegroup/.*).* 创建一个仓库目标（名字叫做 All Public Releases），这个仓库目标将组织内部的Artifact排除在规则之外。然后创建一个对All Release 仓库组的 All Public Releases仓库目标具有Read权限的权限，然后为每个用户赋予这个权限（实际上是赋予具有这个权限的角色），这样每个用户都可以自由访问除了组织内部的Artifact之外的其他Artifact了，再结合以上第2点为不同的用户指定用于匹配其可以访问的Artifact的仓库目标。
权限（Privilege）在菜单【Security】→ 【Privileges】进行管理。注意，权限一旦创建便无法修改，只能删除。用户可以创建的只有一种权限，就是仓库目标权限（Repository Target Privilege）。创建权限的时候需要指定权限所控制的仓库，然后指定一个仓库目标，这样我们就把控制的粒度缩小到某个仓库（组）的某个仓库目标了，我们上面说过权限控制的是（增删改查中的）一个操作，但是创建权限的表单中并没有这一项可以选，那是因为Nexus会自动创建对应增删查改的四个权限，这为我们减少了不少工作量。每个操作对应权限的名称为我们指定的Name加上括号以及括号里面的“create”，“read”，“update”，“delete”其中一个。
要跟仓库目标权限区分的是仓库（组）的view权限，view权限是Nexus在我们创建仓库（组）的时候自动创建的，属于内建的权限，这些权限直接跟仓库（组）关联，而不是跟仓库目标关联，这些权限也不能被用户直接删除。
角色（Role）在菜单【Security】→ 【Roles】进行管理。注意，角色可以包含其他角色，也可以直接包含权限。
最后，我们在菜单【Security】→ 【Users】用户管理的【config】选项卡的【Role Management】面板进行授权；我们还可以在【Privilege Trace】和【Role Tree】分别以权限和角色的视角查看当前用户的授权情况。
综上，权限配置的基本流程如下：
【创建仓库目标】-指定仓库(组)-> 【创建权限】→【创建角色】→【为用户授予（一或多个）角色】
[本文主要作笔记使用，表述可能不够清晰，也包含一些个人的理解，仅供参考。]
