控制台
authing blog banner
查看文章
开发者谈 | Spring Security 集成 OIDC 项目编码 认证
在上一篇文章《开发者谈 | OIDC 在 Authing 控制台配置 认证》中,我们讲述了如何在 Authing 平台配置项目集成中需要的 OIDC 的配置,以及在后期开发过程中如何获取配置。同时,也提前让大家预习和熟悉了一些项目搭建和编码过程中需要的知识点。 接下来这一小节,就让我们一起来完成项目搭建和编码过程吧。 01 项目搭建 使用 Spring Initializr 快速构建项目 打开 IDEA,点击 New Project 创建一个新项目,选择 Spring Initializr 创建一个 Spring Boot 项目,输入项目的 Group 以及 Artifact 信息。 添加 Spring Web, Spring Security 依赖。 另外,集成过程中需要在 pom.xml 中添加一些其他的依赖包,如下:   <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-config</artifactId> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-oauth2-client</artifactId> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-oauth2-jose</artifactId> </dependency> <!--远程调用接口使用--> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.7.11</version> </dependency>   使用 maven 工具构建项目 打开 IDEA,点击 New Project 创建一个新项目,选择 maven 创建一个 maven 项目,然后点击 Next,填写项目名称,最后 Finish 即可。 接下来在 pom.xml 中添加父工程依赖和集成过程中需要的其它依赖包。   <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.5.5</version> <relativePath/> <!-- lookup parent from repository --> </parent> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-test</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-config</artifactId> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-oauth2-client</artifactId> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-oauth2-jose</artifactId> </dependency> <!--远程调用接口使用--> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.7.11</version> </dependency>   说明:其中,hutool-all 工具包的作用是远程调用接口,当收到回调请求时,会使用该工具包远程调用 Authing 接口,即通过 code 换取 token 的流程,后续自动回调接口编码会使用到。 🎉🎉🎉至此,你已经完成了使用 Spring Initializr 和 maven 两种方式构建项目,请选择一种适合自己项目开发的方式即可。 02 项目编码 测试项目 创建好项目后,在 IDEA 中运行项目,使用浏览器访问 http://localhost:8080 会自动跳转到 /login 路由,可以看到页面上出现了一个基础的登录表单,说明项目初始化成功。 配置项目中的配置文件 找到: src/main/resources/application.properties,将其重命名为 application.yml,并添加如下内容。   spring: security: oauth2: client: registration: authing: client-id: {替换为你的App ID如:App Secret5e72d72e3798fb03e1d57b13} client-secret: {替换为你的App Secret如:931f19ce2161e5560c072f586c706ee6} redirect-uri: {替换为登录的回调地址} client-authentication-method: post authorization-grant-type: authorization_code scope: - openid - profile provider: authing: issuer-uri: https://{替换为你的Issuer,如:authing-net-sdk-demo}.authing.cn/oidc user-name-attribute: preferred_username   需要将这里的 {client_id}、{secret_secret}、{issuer-uri} 、{redirect-uri} 替换成 《认证(二)》 中应用配置中的实际信息。 自动回调接口编码 在项目下新建一个 package(package cn.authing.springsecurityoidc.controller),然后新建一个 CallBackController,此接口作用是通过 Authing OIDC 的 code 获取 token 的过程。注意,下面的参数都是 OIDC 的标准,不能乱改,这也是标准协议的规定,参数名所对应的值也就是之前在 Authing 平台应用所配置的那些。   package cn.authing.springsecurityoidc.controller; import cn.hutool.http.HttpUtil; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; import java.util.HashMap; import java.util.Map; @RestController public class CallBackController { @GetMapping("/callback") public String getTokenByCode(String code){ //'https://<你的应用域名>.authing.cn/oidc/token // --data-urlencode 'code=61yhuOVrgyhKlFTU~bnEKA_fnnz' \ // --data-urlencode 'client_id=5e37979f7b757ead14c534af' \ // --data-urlencode 'client_secret=64b517f8de3648091654eb4ee9b479d3' \ // --data-urlencode 'grant_type=authorization_code' \ // --data-urlencode 'redirect_uri=https://baidu.com' Map<String,Object> paramMap = new HashMap<>(); paramMap.put("code",code); paramMap.put("client_id","61319680ea8b30c9ca9ca071"); paramMap.put("client_secret","cc8a53d7e22ce6b845330ced6cc5d9f2"); paramMap.put("grant_type","authorization_code"); paramMap.put("redirect_uri","http://localhost:8080/callback"); String result = HttpUtil.post("https://cjtjls-demo.authing.cn/oidc/token", paramMap); return result; } }   添加配置文件类 在项目下新建一个 package(cn.authing.springsecurityoidc.config),然后新建一个SpringSecurityConfig,Spring Security 默认拦截所有的接口,此配置类是为了放行我们自己需要开放的接口。   package cn.authing.springsecurityoidc.config; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter; import static org.springframework.security.config.Customizer.withDefaults; @EnableWebSecurity(debug = true) public class SpringSecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.formLogin().disable(); http.csrf().and().cors().disable(); http.authorizeRequests() .mvcMatchers("callback","") .permitAll() .anyRequest().authenticated(); // 授权码模式回调 http.oauth2Login(withDefaults()); } }   运行项目 一切准备就绪了,现在启动项目并访问 http://localhost:8080,即可看到 Authing 登录窗口。 Spring Security 默认会保护首页,在访问首页时会进行认证,未认证的访问请求会跳转到 /login。注册并登录后,会跳转回首页,此时可以看到页面上的欢迎语显示了当前登录用户的用户名。 当登录成功后,会自动回调到我们之前自己编码的接口,即前面所概述的 Code 换取 Token 的过程。此时界面会拿到返回值,如下: { "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InhENWlTYVJiU0dZQzFmdWFTRVdQXy1hejBORW5qSmtoZG00bTJ3X3ZwMHcifQ.eyJqdGkiOiJnbHdLbmMzbzlXYlVLUE5pWUF1V00iLCJzdWIiOiI2MTRmZDlhZTQyYjE5MmZjMzI4MjNiMTAiLCJpYXQiOjE2MzU5MjQwNjgsImV4cCI6MTYzNzEzMzY2OCwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSIsImlzcyI6Imh0dHBzOi8vY2p0amxzLWRlbW8uYXV0aGluZy5jbi9vaWRjIiwiYXVkIjoiNjEzMTk2ODBlYThiMzBjOWNhOWNhMDcxIn0.KG6_SCaXfm082WAuPZu2-gR2cuA1Heg50EeVF1ldAO_fvb72pkmgs7EiWXjLJwYUj3CNejIS1GwcDy9gVWw8jfO-aRxUyRMplDY-axzgu5frCxYrg_K7LhlU1xvQJIMKTx7HY7rldbbAX0JzqJx-xHCJItUiggvHjvF9-B1twmMP7Ua-UQxQdgkFd1SmbN9LwqxCo8AzsbX6jcBNJ3Ughv0_jUxYp6QPAeIEkXmOYlwdJR-4Rdn9XxPya5yF4wxgwZ_oybjViESr7BDwEXEPVWTF6czGzctmfhCD7EEE4sLWaP6TSmXAHyCYp6TVNpVNAXg2sKQSfbwPdR8PxOhFmg", "expires_in": 1209600, "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InhENWlTYVJiU0dZQzFmdWFTRVdQXy1hejBORW5qSmtoZG00bTJ3X3ZwMHcifQ.eyJzdWIiOiI2MTRmZDlhZTQyYjE5MmZjMzI4MjNiMTAiLCJiaXJ0aGRhdGUiOm51bGwsImZhbWlseV9uYW1lIjpudWxsLCJnZW5kZXIiOiJVIiwiZ2l2ZW5fbmFtZSI6bnVsbCwibG9jYWxlIjpudWxsLCJtaWRkbGVfbmFtZSI6bnVsbCwibmFtZSI6bnVsbCwibmlja25hbWUiOm51bGwsInBpY3R1cmUiOiJodHRwczovL2ZpbGVzLmF1dGhpbmcuY28vYXV0aGluZy1jb25zb2xlL2RlZmF1bHQtdXNlci1hdmF0YXIucG5nIiwicHJlZmVycmVkX3VzZXJuYW1lIjpudWxsLCJwcm9maWxlIjpudWxsLCJ1cGRhdGVkX2F0IjoiMjAyMS0xMS0wMVQxMToyOToyMi4zMDlaIiwid2Vic2l0ZSI6bnVsbCwiem9uZWluZm8iOm51bGwsIm5vbmNlIjoiekx6WndwR05faEpDdDNRTVlvMk12TmplT2o4aTM0U0tpR3ZlMVc0d2R1ayIsImF0X2hhc2giOiJFcGZUR1M2dFNpVnhiMkdPbkxUazNRIiwiYXVkIjoiNjEzMTk2ODBlYThiMzBjOWNhOWNhMDcxIiwiZXhwIjoxNjM3MTMzNjY4LCJpYXQiOjE2MzU5MjQwNjgsImlzcyI6Imh0dHBzOi8vY2p0amxzLWRlbW8uYXV0aGluZy5jbi9vaWRjIn0.iRoYa0JLoBJPXAPD8LjHnuvjQsQ5o5g9qUjPAj1aTMbZqa9GI3gUfxW-smudKJCJmGfYDYJaRP8_szdS03cXCt8u4rGc7y6e6y2Fqq1pssz3VlpRm9t_7LxJrUeBFu1ef87KWO0WZg5Nd6mdoIEAJXwRSW8BbTE_ARg8DZiOcrk3YJ2PxFqb6Tepf3Vw6XyxkHjOfDgJNDnnwHsiMGdXzTMYJwMNKkEjP8xQJl9oh9nOSDF_33-4Btn3nuQQPZ6ndTEcPbaYOo6PN_0IaisjuE3rzyCdGNXxgPrbXg2qywMKZrtj-AKROZ43IA2ito_MtJ6292N6IlFv9SR0Gr4hpw", "scope": "openid profile", "token_type": "Bearer" } 项目地址: https://github.com/Authing/example-spring-boot-oidc   恭喜 🎉,到此你已经学会了 Spring Security 5 集成 Authing OIDC 认证授权的整个流程。后续还有更多的干货,持续关注 Authing 技术博客吧!   文章回顾: 开发者谈 | OIDC 在 Authing 控制台配置 认证 开发者谈 | 一文带你了解 Spring Security 集成 Authing OIDC 认证    关于 Authing Authing 是国内首款以开发者为中心的全场景身份云产品,集成了 OIDC 等所有主流身份认证协议,为企业和开发者提供完善安全的用户认证和访问管理服务。作为云原生架构下的身份云产品,Authing 在产品创建初期,目标就是服务亿级的企业和个人开发者客户,轻量级、易部署、低消耗、技术栈成熟,运维易的云原生技术产品架构,成为了 Authing 的首选。   点击此处了解更多行业身份管理 「解决方案」以及「最佳实践案例」
开发者谈 | OIDC 在 Authing 控制台配置 认证
01 集成介绍 在《一文带你了解 Spring Security 集成 Authing OIDC 认证 》中我们讲解了很多的基础知识和概念。我们讲解了什么是 Spring Security ,以及使用 Spring Security 安全管理框架给我们开发工作带来的便利和整合难度的降低,极大地减少了大量重复代码的开发。 OIDC 协议,是一个基于 OAuth 协议的身份认证标准协议,且完全兼容 OAuth。Access Token 来解决授权第三方客户端访问受保护资源的问题,OIDC 在这个基础上提供了ID Token 来解决第三方客户端标识用户身份认证的问题。 接下来,本文将详细讲解集成过程需要在 Authing 平台配置的整个流程。 02 配置 Authing 获取 Authing 平台信息 首先要在 Authing 注册一个账号,然后进入控制台,按照引导步骤新建一个用户池。然后点击左侧的「应用」 菜单项,在右侧会看到一个默认创建好的应用。     点击「配置」,看到 App ID、App Secret 和 Issuer url,请妥善保存,之后会用到这些信息。   然后需要在回调地址处添加: http://localhost:8080/login/oauth2/code/authing   之后的选项与下图中保持一致,注意这个地址会在第三节的编码过程中用到,请留意。     最后还需要在授权配置中,勾选如下的配置,以确保该应用支持的授权模式和 token 的安全配置。   项目开发准备工作 开发环境 开发工具:IDEA 项目管理工具:Maven JDK版本:1.8 版本控制工具:Git   本篇主要介绍了 OIDC 在认证过程中所需要的配置,以及在 Authing 平台如何配置和获取这一系列的配置的过程。 继续关注 Authing 技术博客,接下来将解读使用代码实现 Spring Security 集成 Authing OIDC 认证的全过程。 后文主要以以上环境来进行项目的搭建和编码工作,个别版本以及集成开发工具之间的差异对开发集成工作没有太大的影响,请根据个人的开发习惯来配置一下自己的本地环境哦,方便接下来的学习。 搭建项目方式 1.使用 maven 工具构建项目 2.使用 Spring Initializr 快速构建项目 后文搭建项目过程中,主要采用以上两种方式,后续技术博客将介绍如何使用这两种方式构建项目。 关于 Authing Authing 是国内首款以开发者为中心的全场景身份云产品,集成了 OIDC 等所有主流身份认证协议,为企业和开发者提供完善安全的用户认证和访问管理服务。作为云原生架构下的身份云产品,Authing 在产品创建初期,目标就是服务亿级的企业和个人开发者客户,轻量级、易部署、低消耗、技术栈成熟,运维易的云原生技术产品架构,成为了 Authing 的首选。 点击此处了解更多行业身份管理 「解决方案」以及「最佳实践案例」
开发者谈 | 一文带你了解 Spring Security 集成 Authing OIDC 认证
01 集成介绍 Authing OIDC 允许客户端根据授权服务器执行的身份验证来验证最终用户的身份,并以可互操作和类似 REST 的方式获取有关最终用户的基本配置文件信息。允许所有类型的客户端(包括基于 Web 的客户端、移动客户端和 JavaScript 客户端)请求和接收有关经过身份验证的会话和最终用户的信息。 规范套件是可扩展的,允许参与者在对他们有意义的时候使用可选功能,例如身份数据加密、OpenID 提供者的发现和会话管理。允许应用程序和站点开发人员对用户进行身份验证,而无需承担存储和管理密码的责任,因为互联网上充斥着大量试图为了自己的利益而破坏用户账户的人。它简单、可靠、安全,并且可以让他们摆脱存储和管理他人密码的困难和危险工作。还有一个额外的好处是,它使用户的注册过程更轻松,从而减少了用户跳出率。利用 Authing OIDC 服务作为用户认证中心的统一入口,使所有需要登录的地方都交给 OIDC 服务来做。简单来说就是把需要进行用户认证的部分都剥离出来交给 OIDC 认证中心来完成。 02 知识储备学习 Spring Security 介绍 Spring Security 是 Spring 家族中的一个安全管理框架,实际上,在 Spring Boot 出现之前,Spring Security 就已经发展了很多年了。Spring Security 为基于 J2EE 的企业软件应用程序提供了全面的安全解决方案。程序安全的两个主要领域是 “身份验证”和“授权”(或 “访问控制”)。这是 Spring Security 所针对的两个主要领域。“身份验证”是建立主体的过程,即他们声称是谁(“主体”通常是指可以在您的应用程序中执行操作的用户、设备或其他一些系统)。“授权”指决定是否允许委托人在您的应用程序中执行操作的过程。为了达到授权所需要的,身份验证过程已经建立了委托人的身份,这些概念是常见的,并且完全不是特定于 Spring Security 的。 项目获取代码地址 要获取项目的源代码,请使用以下 git 命令: git clone git://git.springsource.org/spring-security/spring-security.git   Spring Security 对 OpenID 支持 命名空间支持 OpenID 登录,可以代替普通的基于表单的登录,或者除了普通的基于表单的登录之外,还有一个简单的更改: <http> <intercept-url pattern = "/**" access = "ROLE_USER" /> <openid-login /> </http>   然后,您应该向 OpenID 提供商注册自己,并将用户信息添加到您的内存中 <user-service>: <user name = "http://xxx./openid" authority = "ROLE_USER" />   Spring Security 对 OpenID 属性交换的支持 例如,以下配置将尝试从 OpenID 提供程序检索电子邮件和全名,以供应用程序使用: <openid-login> <attribute-exchange> <openid-attribute name = "email" type = "http://xxx./email" required = "true"> <openid-attribute name = "name" type = "http://xxx./namePerson" /> </attribute-xchange> </openid-login>   OIDC 介绍 OIDC 是 OpenID Connect 的简称,OIDC = (Identity, Authentication) + OAuth 2.0。它在 OAuth 上构建了一个身份层,是一个基于 OAuth 协议的身份认证标准协议。我们都知道 OAuth 是一个授权协议,它无法提供完善的身份认证功能,OIDC 使用 OAuth 的授权服务器来为第三方客户端提供用户的身份认证,并把对应的身份认证信息传递给客户端,且可以适用于各种类型的客户端(比如服务端应用,移动 APP,JS 应用),且完全兼容 OAuth,也就是说你搭建了一个 OIDC 的服务后,也可以当作一个 OAuth 的服务来用。 OAuth 2.0 提供了 Access Token 来解决授权第三方客户端访问受保护资源的问题,OIDC 在这个基础上提供了 ID Token 来解决第三方客户端标识用户身份认证的问题。OIDC 的核心在于在 OAuth 2.0 的授权流程中,一并提供用户的身份认证信息(ID Token)给到第三方客户端,ID Token 使用 JWT 格式来包装,得益于 JWT 的自包含性,紧凑性以及防篡改机制,使得 ID Token 可以安全的传递给第三方客户端程序并且容易被验证。此外还提供了 UserInfo 的接口,用户获取用户的更完整的信息。 OIDC 主要术语 主要的术语以及概念介绍 EU:一个人类用户 RP:用来代指 OAuth 2.0 中的受信任的客户端,身份认证和授权信息的消费方 OP:有能力提供 EU 认证的服务(比如 OAuth 2.0 中的授权服务),用来为 RP 提供 EU 的身份认证信息 ID Token:JWT 格式的数据,包含 EU 身份认证的信息 UserInfo Endpoint:用户信息接口(受 OAuth 2.0 保护),当 RP 使用 Access Token 访问时,返回授权用户的信息,此接口必须使用 HTTPS OIDC 工作流程 OpenID Connect 协议抽象地遵循以下步骤: RP(客户端)向 OpenID 提供者(OP)发送请求 OP 对最终用户进行身份验证并获得授权 OP 使用 ID 令牌和通常的访问令牌进行响应 RP 可以向 UserInfo Endpoint 发送带有访问令牌的请求 UserInfo 端点返回有关最终用户的声明 这些步骤如下图所示: 下面是一个成功的令牌响应的非规范示例: HTTP/1.1 200 正常 内容类型:应用程序/json 缓存控制:无存储 编译指示:无缓存 { "access_token": "SlAV32hkKG", "token_type": "承载", "refresh_token": "8xLOxBtZp8", "expires_in": 3600, "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIwKICJzdWIiOiAiMjQ4Mjg5 NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ fV3pBMk1qiiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEZMTEYODA5Nz AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q -cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJboEoRoS K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4 XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg" }   关于 Authing Authing 是国内首款以开发者为中心的全场景身份云产品,集成了 OIDC 等所有主流身份认证协议,为企业和开发者提供完善安全的用户认证和访问管理服务。作为云原生架构下的身份云产品,Authing 在产品创建初期,目标就是服务亿级的企业和个人开发者客户,轻量级、易部署、低消耗、技术栈成熟,运维易的云原生技术产品架构,成为了 Authing 的首选。   点击此处了解更多行业身份管理 「解决方案」以及「最佳实践案例」   更多技术干货,在 Authing 技术博客搜索“身份云动态”,将身份云知识一网打尽。
开发者谈 | OAuth 2.0 和 OIDC 协议的关系?(内含必看案例)
撰稿人:Authing 开发者 寻寻觅觅的 Gopher 还记得那个吃披萨的例子吗? 《5000 字干货 | IDaaS 身份即服务背后的基石》一文中阐述了 SaaS,PaaS,IaaS 三者的区别。 IDaaS 实际上就是一个基于 SaaS 模式的 IAM 解决方案,也就是云上的身份和访问管理服务,完全由受信任的第三方云服务厂商托管和管理。它允许企业使用单点登录、身份验证和访问控制来提供对任意接入的已实现标准协议应用的安全访问。 而 IDaaS 背后,有两个支撑着其认证和授权能力的基石: OAuth2.0 和 OIDC 协议。 01 OAuth 2.0 OAuth 即 Open Authorization ,开放授权。 OAuth 2.0 是一个授权标准协议,可以使第三方应用获得对资源服务的有限访问。 根据 OAuth 2.0 协议规范,定义了四个角色: 资源所有者(Resource Owner):能够授予对受保护资源访问权限的实体。例如应用的用户是资源的所有者,可以授权其他人访问他的资源。当资源所有者是一个人时,它被称为最终用户。 资源服务器(Resource Server):存储受保护资源的服务器,能够接受并使用访问令牌来响应受保护的资源请求。就是资源服务器接受 Access Token,然后验证它拥有的权限,最后返回对应的资源。这个资源服务器一般是应用本身。 授权服务器(Authorisation Server):服务器向客户端(即应用)颁发访问令牌来验证资源所有者并获得授权。即负责颁发 Access Token 的服务器,例如 IDaaS 就是一个授权服务器。 客户端(Client):需要获取访问令牌以访问资源服务器的应用。经过授权后,授权服务器为客户端颁发 Access Token。后续客户端可以携带这个 Access Token 到资源服务器那访问用户的资源。 在 OAuth 2.0 中一个应用可能既是 Resource Server,也是 Client,具体是什么角色,取决于应用工作的场景。 概念可能有点难嚼,还请慢咽。 这四个角色一直在围绕着一个叫 Access Token 的东西在转圈圈。 Access Token 也就是访问令牌,它用于允许应用访问一个资源 API。用户认证授权成功后,授权服务器会签发 Access Token 给应用。应用后续需要携带 Access Token 访问资源 API,资源服务 API 会检验 Access Token 是否有权限访问,从而决定是否返回对应资源。 而 Access Token 本质上只是一串随机字符串,并不能从中获取到任何信息,检验 Access Token 的步骤还需要资源服务器将它转发到授权服务器上进行解析验证。 了解完 Access Token 之后,我们来关注一下客户端调用方是如何获取到它的,也就是授权模式的选择。 授权码模式(Authorization Code):适用于具有完整前后端的传统 Web 应用以及移动或桌面端应用。 隐式模式(Implicit):适用于没有后端的基于浏览器(JavaScript)的纯前端应用。 密码模式(Resource Owner Password Credentials):适用于资源服务器和客户端之间高度信任的情况下,例如自家应用使用自家的资源。 客户端凭证模式(Client Credentials):适用于没有前端参与,纯后端交互的情况,期间没有用户的参与,客户端自己就是资源所有者。 ...... 我们重点关注授权码模式和客户端凭证模式,这两个是最常用的。 先看授权码模式,也叫 code 换 token 模式,我们以 Stack Overflow 使用 GitHub 登录为例(在这个过程中 Stack Overflow 是客户端,GitHub 是资源服务器,提供邮箱头像等资源信息,同时 GitHub 也是授权服务器,会颁发 token 给客户端)。 第一步,点击登录后需要跳转到授权服务器地址,即 GitHub 的地址,并且必须在 URL 上携带 client_id 和 redirect_uri 以及 scope 等信息。 Apache https://github.com/login/oauth/authorize? client_id=01b478c0264a1fbd7183& redirect_uri=https://stackauth.com/auth/oauth2/github& response_type=code& scope=user:email& state=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   client_id 可以让 GitHub 知道是哪个客户端在请求资源,这里的 01b478c0264a1fbd7183 就是 Stack Overflow 在 GitHub 中注册的客户端 ID; redirect_uri 是授权成功或失败后的回调地址; response_type=code 表示使用授权码模式授权; scope 表示应用正在请求哪些权限; state 是一个随机字符串用来防止 CSRF 攻击。   继续第二步,当我们点击授权按钮后,这时授权服务器即 GitHub 会将浏览器重定向到第一步的 redirect_uri 参数指定的网址。并且跳转时,会携带一个授权码 code 参数(由 GitHub 后台生成的)以及 state 参数。   Apache https://stackauth.com/auth/oauth2/github? code=1efc47a278d10a04f88e& state=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   第三步,由于浏览器触发请求了 redirect_uri ,所以 Stack Overflow 网站后台可以接收到请求并拿到授权码 code 和 state ,这时就可以将 state 和第一步生成的 state 对比以防止 CSRF 和其他相关攻击。 第四步,Stack Overflow 可以拿着 client_id 、 client_secret 、 code 跟 GitHub 交换令牌,GitHub 收到请求以后就会校验 code 并颁发访问令牌(code 是有过期时间的,并且是一次性的)。 Ruby // Request POST code=1efc47a278d10a04f88e& client_id=01b478c0264a1fbd7183& client_secret=xxxxxx // Response Accept: application/json { "access_token":"gho_16C7e42F292c6912E7710c838347Ae178B4a", "scope":"user:email", "token_type":"bearer" }   最后第五步,Stack Overflow 使用 GitHub 颁发的访问令牌跟 GitHub 获取到所需的资源(用户邮箱地址),然后就走自己的业务流程了,一般就是重定向回首页。 另一个客户端凭证模式就相对简单了,毕竟只是纯后端交互。 例如,一个 B 应用拥有很多 photo 资源,即 B 为资源服务器(假设同时也是授权服务器),A 客户端想要获取 B 的 photo 资源。 第一步,A 应用直接使用 client_id 和 client_secret 向 B 申请资源。 Groovy https://b.com/oauth/token? grant_type=client_credentials& scope=photo& client_id=xxx& client_secret=xxx   response_type=client_credentials 表示使用客户端凭证模式授权。 第二步,B 作为授权服务器验证 A 客户端的 client_id 和 client_secret 是否合法,然后颁发访问令牌。 第三步,A 客户端携带访问令牌向 B 资源服务器获取 photo 资源。 这期间并没有用户的参与,A 客户端自己就相当于一个“用户”。   02 OpenID Connect 讲完 OAuth 2.0 授权,来到 OIDC 认证协议。 如标题,OIDC 全称是 OpenID Connect,是一个基于 OAuth 2.0 的认证 + 授权(OAuth 2.0 提供的能力)协议。 OIDC 可以理解为 OAuth 2.0 的超集,在 OAuth 2.0 之上实现了更多的标准,例如定义了一系列的 EndPoint 。还有一些规范诸如 Session Management,Front-Channel Logout,Back-Channel Logout 等。 OIDC 之所以有认证的功能,是因为在 OAuth 2.0 颁发 Access Token 的基础上,多颁发了一个 ID Token(用户的身份凭证),和 Access Token 是一个随机字符串不同的是,ID Token 是一个 JWT Token 。 ID Token 自身包含了一些用户的基本信息,而且由于 JWT 的防篡改性,让客户端不需要再向授权服务器进行身份验证,就能直接用 ID Token 来进行身份验证。即使 ID Token 包含的用户信息不够,也可以调用 OIDC 定义的 UserInfo EndPoint(用户信息接口)来获取更多的用户信息。 OIDC 协议定义的名词和 OAuth 2.0 协议定义的稍微有些出入: OpenID Provider ,简称 OP :相当于 OAuth 2.0 中的授权服务器,除了负责颁发 Access Token ,还会颁发 ID Token 。例如 IDaaS 就是一个 OP 。 Relying Party ,简称 RP :代指 OAuth 2.0 中的客户端。 End User ,简称 EU :即用户。 最后, OIDC 的授权流程与 OAuth 2.0 是一样的,主要区别在于 OIDC 授权流程中会额外返回 ID Token。 03 云原生下的 OIDC Provider 服务 IDaaS 的认证和授权使用了 OIDC/OAuth 2.0。说白了,要搭建 IDaaS 得先搭建一个授权服务器 OpenID Provider (更多时候称之为 OIDC Provider )。 但即便完全了解 OIDC 协议,自行实现一套完整的 OIDC Provider 依旧十分繁琐,好在云原生环境下孕育出了很多优秀的项目。本文会简单介绍一下 Go 语言生态下的 dexidp/dex 和 ory/hydra ,感兴趣的可以自行到其官网详细了解。 dexidp/dex Dex 作为 CNCF 的一个 sandbox 项目,是一个具有可插拔连接器的 OIDC 和 OAuth 2.0 提供商。 它通过”连接器“的身份来充当其他身份提供商的门户,可以将身份验证推送到 LDAP 服务器、SAML 提供商或 GitHub、Google 和 Active Directory 等其他一些成熟的身份提供商中进行验证。客户端只需写一次认证逻辑就可以与 Dex 对接,然后 Dex 来处理特定后端的协议。 ory/hydra ORY Hydra 是一个 OAuth 2.0 和 OpenID Connect 提供者。 特别一说的是 Hydra 所实现的 OAuth 2.0 协议并不依赖 Go 标准库提供的,而是自实现的 fosite。 另外 ORY Hydra 还提供了一个 5 分钟的快速搭建教程。   关于 Authing Authing 是国内首款以开发者为中心的全场景身份云产品,集成了 OIDC 等所有主流身份认证协议,为企业和开发者提供完善安全的用户认证和访问管理服务。作为云原生架构下的身份云产品,Authing 在产品创建初期,目标就是服务亿级的企业和个人开发者客户,轻量级、易部署、低消耗、技术栈成熟,运维易的云原生技术产品架构,成为了 Authing 的首选。 点击此处了解更多行业身份管理 「解决方案」以及「最佳实践案例」
干货 | 使用 OIDC 协议进行身份验证的工作原理
  01 身份验证的本质 OIDC 全称是 OpenID Connect,是一个基于 OAuth 2.0 的认证 + 授权(OAuth 2.0 提供的能力)协议。 《身份云动态 | 认证和授权,都离不开的 OIDC 协议》一文中提到,OIDC 诞生的场景是 —— 被授权的主体不再是用户,而是「想要访问用户资源的第三者」,而颁发权限的主体也不再是管理员,而是用户自己。 OIDC 诞生的场景则是 ——  被授权的主体不再是用户,而是「想要访问用户资源的第三者」,而颁发权限的主体也不再是管理员,而是用户自己。 因此,想要了解 OIDC 协议,首先要厘清「认证」和「授权」的概念。 认证 认证是决定一个主体(之后统称「用户」)究竟是谁的过程,换句话来说,是将「当前意图访问资源的用户」和「提前存储好的身份信息」对应起来的过程。显然,这个操作需要由身份信息的持有者来完成,我们称其为「IdP(Identity Provider)」,它存储的身份信息列表称为「用户目录」或「用户池」。 所谓的「身份信息」可以是任意格式,包含但不限于以下两种内容:用户的唯一标识符(可以是唯一的用户名、随机字符串、UUID 等),以及只有该用户才能提供,用来确认该用户身份的私密信息(密码、指纹等)。前者可以是公开的,但后者必须是私密的,只有 IdP 和用户自身才能持有。 为了完成认证,用户必须首先「宣称」自己是谁,并且这个宣称需要以某种形式和用户目录中的唯一一条记录产生关联。显然,最简单的办法就是直接向 IdP 宣布自己的唯一标识符。之后,用户需要通过某种保密的途径悄悄告诉 IdP 自己的私密信息,IdP 确认无误后,就可以将当前正在进行请求的用户和用户目录中的身份信息对应起来,如此一来,用户在 IdP 上的认证过程就完成了。 授权 确认了用户的身份之后,下一步就是确认用户到底有没有权限访问想要访问的资源了。拥有身份信息后,这一步就变得很简单了——只需根据对应资源的权限设置,检查用户的对应操作是否被允许即可。     02 身份和资源的分离 在最简单的身份模型中,身份持有者(IdP)和资源持有者运行在同一个上下文中。这意味着一旦 IdP 完成了某个用户的认证,资源持有者立刻就能知道(例如通过数据库查询)用户的身份信息。 之后用户访问资源时,资源持有者就能利用这一信息来决定是否允许用户的操作(相当于自己执行授权),或者把这一决定交给 IdP 来做(相当于 IdP 执行授权)。 这种模型的缺点显而易见——每个应用都要维护一套自己的用户目录,不同应用之间无法共享身份信息。为了解决这个问题,一个自然的想法就是将 IdP 独立出来,让所有资源持有者都从 IdP 处获取用户的身份。 这种做法存在一个前提条件:当一个用户在 IdP 上完成了认证之后,资源持有者必须得知这一点,并能从 IdP 处获取用户对应的身份信息,而且这一渠道必须是可信的,身份信息不能被恶意篡改。在实际应用中,资源持有者一般会在用户访问资源时,向 IdP 获取用户的认证状态和身份信息。如果成功,之后的授权步骤就和上面一致了。 独立的 IdP 有一个天然的好处——只要用户在 IdP 上进行过了认证,其下关联的所有资源持有者都能获取到用户的身份信息,正所谓「一次认证,到处访问」。所谓的「单点登录(SSO)」本质上就是如此。 由于 Web 应用天生的无状态性,资源持有者并不能确定访问资源的用户和在 IdP 上认证过的用户是同一个,因此用户每次访问资源时都需要提供身份标识符和密码,由资源持有者向 IdP 进行确认。 为了解决这一问题,IdP 在完成认证时可以向用户颁发一个临时的「令牌(Token)」,这个 Token 存储着用户目录中的用户身份,只有用户本人才能持有,并且经过 IdP 的数字签名。 用户访问资源时,通过 Cookie 等手段自动向持有者提供 Token,持有者可以在本地利用签名验证 Token 的真实性和有效性,并且从 Token 中获取到用户的身份信息,无需再经过 IdP 了。为了防止 Token 从用户处泄露,它只在短时间内有效,失效后必须由 IdP 重新颁发。 最著名的 Token 技术是「JWT(Json Web Token)」,它也是 OIDC 协议的一部分。除此之外,SAML 协议中的「断言(Assertion)」也可以起到和 Token 相同的作用。 当然,用户的登录态也可以由资源提供者来维护,资源提供者在向 IdP 确认用户身份后自己向用户颁发一个类似的 Token,存放在用户 Cookie 中。此时的 Token 可以实际存储身份信息并进行签名,也可以作为一个索引的 Key,指向存放在资源提供者后端的,从 IdP 处获得的身份信息(也就是所谓的 Session)。 值得注意的是,在分离模型中,如果授权步骤由 IdP 执行,用户在 IdP 上进行授权时还需要提供自己想要访问的资源种类和执行的操作,IdP 签发 Token 时也需要将这些信息写在 Token 中,以便资源持有者核验。「资源」和「操作」的二元组被称为「Scope」,OIDC 登录时传人的其中一个参数就是它。 03 由用户决定的授权(OIDC 协议) 之前的讨论中存在一个隐含的假设——资源的所有权并不在用户手中,而是在外部的管理者手中,因此用户访问资源时才需要首先获取权限。然而在当今的互联网中,很大一部分信息都是用户产生的,用户理应拥有自己资源的完全控制权限。 在这种场景之下,「授权」的概念依旧存在,只不过被授权的主体不再是用户,而是「想要访问用户资源的第三者」,而颁发权限的主体也不再是管理员,而是用户自己。此时,这个「第三者」被称为「SP(Service Provider)」,也称为「Client」,而用户资源的存放处依然称为「资源提供者」。由于以下的讨论仅涉及授权而不涉及认证,为了方便起见,不妨假设「资源提供者」和「IdP」运行在同一上下文中,统称「IdP」,同时负责认证用户身份和提供资源。 举个例子,用户想在自己的微信中看到自己 Github 账号的状态,在这种情况下,微信是 SP ,Github 是 IdP,微信需要访问用户存储在 Github 下的资源(账号状态)。 由于微信和 Github 是两个互相不信任的应用,也因为用户有权控制其在 Github 下的资源,Github 不能在未取得用户许可的情况下,向微信提供任何用户资源。因此,微信首先需要指引用户前往 Github 进行认证和授权,这通常是用重定向用户浏览器来实现。 Github 会首先进行认证操作,确认用户的身份(显然只有用户本人才有权向第三者提供他的资源的访问权限)。身份验证通过后,Github 还会根据管理员配置的权限列表,确认用户本身拥有微信所请求资源的对应访问权限(因为请求的资源也可能不完全属于用户)。这一点也确认无误后,Github 就会弹出授权确认页面,向用户确认「是否授予微信对应权限」。用户确认完成后,Github 就会签发一个 Token,由用户转交给微信,微信方只需向 Github 提供这个 Token 就可以访问之前请求的资源了。 作为标准身份协议之一的 OIDC 正是为此种场景而生。OIDC 的认证和授权分为四种模式:授权码模式(Code)、隐式模式(Implicit)、密码模式(Password)、客户端证书模式(Client Credential)。 授权码模式 授权码模式是最为规范的模式。它的主要步骤如下: 1.SP 将客户端重定向到 IdP 的 OIDC 授权地址,附上自己请求的权限(Scope)和一个回调地址 2.IdP 在自己的页面上完成认证,并由用户确认权限 3.IdP 通过客户端向 SP 的回调地址发送一个授权码(Code) 4.SP 的后端向 IdP 的另一个接口发出含有 Code 的请求,得到 IdP 颁发的 Token 授权码模式的优点在于 Token 不由用户,而是由 SP 持有,降低了意外泄露带来的风险。值得注意的是,用户在 IdP 上进行认证和授权的过程是 IdP 自行规定的,和 OIDC 协议无关。在 OIDC 协议中,IdP 颁发的 Token 是 JWT。 隐式模式 隐式模式可以看作省略了 Code 的授权码模式。它的主要步骤如下: 1.SP 将客户端重定向到 IdP 的 OIDC 授权地址,附上自己请求的权限(Scope)和一个回调地址 2.IdP 在自己的页面上完成认证,并由用户确认权限 3.IdP 通过客户端向 SP 的回调地址直接发送 Token 可以看到,此时的 Token 经过了用户的客户端,容易被中间人窃取。由于访问用户资源的是 SP 而不是用户本人,只让 SP 持有 Token 永远是更为正确的选择。 密码模式 密码模式在隐式模式的基础上进一步省略了 IdP 上的授权过程。它的主要步骤如下: 1.SP 在自己的页面上请求用户输入在 IdP 上的用户名和密码 2.SP 向 IdP 的 OIDC 授权地址发起请求,附上用户输入的帐密 3.IdP 确认帐密的正确性,然后在响应中直接发送 Token 密码模式只应用在 IdP 和 SP 互相信任,或者 SP 由用户本人控制(例如移动端或桌面应用)的情况下,因为用户的帐密经过了 SP,只要 SP 愿意,完全可以通过用户的帐密在 IdP 上无限制访问用户的全部资源。也正因如此,密码模式中让用户确认权限是没有意义的,SP 获取的一定是用户资源的完全访问权限。 客户端证书模式 客户端证书模式和用户无关,只用于在 IdP 上授权特定 SP 访问特定资源。它的主要步骤如下: 1.SP 提前在 IdP 上注册一个证书(一般是账号 + 密码) 2.SP 向 IdP 的 OIDC 授权地址发起请求,附上自己的证书 3.IdP 确认证书的正确性,然后在响应中直接发送 Token 显然,客户端证书模式也只应用于 IdP 和 SP 互相信任,或是 SP 只访问用户无关资源的情况下。由于没有征得用户的同意,如非必要,IdP 不应授权 SP 访问用户的私密信息。   关于 Authing Authing 是国内首款以开发者为中心的全场景身份云产品,集成了 OIDC 等所有主流身份认证协议,为企业和开发者提供完善安全的用户认证和访问管理服务。作为云原生架构下的身份云产品,Authing 在产品创建初期,目标就是服务亿级的企业和个人开发者客户,轻量级、易部署、低消耗、技术栈成熟,运维易的云原生技术产品架构,成为了 Authing 的首选。   点击此处了解更多行业身份管理 「解决方案」以及「最佳实践案例」   更多技术干货,在 Authing 技术博客搜索“身份云动态”,将身份云知识一网打尽。
