SAML的全称是Security Assertion Markup Language， 是由OASIS制定的一套基于XML格式的开放标准，用在身份提供者（IdP）和服务提供者 (SP)之间交换身份验证和授权数据。
SAML的一个非常重要的应用就是基于Web的单点登录（SSO）。
在SAML协议中定义了三个角色，分别是principal：代表主体通常表示人类用户。identity provider (IdP)身份提供者和service provider (SP)服务提供者。
IdP的作用就是进行身份认证，并且将用户的认证信息和授权信息传递给服务提供者。
SP的作用就是进行用户认证信息的验证，并且授权用户访问指定的资源信息。
接下来，我们通过一个用SAML进行SSO认证的流程图，来分析一下SAML是怎么工作的。
上图中User Agent就是web浏览器，我们看一下如果用户想请求Service Provider的资源的时候，SAML协议是怎么处理的。
SP将会对该资源进行相应的安全检查，如果发现已经有一个有效的安全上下文的话，SP将会跳过2-7步，直接进入第8步。
RelayState是SP维护的一个状态信息，主要用来防止CSRF攻击。
其中这个SAMLRequest是用Base64编码的<samlp:AuthnRequest>，下面是一个samlp:AuthnRequest的例子：
为了安全起见，SAMLRequest还可以使用SP提供的签名key来进行签名。
IdP收到这个AuthnRequest请求之后，将会进行安全验证，如果是合法的AuthnRequest，那么将会展示登录界面。
这个form中包含了SAMLResponse信息，SAMLResponse中包含了用户相关的信息。
同样的SAMLResponse也是使用Base64进行编码过的<samlp:Response>。
我们可以看到samlp:Response中包含有saml:Assertion信息。
我们可以看到上面的所有的信息交换都是由前端浏览器来完成的，在SP和IdP之间不存在直接的通信。
这种全部由前端来完成信息交换的方式好处就是协议流非常简单，所有的消息都是简单的GET或者POST请求。
如果为了提高安全性，也可以使用引用消息。也就是说IdP返回的不是直接的SAML assertion，而是一个SAML assertion的引用。SP收到这个引用之后，可以从后台再去查询真实的SAML assertion，从而提高了安全性。
SAML协议是2005年制定的，在制定协议的时候基本上是针对于web应用程序来说的，但是那时候的web应用程序还是比较简单的，更别提对App的支持。
SAML需要通过>看完了亚马逊的web service是如何鉴权的，re-read how Amazon Web Services does authentication 讲的确实有道理，整个流程如下:
[客户端]在调用REST API之前，首先将待发送消息体打包, combine a bunch of unique data together(websevice端将要接收的数据)
[客户端]用系统分派的密钥使用哈希(最好是HMAC-SHA1 or SHA256 ) 加密(第一步的数据)
[客户端]向服务器发送数据:
用户身份认证信息例如,用户ID，客户ID或是其他能别用户身份的信息。这是公共API，大家都能访问的到(自然也包括了那些居心叵测的访问者)系统仅仅需要这部分信息来区分发信人而不考虑可靠与否(当然可以通过HMAC来判断可靠性)
发送生成的HMAC码
发送消息体（属性名和属性值），如果是私有信息需要加密，像是（“mode=start&number=4&order=desc”或其他不重要的信息）直接发送即可
(可选项)避免重放攻击 “replay attacks” o的唯一办法就是加上时间戳。在使用HMAC算法时加入时间戳，这样系统就能依据一定的条件去验证是否有重放的请求并拒绝
[服务器端]接收客户端发来的消息
[服务器端] (参看可选项)检查接收时间和发送时间的间隔是否在允许范围内（5-15分）以避免重放攻击replay attacks
提示: 确保待检对象的时区无误daylight savings time
更新: 最近得到的结论就是直接使用UTC时区而无需考虑DST的问题 use UTC time
[服务器端]使用发送请求中用户信息（比如API值）从数据库检索出对应的私匙
[服务器端]
跟客户端相同，先将消息体打包然后用刚得到的私匙加密（生成HMAC）消息体
(参看可选项) 如果你使用了加入时间戳的方式避免重放攻击，请确保服务端生成的加密信息中拥有和客户端相同的时间戳信息以避免中间人攻击man-in-the-middle attack
[服务器端] 就像在客户端一样，使用HMAC哈希加密刚才的信息体
[服务器端]
将服务器端刚生成的哈希与客户端的对比。如果一致，则通讯继续；否则，拒绝请求!
提示: 在打包消息体的时候一定要考虑清楚，如果像亚马逊进行签名版本1中信息识别那样会面临哈希冲突的问题 open yourself up to hash-collisions! (建议：将整个包含URL的请求加密即可!)
特别提示:私匙绝对不能在通讯过程中传递，它仅仅用来生成HMAC,服务器端会自动查询出它的私匙并重新生成自己的HMAC我来翻译公匙仅仅用来区分不同的用户，即使被破解也无所谓。因为此时的消息无需判断其可靠性，服务端和客户端还是要通过私匙来加密（比如，前缀、后缀，倍数等等）
10/13/11更新：Chris最近发现 pointed out 如果在HMAC计算中加入了URI或是>
OAuth20是一个授权框架，他规定了客户从授权服务器获取令牌Token的规则。
要理解OAuth20，先要知道为什么会有这个东西产生，或者说他能帮我们解决什么问题，其实简单说他就是帮我们解决了访问安全问题。先看如下的一张图：
显示了我们没有引入任何安全机制情况下的资源访问过程，可以看到正常的用户和恶意的用户都可以通过向资源服务器的接口发送请求获得用户数据。显然恶意用户不该获取数据，他是非法获得，这个情况不应该被允许，需要一种机制保护用户数据。
OAuth20包含了资源拥有者，授权服务器，客户应用，授权服务器，资源服务器。
客户应用： 通常是一个 WebWeb 或者无线应用，它需要访问用户的。
资源服务器： 是一个 webweb 站点 或者 web service web service web service web service API ，用户的受保护。
授权服务器： 在客户应用成功认证并获得授权之后，向客户应用颁发访问令牌Access Token。
资源拥有者： 资源的拥有人，想要分享某些资源给第三方应用。
1）授权码(Authorization Code Token)，仅用于授权码授权类型，用于交换获取访问令牌和刷新令牌
2）刷新令牌(Refresh Token)，用于去授权服务器获取一个新的访问令牌
3）访问令牌(Access Token)，这是OAuth令牌类型中最核心的一个，用于代表一个用户或服务直接去访问受保护的资源
4）Bearer Token，不管谁拿到Token都可以访问资源，像现钞
5）Proof of Possession(PoP) Token，可以校验client是否对Token有明确的拥有权
上面提到了需要提供一种机制来保护数据，OAuth20提供的就是一种授权机制，就是说用户要访问资源必须先通过授权服务器授权拿到Access Token(访问授权)，他拿着这个Access Token才能去资源服务器去要他想要的数据，示意图如下：
这里看到我们引入了一个授权服务器，这个授权服务器就是专门负责颁发Access Token的，客户应用需要从授权服务器中获得Access Token，获得后再向资源服务器去获取数据，请求中包含了Token一起发到资源服务器，资源服务器首先要验证这个Token是否合法，如果合法再返回数据给客户应用。
上图中红色圈圈圈起来的就是OAuth20框架协议工作的地方，他规定了客户应用如何获取Access Token，以及如何使用Token的整个过程。
其中核心的授权服务器包括了授权端点，令牌端点，校验端点，注销端点，如下图所示：
OAuth20中规定了多种授权模式，各种模式实现的复杂程度和安全系数不一样，我们先分别看一下四种授权模式：
1）授权码(Authrization Code)模式：
基本流程是先通过前端渠道客户获取授权码，然后通过后端渠道，客户使用Authrization Code去交换Access Token和可选的Refresh Token，这种模式是最安全的模式，因为令牌不会通过user-agent去传递，完整的过程如下图：
授权码模式的优点是比较安全，他可以有token过期时间，而且上面的第四和第五步都是在服务器之间的访问，很难被截获，用户信息也存在服务端，这样就保证了他的安全性。他的缺点是需要进行多次请求才能访问到资源。
授权码模式假定资源拥有者和客户不在一台设备上，他拥有高安全性的保障，目前市面上主流的第三方认证都是采用这种模式。
2)隐式/简化(Implicit)模式
基本流程是Access Token直接通过前端渠道从授权服务器返回，完整的过程如下图：
3)密码(Resource Owner Password)模式
基本流程是使用用户名/密码作为授权方式从授权服务器上获取Access Token，而且一般不支持refresh token，完整的过程如下图：
4)客户端(Client)模式
基本流程是通过后端渠道去获取一个Access Token，因为客户凭证可以使用对称或者非对称加密，该方式支持共享密码和证书，完整的过程如下图：
客户端模式适合用作服务器间通信场景。
授权码模式有一个基本的选择流程，如下图：
OAuth2已经成为了一个授权的标准协议，大家在很多的产品中都能看到它的身影，比如我们登录一个网站，支持微信,QQ等登录方式，这里QQ和微信提供了授权服务。有很多的授权组件都能提供这种OAuth2认证方式，比如keycloak等，但我们也可以在SpringBoot security中实现OAuth2授权，这篇文章将详细讲解每一个步骤来演示如何在SpringBoot中实现OAuth2授权。OAuth 2 是一种授权协议，用于通过 >
@[TOC]
@[TOC]
1#Keycloak项目配置
步骤1：Keycloak入门
请参阅Keycloak入门 文档 以运行和设置keycloak管理员用户。
运行Keycloak后，使用 >项目地址: >
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）