单点登录常用协议原理和流程

一、背景

近期公司准备上身份认证平台(IAM),主要有两块内容,一部分是单点登录、一部分是账号生命周期管理。其中涉及几个常用的单点登录标准认证协议,其中有SMAL、LOAP、CAS、OIDC、Oauth2.0,本篇文章简单介绍。

二、单点登录介绍

单点登录是指用户只需输入一次用户密码,在某一个应用完成认证登录后,即可直接进入所有应用系统。由此可以看出,单点登录比统一认证更进一步,它在让所有应用系统使用一套用户密码访问的基础上,还能让用户只需要登录其中一个应用,访问其他应用不在需要再输入这套用户密码。

三、单点登录协议

3.1、CAS协议

CAS( Central Authentication Service)中央认证服务,是一种独立开发指令协议,旨在为web应用系统提供一种可靠的单点登录方法。

CAS是开源的企业级单点登录方案,Apache2.0许可证,允许修改、发布、商用。
Cas包含两个部分,Cas Server和Cas Client。
    Cas Server需要单独部署,负责对用户的认证工作。
    Cas Client和受保护的客户端应用部署在一起,以Filter的方式保护受保护的资源,负责处理对客户端受保护资源的访问请求,需要对请求方进行身份认证时,重定向到Cas Server进行认证。
Cas Client支持多种客户端,包括Java、PHP、Python、.Net、Perl、Apache、uPortal、Ruby等语言。

流程说明: 

I,用户浏览器访问应用中的受保护资源。
II,Cas Client拦截请求,检查请求中是否带有Service Ticket(ST),如果没有就将请求重定向到Cas Server登录地址,并传送Service。
III,用户输入认证信息,登录
IV,用户登录成功,Cas Server随机产生一个相当长度、唯一、不可伪造的Service Ticket,并缓存Service Ticket用于验证,之后重定向到Service地址,并为客户端浏览器设置一个Ticket Granded Cookie(TGC)。
V,Cas Client拿到Service和新产生的Ticket后,请求Cas Server验证Service Ticket。
VI,Cas Server验证通过后,返回用户信息。

协议过程中所有与Cas的交互均采用SSL协议,确保ST和TGC的安全性;过程中有两次重定向的过程;Ticket验证过程对用户来说是透明的。
当用户访问另一个应用的服务再次重定向到Cas Server时,Cas Server会主动获取TGC,如果TGC有效,则直接进入步骤IV,如果TGC失效则需要用户重新认证。

3.2、OAuth3.0协议

OAuth(开放授权)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如用户信息、照片,联系人),而无需将用户名和密码提供给第三方应用。

常见使用场景:

  • API访问授权
  • 授权登录
  • web应用单点登录

认证和授权过程中涉及的三方包括:
服务提供商(IAM):用户用来存储受保护资源。
用户:受保护资源的拥有者。
客户端(应用):需要访问受保护资源的第三方应用。

流程说明: 

I,用户打开客户端,客户端要求用户授权。
II,用户同意给与授权,向服务提供商获取一个临时授权码。
III,客户端使用临时授权码,向服务提供商申请令牌。
IV,服务提供商验证临时授权码无误后,向客户端发放令牌。
V,客户端使用令牌,向服务提供商申请获取受保护资源。
VI,服务提供商确认令牌无误后,向客户端开发保护资源。

详细见《浅谈Oauth2.0授权》。

3.3、OIDC协议

OIDC(OpenID Connect),OIDC=(Identity, Authentication) + OAuth 2.0。它在Oauth2.0之上构建了一个身份层,是一个基于Oauth2.0协议的身份认证标准协议。OIDC的核心在于在Oauth2.0的授权流程中,一并提供ID Token来标识用户身份认证信息,ID Token使用JWT格式包装,可以安全地传输给第三方客户端并且容易被验证。此外还提供了UserInfo接口,可以获取用户更完整的信息。OIDC协议可以适用于各种类型的客户端(比如服务端应用,移动APP,JS应用),且完全兼容OAuth2.0。