身份云动态 | 认证和授权,都离不开的 OIDC 协议
  身份验证存在的意义是什么?   是为了对那些有安全需求的特定资源进行访问控制,只让某些特定的主体(个人、公司、甚至是一段代码)对其执行某些特定的操作(查看、修改等)。因此,对于想要访问资源的主体,需要按照顺序达成如下两个条件:   1.认证(Authentication):知道 ta 究竟是谁 2.授权(Authorization):知道 ta 有没有权限对资源执行试图执行的操作   这其中,实际上存在着一个隐含的假设:   资源的所有权并不在用户手中,而是在外部的管理者手中,因此用户访问资源时才需要首先获取权限。   然而在当今的互联网中,很大一部分信息都是用户产生的,用户理应拥有自己资源的完全控制权限。   在这种场景之下,「授权」的概念依旧存在,只不过被授权的主体不再是用户,而是「想要访问用户资源的第三者」,而颁发权限的主体也不再是管理员,而是用户自己。   作为标准身份协议之一的 OIDC 正是为此种场景而生。   OIDC 全称是 OpenID Connect,是一个基于 OAuth 2.0 的认证 + 授权(OAuth 2.0 提供的能力)协议。   接下来的一周,Authing 技术博客 | 身份云动态将深度剖析 OIDC,你可以了解到:   OIDC 认证和授权的四种模式分别是什么? OAuth 2.0 和 OIDC 协议之间是什么关系? 除了 OIDC,还有 SAML、AD/LDAP、WS-Fed、JWT 等国际标准协议 ......   更多技术干货,在 Authing 技术博客搜索“身份云动态”,将身份云知识一网打尽。
