ldap 单点登录 ldap统一用户认证和单点登录

谈谈单点登录

寒学习的小课题，把之前的笔记整理整理记录一下（长文）因为当时看到的东西涉及很多，所以有一些地方没有深入去探讨。

ldap 单点登录 ldap统一用户认证和单点登录

ldap 单点登录 ldap统一用户认证和单点登录

ldap 单点登录 ldap统一用户认证和单点登录

百度百科：单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

简而言之就是用户在多个相互信任的应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。这里的关键是一次登录，以及一次退出，都对所有的系统生效。

在普通的登录中，比如典型的B/S情景，浏览器访问，发送登录请求，在发送完用户名和密码之后，会生成该用户的session来标准该用户的状态，比如已登录还是已注销，并给一个cookie给浏览器，因此，用户继续访问就会带上这个cookies，服务端会根据这个Cookie找到对应的session，通过session来判断这个用户的登录状态。比如php中使用phpsessid。当然也可以自定义session的生命周期，session的生命周期过长的话一旦session被盗用就会出现用户被窃取的情况。同时，生命周期过长的session配置会占用较多的资源。

单点登录主要针对同平台下多应用，多系统的情景下多次登录的一种解决方案。单点登录相当于将多个应用的认证体系联通。

设现在一个平台上有3个都带有登录功能的应用，由上面的普通登录的情况可以想到，这3台都会自己的记录session。那么要想达到单点登录，一个最简单的方法就出现了：共享session。

共享session的方式来实现单点登录是最方便也是最直接的。在三个子系统中，使用同一个额外的记录session的，比如我们可以使用一个redis来存储三个系统的session。

用户登录了应用1，获取了应用1返回的cookies，再次访问应用1的其他功能的候携带了cookie就是已登录的状态了，但是这样又有新的问题，虽然实现了共享session，但是用户登录了应用1，获取了应用1返回的cookie，但是因为cookie是无法跨域的，因此用户无法使用应用1的cookie去访问应用2。这里我们就需要将系统的全局cookie domain的属性设置为域名，比如应用1的域名是，应用2的域名是。在普通登录的情况下，应用1的cookie domain的属性是，指这个cookie只能在该子域名上被使用。我们将系统的全局cookie domain设置为域名，即，这样就可以实现用户登录了应用1，之后可以以已登录状态访问应用2和3。

上面的共享session的情况是三个应用都有登录功能，还有一种类似的情况是应用1和应用2都有登录模块和其他模块，还有一个单独的SSO系统，是登录模块的：

共享session的方法虽然简单，但是存在局限性，因为使用了cookie顶域的特性，所以不能做到跨域。一个公司或者一个平台很可能不是所有的域名都在在一个一级域名之下的，所以同域名下的单点登录并不是完整的单点登录。

先说说openid，openid是一种认证标准，规定如何认证的标准！即其关注的是登录时身份的认证。给出的一个场景，其中一方是一个openid身份，用来存放注册好的openid账号，另一方是受这个openid身份信赖的服务或应用。openid协议就是提供openid身份和被信赖的服务或应用之间的通信的。比如我们在很多网站上可以使用QQ登录，这里的腾讯的QQ就是openid的身份，我们所要登录的网站就是受信赖的服务或应用。

在使用openid实现单点登录的方法有很多，可以使用上面共享session的方法，即把openid带在cookie里面，但是这样也会出现一样的cookie跨域的问题。

在实际场景中，我们在访问提供服务的应用时检测到未登录就会直接跳转到openid身份，或者没有重定向而是在登录表单附近点击选择使用第三方openid登录，进行账号密码登录（这可以保证我们所登录的无法获取我们的敏感身份认证信息），具体流程如下：

CAS全称为Central Authentication Serv即认证服务，是一个企业多语言单点登录的解决方案，并努力去成为一个身份验证和授权需求的综合平台。CAS就是一个现成的单点登录的demo，企业只需要简单修改就可使用。

CAS支持各种协议，SAML，OAuth，OpenID，OIDC等等，支持LDAP，Radius，JWTX，509等等进行身份认证和授权，还有各种常用语言的客户端，Ja，PHP，C# 等等。反正就是一个十分完整的，兼容性特别好的SSO框架。

