在Cloudflare，我们依赖于Atlassian构建的一组生产力工具，包括Jira和conference。我们通过Cloudflare访问保护他们。过去，当我们的团队成员想要访问这些应用程序时，他们首先使用我们的身份提供者凭据登录以传递访问权限。然后，他们拿出了第二套证书，特别是亚特拉斯工具，以达到吉拉。这在桌面上很不方便，在手机上也很痛苦设备。而访问可以决定谁应该能够访问一个应用程序，但是产品本身不能决定用户到达目的地后应该能够做什么。应用程序设置这些特定权限，通常需要另一组用户凭据。额外的步骤会减慢速度并使最终用户感到沮丧。访问通过替换繁琐的VPN登录节省时间。但是，我们还想为团队。我们创建了一个特定于Atlassian的插件，可以从Access生成的令牌中获取身份数据并将其映射到用户帐户。我们的团队成员使用我们的身份提供者登录以传递访问权限，然后Access可以在Jira或conference中设置他们的用户权限。没有额外的凭证必须的。我们'很高兴地宣布，我们正在共享Cloudflare每天使用的同一个SSO插件，以便所有Access客户都可以为其托管的Atlassian工具部署它。您可以立即将此插件添加到Atlassian实例中，并删除该额外的凭据要求。就像我们在Cloudflare所做的那样，您可以让您的每一位员工在这一天变得更加方便团队。我们不会停在阿特拉斯西安。我们正在与合作伙伴合作扩展基于JWT的身份验证。如果您正在构建或维护具有授权流的产品，我们希望帮助您添加此项功能。什么是一个JWT，Access如何使用它们？jsonwebtokens（JWTs）允许系统以安全格式传递无状态数据或声明。代币遵循RFC 7519中制定的标准。这个开放的标准允许不同的组以双方都可以创建和理解的格式发送安全、加密的数据。每个JWT由三个base64url字符串组成：头、负载和签名。那个头定义加密中的数据的加密操作智威汤逊有效负载由至少一个（通常是多个）声明的名称-值对组成，用JSON编码。例如，有效负载可以包含用户的身份签名允许接收方确认有效负载是正品。Cloudflare在允许或拒绝访问敏感资源之前，Access依赖于JSON Web令牌来确认身份。当最终用户访问受访问保护的应用程序时，他们首先使用您的身份提供程序登录。我们通过OAUTH或SAML流与该提供者通信以验证用户身份。一旦得到确认，我们将使用RS256算法创建一个JWT，将数据添加到有效负载中，并使用公钥私钥对令牌进行签名配对。那个我们发行的代币商店：用户标识：通常是从您的身份检索到的用户的电子邮件地址提供程序。身份验证域：对令牌进行签名的域。对于访问，我们使用"example.cloudflareaccess.com其中"example"是您可以配置。访问群体：要尝试的应用程序的域到达。过期：令牌不再有效的时间使用。什么时候向访问后的应用程序发出请求，Cloudflare将查找该令牌的存在。如果可用，我们解密它，验证它的真实性，然后读取有效负载。如果有效负载包含有关应该能够访问应用程序的用户的信息，那么我们让他们通过。应用程序可以使用相同的验证步骤来设置特定于用户的权限。您只需要将JWT中的用户与应用程序中的用户相关联，这是一个新模块或插件可能遇到的问题解决。分享我们的Atlassian插件之所以选择Atlassian，是因为几乎我们全球团队的每个成员每天都在使用该产品。每天节省时间来输入第二组凭证会产生真正的效果。此外，去掉额外的步骤可以使移动设备更容易地访问这些核心工具设备Java插件构建在Atlassian插件SDK之上。当对Atlassian部署中的页面发出请求时，Atlassian将重定向到登录页面。安装插件后，登录页面将首先查找Cloudflare Access发出的令牌是否存在。如果存在，插件将确保令牌有效并解析有效载荷。下一个，插件会尝试将负载中的电子邮件地址映射到Atlassian帐户中用户的电子邮件地址。如果找到一个帐户，插件将为该特定用户启动一个用户会话。该插件依赖于您的身份提供程序中与中配置的电子邮件匹配的电子邮件或用户名亚特拉斯。什么时候我们在Cloudflare推出了这个功能，团队成员一天中减少了一次中断。我们都习惯了。我们只是在短暂地禁用它来测试新版本时才收到真正的反馈。那反应很响亮。当我们暂时回到多个登录流的旧世界时，我们开始意识到SSO对于团队是多么的方便。这个教训促使我们迅速地将这一点提供给我们顾客。我们正在将此工具的代码公开，而不是作为打包的插件在市场上发布，这样您就可以自己查看实现了。现在就在部署中安装它；您可以在此处找到说明。根据我们的经验，我们认为您的最终用户会喜欢删除额外的登录步骤。安装基于JWT的Atlassian SSO pluginExpanding的授权Atlassian工具很流行，但是解决Jira和Wiki的这个问题仅仅是个开始。团队中的每个成员可能每天都使用十几个或更多的内部应用程序。组织中的不同组也依赖于不同的工具。我们'正在与项目合作，以扩展对基于JWT的SSO的支持。一个例子是Redash，一个流行的数据查询和可视化工具。上周，Redash在他们的产品中加入了这个功能。与Atlassian插件不同，更改只需要在工具的身份验证流中添加一个新选项。启用后，新特性将检查请求中是否存在JWT。如果有效，Redash将把有效负载中的标识映射到用户配置文件，并使用这些权限启动会话。最终用户在访问屏幕上登录一次，然后到达他们唯一的Redash帐户。如果您有兴趣改善您的产品的SSO流程，请通过这里的表单联系我们，我们可以提供有关实现的输入和最佳实践。请随意使用Atlassian和Redash示例作为模板。我们很高兴与您合作，为您的用户删除多余的步骤。