IAM 负责人怎么做身份治理和管理(IGA)?听听 Gartner 怎么说
内容来源:《Gartner:IAM 负责人实施 IGA 指南》 翻译:Authing 市场部   最近,随着「元宇宙」概念的爆发,相信在未来,我们会看到越来越多的在线化场景。在这些场景中,「身份」至关重要。 下面,让我们来看一下数字身份的发展脉络。 在「昨天」,身份是软件的一部分,但是不同账号之间相互割裂,比如软件服务商在卖一个软件时,会内置身份系统,但是不同身份系统之间是隔离的,无法互通。 在「今天」,互联网平台已经出现一些身份提供商和统一登录解决方案。我们在不同平台,都可以用微信登录。但是这中间存在一个问题,身份和业务耦合使身份服务商使用用户数据进行大数据“杀熟”。 所以,市场上急需一个中立的身份服务平台来支持越来越复杂、多样的数字身份场景,这正是 Authing 的目标和价值所在。 在构建数字身份平台的过程中,产生了 IAM (Identity and Access Management ),即“身份识别与访问管理”。   在实现身份管理的基础上,一些安全服务商正在向 IAM 系统整合更多能力,身份治理和管理(Identity Governance and Administration,IGA)应运而生。IGA 不仅可以证明身份治理的合规性,也支持持续为权限管理安全保驾护航,以确保数字身份没有错误地配置访问权限,保证访问速度与准确性。 在这篇文章中,Gartner 站在企业 IAM 实施负责人的视角,详解 IGA 部署过程中应重点关注哪些问题,可为商业线同学提供一个参考视角。 Highlight 1、一个组织良好的 IAM 项目必须考虑 IGA 如何与相邻项目相适应。而选择 IGA 工具和部署 IGA 流程应该在 IAM 远景、路线图、架构和业务案例定义之后进行。 2、IGA 应该使用“广泛而浅显”的部署方法,即为所有用户跨多个目标系统推出“最小可行”的能力,然后逐步增加能力的深度。 3、在使用 IGA 时优先考虑身份分析,并通过使用扩展工具进行不同类型的身份分析。不同类型的分析技术相互关联、相互补充,发挥更大价值。 4、IAM 负责人可参考 Gartner 的三维企业策略和角色管理框架,关注三个控制层面:业务角色、配置角色、技术角色。 5、成功的企业角色管理策略需要明确一个策略管理框架,最佳实践是用身份生命周期过程建立身份边界。 6、自动化实现是 IGA 部署项目中最不可预测、成本最高的部分,寻求间接实现 IGA 的策略是必要的,ITSM 是处理间接实现访问请求的最简单方法。 7、实施 IGA 的负责人应关注利益相关方的诉求,并定义 kpi 驱动的 IGA 指标。 截取报告核心部分译文 1、一个组织良好的 IAM 项目必须考虑 IGA 如何与相邻项目相适应。选择 IGA 工具和部署 IGA 流程应该在 IAM 远景、路线图、架构和业务案例定义之后进行。 应该做到: 提供所有 IAM 服务的结构。 协调需要身份相关服务的技术项目。 确保与业务需求保持一致。 通过治理和管理,监督正在进行的开发和运营活动。 2、Gartner 的身份治理和管理部署计划模型使价值最大化,风险最小化。 安全与风险管理负责人通常对 IGA 部署缺乏耐心,因为它带来的商业利益太少、速度太慢。负责 IAM 的人应该遵循一种系统的、灵活的、基于风险的方法,在 IGA 部署计划期间提供增量收益。 IGA 应该使用“广泛而浅显”的方法部署,而不是“狭隘而深入”的方法——即为所有用户跨多个目标系统推出“最小可行”的能力,然后逐步增加能力的深度。从用户群体和集成目标的角度来看,更好的做法是更浅、更广地覆盖用户群体,而不是深入控制少数用户群体或少数应用。最好从价值较高的治理功能开始,比如用于标记休眠和未使用帐户的分析,然后在降低数据质量问题和不必要特权的更大风险之后,在程序中实现流程自动化。 3、将 IGA 部署划分为两个不同的轨道:构建和运行。 IGA 构建:清理和权利管理->身份和账户生命周期->工作流和认证->政策和角色框架 IGA 运行(申请入职):无监视的->监控->管理和治理->配置/实现 对应用程序采取分层迭代的立场,而不是“全有或全无”的方法。很常见的情况是,IAM 负责人优先选择适合入职的应用程序,然后对它们应用所有集成层(管理、治理和自动化配置),然后再转向其他候选应用程序。一种更有效的方法是使用成本效益分析,并根据请求量定义哪些应用程序应该一直采用自动化配置。 4、在使用 IGA 时优先考虑身份分析,并通过使用扩展工具进行不同类型的身份分析 在 IGA 部署过程中,获得更快 ROI 的最佳方法是,通过优先进行身份分析,在流程的早期重点关注风险缓解策略。 IGA 是一个复杂的 IAM 倡议,经常无法实现其功能、预算或时间目标。负责 IAM 的安全和风险管理负责人应该使用身份分析来降低身份风险,并深入了解部署 IGA 用例的情况。 传统的 IGA 方法并不能解决所有的身份治理和管理挑战。负责 IAM 的安全和风险管理负责人应该评估邻近和新生市场,以使用先进的分析工具来扩展 IGA,以简化身份治理负担。 在过去的五年中,身份分析在 IGA 中获得了越来越多的关注,它提供了支持决策的报告,例如,传统上用于角色挖掘、或计算可能用于解释发生了什么及其原因的风险评分。大多数 IGA 工具只提供了描述性和诊断类型的分析。 5、不同类型的分析技术 数据->分析->人工输入->决定->行动 描述:发生了什么事? 诊断:为什么会这样? 预测:会发生什么? 我应该做什么:决策支持、决定自动化 传统的 IGA 工具只能报告历史(通常是静态)数据,以计算风险评分。很少有 IGA 供应商开始提供预测功能(例如,在给定对等组相似性的情况下,预测特定授权的用户需求的建议)。 一些专业分析工具中实现了规范性分析,临近的新兴市场也开始使用,如云基础设施授权管理(CIEM)。CIEM 通过简化在多云 IaaS 场景中访问非常细粒度的授权的手动管理任务来扩展 IGA。 如何定义一个成功的企业策略和角色管理框架:一个成功的 IGA 计划需要一个正式的框架来实施和管理身份策略和企业角色。身份策略和企业角色是实现访问请求、SOD 和实现目标的重要组成部分。 传统的企业策略和角色管理方法(例如基于角色的访问控制【RBAC】)在动态环境中对每个用户具有数千个细粒度和短暂的授权,但由于遵从性和审计的原因,以及提供了减少 SOD 风险的方法,在例如 IaaS 环境中,像 CIEM 这样基于异常的、说明性的、基于分析的工具是对传统企业角色管理方法的很好的补充。 6、推荐使用 Gartner 的三维企业策略和角色管理框架,关注三个控制层面(业务角色、配置角色、技术角色) 使用 IGA 工具实施企业策略和角色管理的直观方法未能产生大多数组织所期望的结果。安全和风险管理负责人应该采用 Gartner 的三维企业策略和角色管理框架来有效地管理访问,在企业范围内使用角色。 当前大多数 IGA 工具部署由于依赖于手工操作模型的实现而存在控制缺陷。IAM 负责人应该关注三个控制层面,为其 IGA 部署建立一个可验证的模型。 在 IGA 部署项目的早期阶段,应重点关注大量系统和应用程序的授权管理,以提供“谁可以访问什么”的清晰图景。另外,应提高参与间接账户履行过程的实施效率,作为构建访问治理框架其他部分的过渡步骤。 7、成功的企业角色管理策略需要明确一个策略管理框架,最佳实践是用身份生命周期过程建立身份边界。 身份生命周期控制的第一个原则是,生命周期应该是一个闭环,例如雇佣关系中的从雇佣到分离,还包括与组织进行交互的所有身份关系(雇员、承包商、业务伙伴或客户)。身份边界控制的第二个原则是,一个人应该只由 IGA 工具的身份库中的一个身份表示。第三项原则是,应监测所有身份生命周期的完整性。 许多使用 IGA 工具的组织由于设计不良的身份生命周期过程在关键控制方面存在缺陷。IAM 负责人应该采用这些身份生命周期最佳实践,其中包括关键指标,为其 IGA 部署恰当地建立身份边界。 8、自动化实现是 IGA 部署项目中最不可预测、成本最高的部分,寻求间接实现 IGA 的策略是必要的,ITSM 是处理间接实现访问请求的最简单方法。 端到端自动化成本高昂,且充满集成挑战。在 IGA 部署的早期,过分强调自动化配置的 IAM 负责人会冒着将大部分项目风险提前加载的风险。 在 IAM 负责人中有一个常见的误解,即为了控制帐户存储库,IGA 平台需要提供端到端连接器驱动的自动化。他们的信念是,只有通过 IGA 系统分配访问权限,并在没有人为干预的情况下自动完成,控制需求才能得到满足。这导致许多组织将重点放在 IGA 产品部署的早期自动配置上。 自动化实现一开始看起来很简单,但实际上它是 IGA 部署项目中最不可预测、成本最高的部分。这一问题在 IGA 部署项目的早期阶段最为严重,在这一阶段进程尚未得到协调或精简。 经典的访问请求流程流在下图中进行了分解,显示了访问请求从生成到实现的生命周期。 这个请求流程没有必要同时将所有元素实现自动化。每个步骤都为过程增加了价值,同时需要花费时间和不同程度的情报(包括默认的和文档化的)。 参与者: (1)用户或管理人员手工提交的请求经常是模糊的。 (2)第二步涉及安全分析师处理请求并使其可操作。这通常涉及到研究“考古学”,以检查该请求实际上需要哪些权利。在考古阶段,还需要找出谁是审批人。 (3)一旦存在可操作的请求,安全分析师必须确定请求是否符合策略,并获得和记录批准。然而,糟糕的文档和大量的请求使得这项工作非常容易出错。 (4)从人类参与的角度来看,最后一步是最简单的。实现不像步骤 2 和步骤 3 那样需要那么多的经验或脑力,所以可以让低成本资源(如服务台技术人员)用文档化的程序来执行这项任务。 为了避免这些类型的问题在早期阶段破坏 IGA 项目,有必要从端到端自动化的全有或全无的完美主义中退一步,认识到最后一英里的集成通常是提高行政效率和控制 IGA 帐户管理有效性的最不重要的因素。当您有了间接实现的可靠策略时,最后一英里集成的方法将得到极大的改进。IT 服务管理(ITSM)是处理间接实现访问请求的最简单方法,但是访问管理和机器人过程自动化(RPA)解决方案也是应该考虑的选项,如IGA、RPA和管理软件机器人身份中所描述的那样。 间接实现 IGA 的可靠策略: 当一个 ITSM 工具不可用时,或者集成 ITSM 不可行时,可以使用 IGA 产品用工作流来模拟 ITSM 流程。 平均而言,组织可以实际地期望 15% 到 25% 的目标管理系统通过连接器自动直接供应。75% 到 85% 的系统最终将间接实现。组织应该以自动化处理 IGA 工具生成的超过 50% 的完成交易为目标,通过对需要自动化的系统进行优先排序。 IGA 通常是 IAM 项目中风险最高的项目。负责 IAM 的负责人应该采用治理主导的部署方法,以便在最小化整体项目风险的同时快速交付业务价值。 建议,依靠间接 IGA 工具——通过生成服务实现策划的 ITSM 的工具,例如,对于大多数目标系统实现,特别是在早期阶段的部署目标系统,一个开箱即用的适配器是不可用的。 9、负责人应关注利益相关方的诉求,并定义 kpi 驱动的 IGA 指标 IGA 经常需要更快速、更灵活的交付方法,以应对不断变化的业务条件,IGA 服务应优先采用 DevOps 和敏捷方法。 在规划部署 IGA 产品时,IAM 负责人应与业务和技术利益相关者(包括产品专家)密切合作,以评估可以使用敏捷框架部署的离散功能和潜在集成。 IGA 的主要利益相关者应该包括人力资本管理(HCM)、安全和技术、基础设施、应用程序所有者,甚至销售或营销团队。最基本的是,涉众要在一个单一的愿景中保持一致,并且为测量 IGA 过程采用的有效性定义了适当的 kpi。 性能和覆盖指标通常更容易产生,但对 IGA 涉众(除了 IAM 负责人)的价值会更低。有效性度量标准通常是最难产生的,但是它们也可以是特定涉众最重要的度量标准之一。这些度量标准通常是通过说明不同组件值的比较或比率得到的。度量标准将 IAM 计划的价值传达给利益相关者,并使 IAM 服务的有效评估和管理成为可能。IAM 负责人必须清晰地表达和维护显示其 IAM 项目服务覆盖率、性能和有效性的度量标准。 IGA 有效 kpi 包括: 准入认证撤销率(百分比、趋势和演变) 从授权账户中移除的孤儿账户数量 基于低风险分析分数的自动审批数量   点击此处了解更多行业身份管理 「解决方案」以及「最佳实践案例」
干货 | 身份云的云原生探索与实践:从 IAM 到 IDaaS
01 向云而生,从 IAM 到 IDaaS IAM 是“Identity and Access Management ”的缩写,即“身份识别与访问管理”。IAM 是一套通过全面建立和维护数字身份,并提供有效地、安全地 IT 资源访问的业务流程和管理手段,从而实现组织信息资产统一的身份认证、身份授权和身份数据的集中管理与审计。 通俗地讲:IAM 是让合适的人在恰当的时间通过统一的方式访问授权的信息资产,提供集中式的数字身份管理、认证、授权、审计的平台。 我们为什么还需要 IDaaS?是因为传统的 IAM 有几点不足: 1)运营能力弱,传统 IAM 账号中心的运营能力较弱,难以满足大型组织在业务方面的需求,例如,筛选出六个月内未登录过的用户,并向他们发送营销短信;或找到那些高频使用的用户并交由客户经理转化商机。 2)缺乏伸缩性和扩展性,当企业的用户量不断上升时,用户系统承载的压力也会不断增加,传统的 IAM 主要靠堆积服务器和设置负载均衡来优化,但登录失败的次数总是随着用户量的增长而增长,这对企业和用户来说都是灾难。 3)运维费用高,大多数 IAM 专家难以雇佣并且费用高昂。而且当企业计划将内部员工训练成专家时,他们面临着将训练好的员工流失到咨询公司或竞争对手那边。 4)安全性欠佳,数据资产正在逐渐超越实体资产成为企业最有价值的核心。而针对数据资产的盗窃和攻击也呈不断上升趋势。传统的 IAM 在本地构建,难以保障混合云环境下的企业安全,权限管理颗粒度较粗,访问控制策略单一。 5)难以更新换代,大多数企业的 IAM 系统需要消耗巨大的人力物力去更新换代,而当企业耗尽千辛万苦将系统更新好了之后,市面上又出现了新的技术和系统。 IDaaS 是在 IAM 基础上加上了云计算,相比 IAM 增加很多优势: 多种认证与访问控制策略、灵活高效; 基于云原生架构、天然适应,海量数据存储; 多维度保障数据安全; 在 IAM 的基础上实现全面拓展。 02 Authing 就是身份云 云计算有 IaaS、PaaS 和 SaaS 三层,5000 字干货 | IDaaS 身份即服务背后的基石中区分了这几种不同的交付模式。 Authing 的能力是一种可复用的身份基础设施,是以身份作为基础设施的一种来看待我们这个产品。 从云计算角度看 IDaaS,Authing 更多是 PaaS 和 SaaS 之上的一层,面向应用和用户侧。近年来联网的设备爆炸性增长,企业级的数据量也在增长,企业所用到的应用也在增长,我们是在这之上提供了统一的组件,它包含登录、注册、身份鉴权、用户交互这些功能,在 PaaS 和 IaaS 之上 SaaS 层提供了云的统一身份管理解决方案。 软件发展初期,“身份是软件一部分”的方案由于成本和复杂性的限制。如今,我们使用Facebook 的社交账户去登录其他平台。未来我们希望看到通过 Authing 这种统一的身份平台去连接任何组织和任何应用。 「ECUG Meetup 第 2 期」活动中,Authing CTO 尚斯年提到,我们面对客户有不同的交付环境,私有云、混合云、公有云,我们是如何交付我们的产品?在这之上我们提出了“云中立”的概念,我们的产品交付在用户任何云环境上。 比如这个客户只 30 个人,没有必要太复杂架构,在我们平台一个 SQLite 就可以跑起来。如果这个用户是 2000-10000 人的规模,需要一定可靠性、安全性的保障。 未来必须要有个统一的或者中心化的平台来解决所有身份问题,这同样也是我们的愿景。Authing 作为一个通用平台,既能支持云应用、IoT 应用;也能支持设备、私有云平台以及不同的组织;不仅如此,我们还能支持统一的面向私有云、公有云、混合云身份解决方案。 私有化方案这一点上,我们可以使用开源组建进行替换。我们开发者用户或者中小企业说没有必要私有化部署,直接用公有云平台,我们是在公有云之上提供公有云的解决方案和组件,这些东西都是可以替换的,我们做一套适配层 Adapter,可以在任何云平台上部署我们的产品。我们的产品已经部署在腾讯云、阿里云、AWS、Google 和用户的私有云上。 Authing 在公有云上也有一套高可用的架构设计,这也是比较经典的一套,就是多 Region 的概念。 03 面向服务的认证与授权 在微服务架构,尤其云原生倡导微服务时,如何进行服务治理?服务之间是如何完成认证和授权的?有没有统一的方案? Authing 基于 OpenID 的标准协议实现 M2M 的身份授权解决方案,M2M 是 Machine-to-Machine 的缩写,指的是服务之间的认证与授权。 举个简单的例子,如果你是个外包商,需要将业务 API 提供给业务方,几个外包商给客户开发一个大屏的数据展示,你希望将某些非核心的 API 访问授权给外包商,外包商完成非核心部分应用开发需要授权,过程中不需要用户参与,只需要确定来访者是哪些外包商以及哪些接口。 授权就像左图的服务 A 调用服务 B 和服务 C,B 允许服务 A 调用时,有让服务 A 调用服务 B 的权限,C 没有这样的权限。我们发现这种模式有一个问题,就是对代码有侵入性和耦合性,像服务 B 时、服务 C 有个专门认证模块,去判断服务 A 是否能调用,这些与业务无关的认证模块很有必要,我们可以在中间加一个统一的中间件 Authing,所有的认证控制都是通过 Authing。 04 开发者友好的身份云 我们做身份云平台之中非常关注开发者体验,这也是云原生很重要一个概念。 我们产品迭代有个概念叫「API First」,将所有能力 API 化提供给开发者。我们的目标是开发者完全可以基于我们平台的 API 做一个和我们平台一模一样的产品。用户可以通过不同设备访问我们平台全量的 API。 这是面向开发者最大的价值,在 CNCF2020 开发者现状报告中,现在全球有超过 470 万开发者在使用云原生技术,占全部后端开发者的 36%。开发者已经成为云原生变革最主要的推动力量。 我们在平台中提供全量的 SDK 和 API,后端的像 java、Python、.NET,前端的像 JavaScript,安卓、iOS,还有跨端的 React Native、Flutter。希望 API First 的体系架构是一种设计方法,它以 API 为中心,我们认为 API 开发出来的应用就像乐高积木一样模块化,是可复用可扩展的。面向 API 就是面向开发者,可以更好将身份服务集成在开发者和企业的业务当中。 在 API 之上我们提出了 Hyper Component 的概念。经常我们把 API 交付给客户时,客户说用你的 API 要进行二次开发,还要封装组件。我们将登录框做成组件的形式,只需要几行代码就可以嵌入到我们的应用系统平台之上。考虑到前端有不同的框架,我们也面向不同前端框架提供统一的组件化方案,同时支持 React、Angular 和 Vue,完全可以集成在企业和开发者自己的平台之中。 虽然我们提供了 API、提供了组件,用户的诉求是千变万化的。举几个用户常见的想法: 想要获取用户注册来源; 想要在系统维护期间,禁止用户访问登录; 注册之后,希望自动发送钉钉、企业、飞书信息; 希望在白名单的用户才可以访问; 希望收到邀请的用户才可以访问。 ... 用户的诉求无穷无尽,有没有一种方式尽可能满足用户的诉求? 我们还创建了「Authing Pipeline」的概念。Authing Pipeline 是一组运行在云端的用户自定义 JavaScript 代码,可以让开发者扩展、自定义 Authing 能力。在认证身份流之中,登录、注册前后都可以插入钩子执行用户定义的函数。所以身份服务是一种统一平台,面向用户不同场景,去适应用户的场景。 还有一个问题是用户担心数据的安全性,尤其是外企的用户经常说你们的数据是不是被政府所监控?我们核心业务数据放在你这不安全?所以我们提供了自定义数据库的功能,用户的数据完全由用户做主,企业或开发者的数据并不存储在 Authing 上,在每次认证时通过调用脚本访问自身平台的数据,这种方式有一定的性能损耗,但是安全性更好,我们提供了这样一个自定义数据库的连接。 我们有两种数据库连接模式。一种是惰性数据迁移模式,每次用户访问自身数据库,完成信息比对之后将数据惰性迁移到平台;还有一种完全使用你自己的数据库,我们平台只完成用户身份认证,不存储任何数据。这种模式是通过脚本,脚本是 JavaScript,可以连接像 MangoDB、MySQL 数据库等等。 上图是完整的技术方案,在用户完成认证的时候,我们进行函数计算,函数计算也是通过后台上传的,像 AWS 或者阿里云、腾讯的云函数计算,用户通过自身云函数计算访问自身数据库完成数据接入。 这个方式也有问题: 构建和上传速度慢、用户体验差; 有网络通信时间延迟,登录等待时间长; 函数冷启动问题,虽然现在各大平台将函数的冷启动基本解决了,面向温启动,几十毫秒之内能够启动,但是对用户来讲也是没必要的损失; 和我们云平台耦合性比较重,私有化部署时无法实现快速接入。 我们找到了 Safeify 的 Javascript 沙箱解决方案,相比之前其他沙箱模式这个方案提供更好的资源隔离能力。这种沙箱可以通过进程池管理调度沙箱进程,处理的数据和结果,还有公开给沙箱的方法,针对沙箱进程进行 CPU 和内存配额限制。它的核心是沙箱运行在不同进程,然后完成任务。 05 Authing 快速发展背后的云原生技术 Authing 在 2 年内完成快速发展,去年完成第三轮融资,我们平台有千万级的客户,我们是如何做到这些的呢? 第一点,构建基础设施及代码方案。使用 Terraform 编排。业务上云对 IT 基础设施的管理提出了更苛刻的要求,我们需要: 1)更好的系统效能:及时了解相关领域而规避了风险,确保了合规和 IT 基础设施的安全; 2)更快的速度:在今天,软件交付/更新的速度被认为是成功背后最重要的因素之一,需要保证基础设施的高效迭代; 3)高效的变更管理:在部署到生产环境之前,代码常常被修改和测试。基础设施即代码确保了在不同设备、平台和系统中实现更安全和高效的变更管理; 4)可扩展的基础设施:硬件的虚拟化使得在需要时增加、替换和扩展资源。 面对这个问题,我们使用了 Terraform 这个编排。给客户交付时,如果客户希望部署在阿里云平台,也基于 Terraform 进行快速基础设施搭建,当用户有基础设施和环境变更时,可以快速完成底层基础设施的变更,而且每次变更都是有迹可寻的。 第二,持续交付。云原生系统之中应该关注用户交付能力。并没关注以下两点: 1)概念和操作尽可能简单,每一个成员无论技术水平高低,都可以可以快速理解 CICD 流程并将自己代码发布到不同环境。 2)最小适用,如无必要勿需增实体,用尽可能简单的组件完成代码集成和上线交付。发展之是,我们希望所有的东西尽可能简单,一个组件完成交付,就不会扩大更多组件,保证系统的复杂性。 第三,日志与监控。我们是一个 SaaS 平台,保证 7×24 小时高可用,有任何线上问题要及时暴露出来,这张图展示的是我们基于 Prometheus 的监控与报警解决方案。 点击此处了解更多行业身份管理 「解决方案」以及「最佳实践案例」
零信任的主流技术 IAM 你了解吗?
零信任的主要思想是,默认企业内、外部的任何人、事均不可信,对任何试图接入网络或访问网络资源的人、事、物进行持续验证,打破了边界化的网络防御思路,是一种更适应新需求的理念。 如何实现「零信任」网络安全体系结构?中就提到,零信任核心概念依旧保持不变:在当今的安全环境中,它不再与网络有关,而是与访问您系统的人员以及对这些人的访问控制有关。 零信任的兴起不能简单看做某种技术、产品的扩展,而是对固有安全思路改变。在产业端,随着谷歌等公司在零信任上的进展,2019-2020 年,NIST 在 5 个月内连续发布两版《零信任架构》标准草案,意味着零信任正向标准化进展。 从技术视角划分,零信任的主流技术分为三种:即 SIM:S 为 SDP(Software Defined Perimeter, 软件定义边界)、I 为 IAM(Identity and Access Management,身份识别与访问管理系统),M 为 MSG(Micro-Segmentation,微隔离)。 01 零信任技术 软件定义边界(SDP) 软件定义边界(SDP)是被云安全联盟采纳并推崇的一种方案。这种方案还有一个更为形象的别名——“黑云”。 之所以被称为黑云,和其预期达到的效果有关。SDP 可以为企业建立虚拟边界,利用基于身份的访问控制和权限认证机制,让企业应用和服务“隐身”。当黑客试图进行攻击时,会发现看不到目标而无法攻击,只有获得权限的业务人员可以正常访问。 根据云安全联盟的定义,SDP 的主要组件包括发起主机(客户端),接受主机(服务端)和 SDP 控制器,客户端和服务端都会连接到这些控制器。二者间的连接通过 SDP 控制器与安全控制信道的交互来管理。 身份识别与访问管理(IAM) 身份识别与访问管理(IAM)是网络安全领域中的一个细分方向。IAM 产品可以定义和管理用户的角色和访问权限,即决定了谁可以访问,如何访问,访问后可以执行哪些操作。 IAM 的核心主要几个方向: 认证:通过确认实体(包含人与设备等)的身份,建立信任,其中包括多因素认证等。 访问控制:确定实体通过认证之后,匹配怎样的权限,访问怎样的系统。 身份治理:对实体在整个生命周期内(如员工入职、转正、调岗、离职等身份变更过程)进行身份管理,匹配正确的权限。 特权身份管理:是对管理员等权限较高的账户等进行进一步管理。 微隔离(MSG) 微隔离通过细粒度的策略控制,可以灵活地实现业务系统内外部主机与主机的隔离,让东西向流量可视可控,从而更加有效地防御黑客或病毒持续性大面积的渗透和破坏。当前微隔离方案主要有三种技术路线,分别是云原生微隔离、API 对接微隔离以及主机代理微隔离,其中主机代理微隔离更加适应新兴技术不断更迭及应用带来的多变的用户业务环境。 零信任“从不信任、持续验证”的理念契合了去边界化的安全状况,现在网络安全最大的挑战是私有应用程序的访问端口十分分散,以及内部用户权限过多,这两方面正是零信任理念可以解决的问题。 02 以身份为中心 零信任的提出,最主要的原因是为了解决传统上仅基于边界管控的粒度过粗、无法细化相关权限的问题。但在目前中国信息安全的大环境下,其实早就已经存在很多类零信任的实践,比如在企业内部使用的各种堡垒机、云端身份认证、VPN 等。 可以认为,零信任的本质应该是提出一个统一的治理框架,整合上述这些分散、无组织的甚至是凌乱、无序的认证、授权和资源访问控制应用或装置,最终可能演化成一套完整的标准和落地方案,包括各种访问控制策略标准、授权策略标准、参与对象标准和 API 标准等等。 2021年,联合国提出的零信任战略就提及,要达成的零信任目标分为五个支柱: 1、身份:机构工作人员使用企业范围的身份,来访问他们在工作中使用的应用程序。防网络钓鱼 MFA ,可保护这些人员免受复杂的在线攻击。 2、设备:联邦政府拥有其运营和授权供政府使用的每台设备的完整清单。 3、网络:机构在其环境中加密所有 DNS 请求和 HTTP 流量,并开始围绕其应用程序对网络进行分段。 4、应用程序:机构将所有应用程序视为连接到互联网的应用程序,定期对其应用程序进行严格测试,并欢迎外部漏洞报告。 5、数据:机构在部署利用彻底数据分类的保护方面有一条清晰、共享的路径。 零信任对访问控制进行了范式上的颠覆,引导安全体系架构从「网络中心化」走向「身份中心化」,其本质诉求是以身份为中心进行访问控制。Authing 正是「零信任」安全体系下身份安全基础设施的产品实现。 福利时间 免费领取 Authing 产品体验券 点击此处了解更多行业身份管理 「解决方案」以及「最佳实践案例」
IDaaS 已经替代传统 IAM 成为企业标配
在构建数字身份平台的过程中,产生了 IAM (Identity and Access Management),即“身份识别与访问管理”。传统 IAM 服务虽然解决了部分身份问题,但开发效率低,成本浪费严重。我们每开发一个应用,就要进行一次用户系统的开发,并且实施复杂。 IDaaS 则是在 IAM 基础上加上了云计算,基于云原生架构、天然适应,实现海量数据存储,多维度保障数据安全。 随着企业数字化转型和上云进度的加速,企业信息安全的维度和边界正在变得越来越复杂。身份认证和访问权限管理作为第一道门承载着极为关键的使命。在这样的背景下,传统 IAM 的劣势逐渐暴露: 难以保证混合云环境中的访问安全; 在内部员工管理和外部用户管理等场景中力不从心; 上线新应用和兼容老应用时不够灵活。 与此同时,横空出世的 IDaaS 服务由于兼具云的扩展性优势和跨环境的身份识别及权限管理能力,正在取代传统的 IAM。其实,这场身份与访问管理的变局早已被窥见。    IAM 释义 IAM 是 Identity and Access Management 的缩写,即身份认证和访问管理。科技咨询公司 Gartner 对 IAM 的定义是:“让正确的人在正确的时间以正确的理由访问正确的资源。”其核心功能包括: 认证(Authentication)管理 授权(Authorization)管理 账号(Account)管理 审计(Audit)管理 因此传统的 IAM 提供商又被称为 4A 厂商,他们为企业集成现有系统,构建用户管理、身份认证、权限管理、审计整合于一体的集成应用平台。 IDaaS 释义 IDaaS 是 Identity as a Service 的缩写,是由第三方服务商构建并维护的托管式 IAM 服务。 IDaaS 包含传统 IAM 的全部功能,并能为企业带来更多收益: 提升营销和运营效率 加速新业务上线 提升安全性降低网络攻击风险 提升用户体验 …… SaaS + IAM = IDaaS 软件即服务:Software as a Service,缩写就是我们常说的 SaaS。 即服务(aaS)通常是指由别人(一般指云服务厂商)提供的服务,它可以让个人或企业专注于自身更重要的业务。 在 SaaS 这种软件交付模式下,软件不再需要复杂的安装部署过程,只需通过网络连接就可直接使用,软件及其数据托管在云服务厂商中,厂商将全程负责处理软件更新、漏洞修复等维护工作。用户通常通过 Web 浏览器或 API 连接就可以使用软件。 例如腾讯云直播的 SaaS 方案,以及 Microsoft Office 365 其实也是一种典型的针对个人用户的 SaaS 应用。 IDaaS VS IAM(4A) 运营能力 传统 IAM 账号中心的运营能力较弱,难以满足大型组织在业务方面的需求,例如,筛选出六个月内未登录过的用户,并向他们发送营销短信;或找到那些高频使用的用户并交由客户经理转化商机。类似场景在企业的日常运营中几乎无处不在,但传统的 IAM 并不具备如此灵活的功能。而 IDaaS 的多租户运营平台和自动化工作流(Workflow)则可以便捷地实现此类操作,企业运营效率得以大幅提升。 伸缩性和扩展性 当你的用户量不断上升时,用户系统承载的压力也会不断增加,传统的 IAM 主要靠堆积服务器和设置负载均衡来优化,但登录失败的次数总是随着用户量的增长而增长,这对企业和用户来说都是灾难。云原生架构的 IDaaS 则可以很好的解决这一问题,以 Authing 身份云 IDaaS 为例,每月有近千万用户通过 Authing 登录进入数千个系统中,有了大规模数据的处理经验,像 Authing 这样的第三方 IDaaS 平台构建起的数字身份解决方案能够更好的支持企业扩张。 企业经常遇到的另一个问题是不断接入新系统、开发新应用。而每次上线都需要和用户中心打通实现单点登录(SSO),这对于 IAM 来说是一项繁杂的任务,甚至市面上绝大部分的 IDaaS 都难以灵活支持。而像 Authing 这种开发者友好的 IDaaS 则通过封装完备的 500 多个 API 和十几种语言的 SDK,让开发人员可以像搭积木一样方便地接入新应用并兼容老应用。助力新业务快速上线。 安全性 数据资产正在逐渐超越实体资产成为企业最有价值的核心。而针对数据资产的盗窃和攻击也呈不断上升趋势。传统的 IAM 在本地构建,难以保障混合云环境下的企业安全,权限管理颗粒度较粗,访问控制策略单一。例如,当某一员工改变了他的常用登录地址或更换了他的常用登录设备时,该成员账号被窃取的风险性将增加,传统 IAM 会用“一刀切”的方式收回其所有权限,但更好的做法是通过人脸或指纹等其他方式对用户进行双重验证,待确认后根据预置策略授权,在 IDaaS 平台中,基于属性的访问权限控制(ABAC)让企业的 IT 人员可以轻松灵活的配置类似策略。 第三方云服务的安全性一直饱受质疑,但越来越多的数据显示,云服务相比本地部署的软件有更高的安全性,IDaaS 相较于 IAM 也是如此,以 Authing 为代表的国产 IDaaS 平台利用 KMS 加密技术让托管的数据仅能被所有者访问。不仅如此,Authing 还提供私有云(private cloud)方案,企业既可以享受到云原生产品的优势,又能规避风险。 关于 Authing Authing 是国内首款以开发者为中心的全场景身份云产品,为企业和开发者提供完善安全的用户认证和访问管理服务。作为云原生架构下的身份云产品,Authing 在产品创建初期,目标就是服务亿级的企业和个人开发者客户,轻量级、易部署、低消耗、技术栈成熟,运维易的云原生技术产品架构,成为了 Authing 的首选。 点击此处了解更多行业身份管理 「解决方案」以及「最佳实践案例」
Online
Quotation
authing
Add company WeChat
400 888 2106
Online
Phone