简单了解CAS是如何实现单点登录的。在上可以看到其给出的一个 流程图 ，。这个图说的特别详细，一下就能看懂，直接原图上进行标注查看：

学习了上面几种单点登录的知识，结合实际场景可知，跨域单点登录才是真正的单点登录，因为实际情况下很多平台或者域名不可能都在一个一级域名下。在解决跨域单点登录的问题的时候，上面也给说了几种方式，但是究其根本，就是利用一个SSO认证中心来实现认证与授权的。当然，也会有其他的解决跨域单点登录的方案，但是大体流程都与cas类似。

比如在上图的11步骤，也可使用POST包，或者JSONP和iframe方法来跨域发送请求进行重定向。

在利用认证中心来实现单点登录是现在比较普遍的解决方案，那么有没有不需要使用认证中心来解决跨域单点登录的方案呢？

利用JSONP同步登录状态，大概流程流程如下：

在学习单点登录的过程中，在其中认证的过程中授权令牌的传递等相关信息没有特别详细的说明，而且在思考单点登录的时候也会有想过一个比较矛盾的问题：单点登录的目标是为了让用户可以在相互信任的系统中一次登录即可，但是如果真的是做到所有用户都可以访问所有系统，岂不是会带来越权的问题，是否需要对不同的用户以不同的授权，甚至限制访问的应用，但是这样是不是就不是原本狭义的单点认证？

在说单点登录的认证和授权之前，先谈一谈我一直想弄清楚的统一身份认证和单点登录的区别。说起单点登录可能很少听过，但是统一身份认证肯定不陌生，不管是企业还是高校都会有这种统一身份认证的系统。

统一身份认证最重要的一方面就是身份认证，另一方面就是和身份认证相关的授权控制，权限控制。而单点登录是多应用一次登录，也可以叫统一登录，可以理解为主要在认证方面。对于统一身份认证来说会有账号管理，如LDAP，认证管理OAuth，SMAL等，因此我觉得，统一身份认证一般是包括狭义的单点登录，狭义的单点登录，即只需要满足多应用一次登录即可。但是现在的单点登录，SSO系统并不仅仅是要求这些，他的范围正在慢慢扩大。

单点登录的认证和授权，前面说到的CAS实现单点登录里就会看到需要ticket来进行认证，授权。CAS支持多种认证方案，比如OAuth，OpenID，SAML等等，我们可以来比较比较用这些协议的区别，或者说是在哪些场景下使用哪些认证方案较为合适。本身单点登录是没有权限控制的功能的，但是因为这些认证协议的需求，自然支持了权限控制。

在使用SAML进行认证的过程中，可以看到下图，其是基本流程都不多，这里需要注意的就是在用户在认证中心成功登陆之后，重定向的时候返回的是一个SAML token，一个XML，这里的token会包括用户的身份信息，用户名等。

在OAuth2.0的标准中流程是和上面的基本相同，但是OAuth2因为客户端并没有一点是浏览器，所以token中默认是没有签名的。这里可能没有体现出来，OAuth2的目标是授权，所以token更关注的是权限，token在向认证验证的时候就会有不同的授权，但是既然是授权，就间接实现了认证。

在传统的认证中都是基于session机制的，具体的session模式上面也说了，根据其特性可知session的一些确定：

门户中如何实现单点登录和统一身份认证？

本案涉及三个概念及功能模块，即门户、单点登录和统一身份认证。

单点登录(Single

Sign-On，缩写为SSO)，它是目前业务整合时使用较多的一种解决方案，通过SSO，用户只需要在某个应用系统入口登录一次，就可以访问所有与该应用系统相互信任的其它应用系统。

目前成熟的SSO实现框架有很多，开源的有JOSSO、CAS等很多，你可以选择其中之一与门户集成即可，集成方法的问题可在选型后在网络中查找，可选方案请参考《Liferay

集成

CAS

实现单点登录与应用系统集成》

所谓身份认证，就是判断一个用户是否为合法用户的处理过程。最常用的简单身份认证方式是系统通过核对用户输入的用户名和口令，看其是否与系统中存储的该用户的用户名和口令一致，来判断用户身份是否正确。复杂一些的身份认证方式采用一些较复杂的加密算法与协议，需要用户出示更多的信息(如私钥)来证明自己的身份，如Kerberos身份认证系统。