主要术语:

  • EU:End User,一个人类用户。
  • RP:Relying Party,用来代指Oauth2.0中受信任的客户端,身份认证和授权信息的消费方。
  • OP:OpenID Provider,有能力提供EU认证的服务,用来为RP提供EU的身份认证信息。
  • ID Token:JWT格式的数据,包含EU的身份认证信息。
  • UserInfo EndPoint:用户信息接口,受Oauth2.0保护,RP使用Access Token访问时,返回授权用户的信息,必须使用https。

流程说明:

I,RP发送一个认证请求给OP。
II,OP对EU身份进行认证,然后提供授权。
III,OP把ID Token和Access Token返回给RP。
IV,RP使用Access Token访问UserInfo EndPoint。
V,UserInfo EndPoint返回EU的Claims。 

OIDC定义了三种认证方式

  • 授权码流程(Authorization Code Flow):基于OAuth2的授权码流程,在原来code换取Access token的基础上增加了一个Id token。
  • 隐式流程(Implicit Flow):基于OAuth2的简化流程,在原来从授权服务器重定向到第三方应用仅返回Access token的基础上增加了一个Id token。
  • 混合流程(Hybrid Flow):混合了授权码流程(Authorization Code Flow)和隐式流程(Implici Flow),能够按照参数配置的不同,控制Id token的返回位置与Access token的有无。

3.4、SAML协议

SAML(Security Assertion Markup Language)是一个基于XML的开源标准数据格式,它在当事方之间交换身份验证和授权数据,尤其是在身份提供者和服务提供者之间交换。SAML解决的最重要的需求是网页浏览器单点登录,SAML规范定义了三个角色:服务提供者(SP)、身份提供者(IDP)、用户(Client)。
SAML可用于安全身份认证和授权,主要用在Saas单点登录场景。
SAML1.0和SAML2.0并不兼容。
在用SAML解决的使用案例中,用户从服务提供者那里请求一项服务,服务提供者请求身份提供者并从那里获得一个身份断言,服务提供者基于这一断言判断用户是否有权执行这项服务。基本流程如下:

流程说明:  

1,Client去访问SP的某个受保护资源。
2,SP没有Client的认证信息,会生成一个SAML的认证请求数据包,并把这个数据包放在一个html的form中的隐藏域中,返回给Client。
3,这个form会自动把认证请求提交给事先配置好的IDP地址。
4,IDP也需要认证Client,于是返回给Client一个认证界面,可以是用户名密码认证,也可以是其它可行的方式。
5,Client提交认证信息给IDP。
6,IDP认证完成后,会为Client生成一些断言,包含Client的身份、权限等,签名后放在form中返回给Client。
7,包含断言数据的form自动提交到SP。
8,SP验证断言数据,得到Client的身份和权限,返回Client想要访问的资源。 

3.5、LDAP协议

轻型目录访问协议(Lightweight Directory Access Protocol)是一个开放的,中立的,工业标准的应用协议,通过IP协议提供访问控制和维护分布式信息的目录信息。LDAP的一个常用用途是单点登录,用户可以在多个服务中使用同一个密码,通常用于公司内部网站的登录中(这样他们可以在公司计算机上登录一次,便可以自动在公司内部网上登录)。

常见的LDAP实现:

  • openLDAP
  • Active Directory

 3.6、Radius

远程认证拨号用户服务(Remote Authentication Dial In User Service)由RFC2865,RFC2866定义,是应用最广泛的AAA协议。RADIUS是一种C/S结构的协议,它的客户端最初就是NAS(Net Access Server)服务器,任何运行RADIUS客户端软件的计算机都可以成为RADIUS的客户端。RADIUS协议认证机制灵活,可以采用PAP、CHAP或者Unix登录认证等多种方式。RADIUS是一种可扩展的协议,它进行的全部工作都是基于Attribute-Length-Value的向量进行的。RADIUS也支持厂商扩充厂家专有属性。

 

猜你喜欢

转载自blog.csdn.net/juanxiaseng0838/article/details/132691222