[](https://res.cloudinary.com/practicaldev/image/fetch/s--ZNr-ArAg--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://rtfm.co. ua/wp-content/uploads/2016/01/Jenkins.sh-600x600-e1453134979914.png) SAML – Secure Assertion Markup Language 用于我们需要访问某些服务时的联合身份验证(Service Provider ),要求另一个服务(Identity Provider)执行用户的身份验证。

在此处查看文档>>>。

• Service Provider ( SP ): 是一个需要认证的系统,在我们的例子中是 Jenkins

• Identity Provider ( IdP ):是一个存储用户的系统,它将执行准确的身份验证步骤,在我们的例子中,这将是 Okta

他们在认证过程中的通信和步骤可以显示在下一个方案中:

这里:

• SAML Request:或认证请求,由SP创建,用于请求用户的认证

• SAML 响应:将由 IdP 创建并包含有关已通过身份验证的用户的数据,并且可能包括一些附加信息,如用户组等

另外,请记住,SAML 身份验证可以是两种类型:

• A Service Provider Initiated (SP-initiated):当用户尝试登录 Jenkins 实例时,一个服务,在这种情况下为 Jenkins,对 IdP 提供者执行初始化

• An Identity Provider Initiated (IdP-initiated):反之亦然 - 当 Okta 的用户单击按钮登录 Jenkins - IdP 将初始化对 Jenkins (SP) 的请求以验证此用户

在这篇文章中,大部分将谈论_Service Provider Initiated,_但仍然,Identity Provider Initiated 也可以。

此外,请记住,SP 和 IdP 永远不会直接相互交谈——用户的浏览器将充当它们之间的“代理”。

服务提供者角色

IdP 为 SP 生成 SAML 响应,然后 SP 必须检查该响应是否来自有效的 IdP,然后解析该响应以获取必要的数据——用户名、组和其他属性。

为此,SP 需要从 IdP 获取下一个信息:

• 一个 IdP 的公共证书

• ACS Endpoint (Assertion Consumer Service URL) 或只是“SP 登录 URL”——SP 传递给 IdP 以接收 SAML 回复的端点 URL

• IdP 登录 URL – IdP 的端点,SP 将在其中发送其 SAML 请求

用于 Okta 的 Jenkins SAML

SAML 与 Jenkins 集成的主要目标是:

• 商店用户在 Okta

• Okta的用户被分组到组

• Jenkins 将使用基于角色的策略插件,该插件将访问角色分配给各个组

在 Okta Jenkins 中,SAML 可以通过两种方式进行配置:

1. 通过使用原生 Okta 的应用程序 - 配置工作较少,但无法将用户组传递给 Jenkins,将在本文的Okta 社区创建的 Jenkins SAML 应用程序部分进行介绍

2. 或者通过在 Okta 中创建一个自己的基于 SAML 的应用程序,该应用程序将在Okta 和自己的 Jenkins SAML 应用程序部分中审查用户组字段的自定义属性

使用第一种方式,您将无法使用Role-Based Strategy插件,但仍然可以使用Matrix-based security或Matrix Authorization Strategy插件:

Role-Based 插件配置将在以下部分描述,现在在帖子中查看如何以上述两种方式为 Jenkins 配置 Okta 和 SAML。

Okta 本机 Jenkins SAML 应用程序

Okta 配置

转到 Okta > Add 应用程序, 找到 Jenkins SAML 插件:

设置 Jenkins 的 URL:

切换到_登录选项卡:

单击_查看设置说明_——Okta 已经在此处生成了所有数据,供我们的 SP (Jenkins) 使用:

转到 Assignment 选项卡并将 Jenkins SAML 应用程序添加到所需的 Okta 用户:

导航到您的 Jenkins。

Jenkins 中的 SAML 配置

安装SAML 插件:

转到_配置全局安全_,将您的身份验证领域从_Jenkins自己的用户数据库_切换到_SAML_:

返回 Okta 和元数据页面,复制 IdP Metadata 内容:

粘贴到 Jenkins 的 SAML 设置:

返回您的 Okta,将链接复制到 Identity Provider 元数据:

在 Jenkins 中将其设置为 IdP Metadata URL 字段:

显示名称属性 _ 和 _ 组属性 _ 保持原样。

现在检查一下:打开你的 Jenkins URL——你必须被重定向到 Okta:

登录,一切都在这里完成。

Okta 和自己的 Jenkins SAML 应用程序

现在让我们在 Okta 中添加一个新应用程序,它将能够将用户组传递给 Jenkins,例如 - DevOps 组:

Okta 配置

创建一个新应用程序:

设置它的名字,图标:

接下来,在 Single sign on URL и Audience URI (SP Entity ID) set ACS Endpoint – http://dev.ci.example.com/securityRealm/finishLogin:

要将用户组从 Okta 传递给 Jenkins,请在 GROUP ATTRIBUTE STATEMENTS (OPTIONAL) 中添加一个新字段:

• Name:组

• Name format:基本

• Filter- _匹配正则表达式_和值作为 .* 适用于所有 Okta 的组

在下一页设置_我是添加内部应用程序的 Okta 客户_,然后_完成_。

不要忘记_作业_。

现在,以与我们之前相同的方式,单击_查看设置说明_,复制 IdP_ 元数据_ 并更新 Jenkins 中的_配置全局安全_设置。

复制指向 Identity Provider metadata 的链接:

Jenkins 中的 SAML 配置

将此链接设置为 Jenkins 中的 IDP 元数据 URL 文件:

在 Jenkins 中,将 Group Attribute'_s 值从 _http://schemas.xmlsoap.org/claims/Group 更改为“Group”:

其实就是这样。

Jenkins 基于角色的安全性

继续前进(将添加另一篇关于基于角色的插件配置的文章)——Jenkins 中基于角色的安全性和组的示例。

Okta 及其组中的用户:

詹金斯中的角色:

以及分配了 test 的组 DevOps:

完毕。

有用的链接

• 如何在 Jenkins 中将 OKTA 设置为身份提供者?

• SAML 身份验证的工作原理

类似职位

• 09/30/2019Okta:Gmail 和 Slack 的 SSO 身份验证

• 09/02/2017Azure:将附加磁盘附加到 VM 并迁移 Jenkins

• 04/16/2019Jenkins:检查 Github 组织的公共存储库列表的工作