目前基于SOA架构，可跨平台与多种类型的应用系统对接的统一身份认证平台也有很多，

身份存储方式有：通用关系型数据库、LDAP目录、Microsoft

Active

Directory(AD)等形式，可选方案可参考《Web

Serv

Case

Study:

统一身份认证服务》

或《Liferay与CAS及LDAP》

有人用python写过ldap的登录和修改密码吗

你说的是AD域账号吧？先安装lpda3的库

在cmd命令行下运行：

pin install ldap3

然后开始写python脚本

fromldap3import

user="CN=visitor02 ,OU=ll1,DC=hello,DC=com,DC=cn" # 定义你要给谁改密码

admin='xxxxxx' #xxxx换成你域控的账号如helloadministrator, hello是域名

adminpwd = 'xxxx' #域控的密码

s=('10.10.xx.xx',get_=ALL,use_ssl=True) #10.10.xx.xx换成你域控的IP地址，这条是定义域信息

c=Connection(s,user=admin,password=adminpwd,auto_bind=True) #登录域

print(c.extend.microsoft.modify_password(user,"123456")) #这行就是改密码。如果print出true,就是成功了。如果false,再在下面加一条

print(c.response) #会显示为什么失败。

如果想了解更多的python ldap3库，可以看这个链接网页链接

上网行为管理设备没有身份认证的功能

用户身份认证有两种方式：客户端认证和免客户端认证。

1、上网行为管理设备支持免客户端的WEB认证，即通过浏览器就可以完成全部的认证。

2、上网行为管理设备支持丰富的身份认证方式：本地认证：用户名/密码认证；第三方认证：LDAP、AD域、Radius、POP3、微信认证、短信、SMP等；免认证：IP免认证、MAC免认证、ip-mac绑定免认证；单点登录：AD SSO、PPPoE SSO、Radius SSO、WEB SSO、PROXY SSO、城市热点SSO、H3C IMC SSO等；

强制认证：强制指定IP段的用户必须使用单点登录（如必须登录AD域），否则无法接入互联网；

3、上网行为管理设备也支持多种认证方式的混合使用，可为不同的用户配置不同的认证方式，实现用户的异化管理。比如，一部分用户使用本地认证、一部分用户结合LDAP认证，一部分用户不需要进行身份认证。

Jira中如何搭建ldap服务？

JIRA与LDAP集成的工作机制是这样的：

1. 用户信息依旧需要在JIRA中进行管理

2. 只有密码验证在LDAP中完成

3. 在LDAP中不存在的用户依旧可以通过JIRA本身的密码验证机制(OSUser)来进行身份校验

4. 并非全部的LDAP用户都具有JIRA访问权限

配置JIRA与LDAP集成的方法是(以JIRA 4.2.1为例)：

1. 进入Admin(管理) -> System(系统) -> LDAP

2. 在LDAP Host(LDAP主机)中填入LDAP地址

3. 在BaseDN中填入LDAP的根名称

4. 在Search Attribute中填入LDAP中包含JIRA登录用户名的属性名称

5. 保存LDAP的修改

6. 进入Admin(管理) -> General Configuration(通用设置)

7. 打开External Password Mament(外部密码管理)

8. 保存退出并重启服务

除了可以利用JIRA现有的LDAP集成机制外，也可以考虑Atlassian Crowd这款的单点登录工具，Crowd和JIRA的结合非常好。JIRA的用户可完全在Crowd中进行管理。Crowd支持LDAP,Windows Active Directory等多种目录，应用程序上支持JIRA、Confluence、FishEye、Crucible、GoogleApp、SVN等应用。可实现一个账户访问全部应用，并支持单点登录。

单点登录：公司已经有了AD/open ldap/某个认证源，为什么还需要玉符？

玉符能支持各类应用不受限制。

这些老旧的方案的问题就是适配性2，比如AD是一款20年前的老旧产品，根本无法和云端应用进行对接，又比如Open LDAP/某认证源，往往只能支持saml协议，但国内应用的接口五花八门，如果强行打通，就需要大量的接口二开工资，费用高时间长，而玉符SSO支持市面所有标准协议，也能提供超轻量级SDK给无接口应用，保证客户基本无需改造和二开，就能实现对各类云端和本地部署应用的单点登录。