WSO2 Identity Server 5.0.0身份验证框架
WSO2 Identity Server 5.0.0将身份管理带入了一个新的方向。 不再有联邦筒仓或意大利面条身份反模式 。 我们在IS 5.0.0中引入的身份验证框架为这一切提供了动力。 本博客文章的目的是介绍与身份验证框架相关的高级概念。
入站身份验证器的职责是识别并解析所有传入的身份验证请求，然后构建相应的响应。 给定的入站身份验证器分为两个部分。
- 请求处理器
- 响应生成器
对于WSO2 IS支持的每个协议–应该有一个入站验证器。 它具有开箱即用的功能，带有针对SAML 2.0，OpenID，OpenID Connect，OAuth 2.0和WS-Federation（被动）的入站验证器。 换句话说，SAML 2.0请求处理器的职责是接受来自服务提供商的SAML请求，验证SAML请求，然后构建身份验证框架理解的通用对象模型，并将请求移交给它。 SAML响应构建器的职责是从身份验证框架接受通用对象模型，并根据该模型构建SAML响应。
请求处理器和响应生成器都支持协议，而身份验证框架未与任何协议耦合。
本地身份验证者的责任是使用本地可用的凭据对用户进行身份验证。 这可以是用户名/密码，甚至可以是IWA（集成Windows身份验证）。 本地身份验证器与入站身份验证器分离。 一旦将初始请求从入站身份验证器移交给身份验证框架，身份验证框架就会与服务提供商配置组件进行对话，以找到与当前身份验证请求相对应的向服务提供商注册的一组本地身份验证器。
一旦本地身份验证成功完成，本地身份验证器将通知框架。 现在，框架将决定不再需要身份验证，并将控制权移交给入站身份验证器的相应响应构建器。
您可以开发自己的本地身份验证器，然后将其插入Identity Server。
联合身份验证器的职责是通过外部系统对用户进行身份验证。 这可以与Facebook，Google，Yahoo，LinkedIn，Twitter，Salesforce或任何其他身份提供商一起使用。 联合身份验证器与入站身份验证器分离。 一旦将初始请求从入站身份验证器移交给身份验证框架，身份验证框架便会与服务提供商配置组件进行对话，以找到与当前身份验证请求相对应的向服务提供商注册的联合身份验证器集。
联合身份验证器没有任何价值，除非其与身份提供者相关联。 例如，开箱即用的IS 5.0.0支持SAML 2.0，OpenID，OpenID Connect，OAuth 2.0和WS-Federation（被动）。 SAML 2 .0联合身份验证器本身没有任何值。 它必须与身份提供者关联。 通过SAML 2.0联合身份验证器，Google Apps可以成为身份提供者。 该联合身份验证器知道如何向Google Apps生成SAML请求并处理来自它的SAML响应。
联合身份验证器分为两部分。
- 请求生成器
- 响应处理器
联合身份验证成功完成后，联合身份验证器将通知身份验证框架。 现在，框架将决定不再需要身份验证，并将控制权移交给入站身份验证器的相应响应构建器。
请求构建器和响应处理器都支持协议，而身份验证框架未与任何协议耦合。
您可以开发自己的联合身份验证器，然后将其插入Identity Server。
这是一种特殊的身份验证器。 请求路径验证器始终是本地验证器。 一旦将初始请求从入站身份验证器移交给身份验证框架，身份验证框架便会与服务提供者配置组件进行对话，以找到向服务提供者注册的与当前身份验证请求相对应的请求路径身份验证者集。 然后，框架将检查是否有适用于初始身份验证请求的请求路径身份验证器。 换句话说，仅当初始身份验证请求附带了适用的凭据集时，请求路径身份验证器才会执行。
请求路径身份验证器始终要求用户凭据出现在初始身份验证请求本身中。 这不需要最终用户与Identity Server的任何交互。
成功完成请求路径身份验证后，请求路径身份验证器将通知身份验证框架。 现在，框架将决定不再需要身份验证，并将控制权移交给入站身份验证器的相应响应构建器。
IS 5.0.0中身份提供者配置的职责是代表外部身份提供者。 这些外部身份提供者可以是Facebook，Yahoo，Google，Salesforce，Microsoft Windows Live或任何人。 如果我们要针对这些身份提供者对用户进行身份验证，则必须将一个或多个联合身份验证器关联。 例如，如果我们要针对Google Apps验证用户身份，则需要将SAML 2.0身份验证器与Salesforce身份提供商关联。 如果我们要根据Yahoo对用户进行身份验证，则需要将OpenID身份验证器与其关联。 为了简化此过程，Identity Server还附带了一组更特定的联合身份验证器。 例如，如果您要针对Facebook进行身份验证，则无需配置OAuth 2.0身份验证器，而是可以直接使用Facebook联合身份验证器。
每个身份提供商配置也可以维护声明映射。 这是将其自己的一组声明映射到身份服务器的声明。 当联合身份验证器的响应处理器组件收到外部身份提供者的响应时，在将控制权移交给身份验证框架之前，响应处理器将创建从响应中接收到的用户声明的名称/值对。身份提供商。 这些声明特定于外部身份提供者。 然后，身份验证框架负责从身份提供者组件中读取声明映射配置并进行转换。 因此，在框架内时，所有用户声明值将采用通用格式。
服务提供商配置的职责是代表外部服务提供商。 这些外部服务提供商可以是Web应用程序，移动应用程序，Liferay门户，Salesforce（Salesforce可以既是服务提供商又是身份提供商），Google Apps（Google Apps既可以是服务提供商又可以是身份提供商）和还有很多。 在服务提供者配置中，您可以定义服务提供者与身份服务器的通信方式-这是通过入站身份验证器进行的。 注册服务提供商时，您需要将一个或多个入站身份验证器与其关联。
服务提供商配置还定义了如何对用户进行身份验证。 这可以通过本地身份验证器，请求路径身份验证器或联合身份验证器进行。 基于此配置，Identity Server知道何时（通过入站身份验证器）接收到身份验证请求，如何根据发起请求的服务提供商对用户进行身份验证。
每个服务提供商配置也可以维护声明映射。 这是将其自己的一组声明映射到身份服务器的声明。 当身份验证框架将一组声明（它从本地用户存储或从外部身份提供程序获得）移交给入站身份验证器的响应构建器时，框架将与服务提供商配置组件进行对话，找到声明映射并进行索赔转换。 现在，响应构建器将以相应服务提供商理解的方式接收声明。
服务提供商可以定义如何在Identity Server上针对由其发起的身份验证请求对用户进行身份验证。 这样做时，每个服务提供商可以选择多个身份验证者-因此，最终用户将获得多个登录选项。 这可以是本地身份验证器和联合身份验证器的组合。
服务提供商可以定义如何在Identity Server上针对由其发起的身份验证请求对用户进行身份验证。 在此过程中，每个服务提供商可以定义多个步骤，并且每个步骤可以选择多个身份验证者。
身份验证框架将跟踪每个步骤中的所有身份验证器，并且仅当用户在当前步骤中成功进行身份验证时，才继续进行下一步。 在给定步骤中，其在步骤之间为“与”，而在验证者之间为“或”。
翻译自: https://www.javacodegeeks.com/2014/10/wso2-identity-server-5-0-0-authentication-framework.html