精华内容
下载资源
问答
  • 统一用户认证和单点登录和授权的原理与流程

    千次阅读 多人点赞 2019-02-02 13:58:09
    彻底搞懂统一用户认证和用户单点登录1. 前言2. 原理1. 统一用户认证介绍2. 单点登录原理介绍3. OAuth 2.0的统一用户认证1. OAuth 2.0协议和流程简介2. 授权码模式3. 简化模式4. 密码模式5. 客户端模式6. 授权码模式...

    1 前言

    随着信息技术和网络技术的迅猛发展,大型企业内部的应用系统越来越多。比如在电商行业,常见的应用系统就有商品系统、订单系统、支付系统、物流系统、客服系统等等。这些系统互相独立,且每个系统都需要识别用户的身份,并根据用户的身份来进行权限控制。如果每个系统都各自实现用户管理和认证的功能,就会带来用户信息冗余、不同步等问题,也会导致用户必须记住每一个系统的用户名和密码,从而给用户带来不少麻烦。针对这些实际情况,统一用户认证、单点登录、授权等概念应运而生,而且被广泛应用到企业应用系统中。

    本文主要介绍基于Spring Security + OAuth 2.0协议的统一用户认证、单点登录、授权的原理和流程。

    2 介绍

    2.1 统一用户认证

    统一用户认证,就是判断一个用户是否为合法用户的过程。一般来说,大型企业内部的每个应用系统都需要识别用户的身份,如果每个系统都各自实现用户管理和认证的功能,那么对于企业而言,必定会增加用户信息的管理成本,也会导致多个系统之间的用户信息冗余且不同步的问题,对于用户而言,必须记住每个系统的账户信息,从而带来不便。例如,用户同时使用某个大型企业内部的10个应用系统,就必须在这10个应用系统中都创建自己的账户并记住账户,这样每个系统都需要管理用户的信息,而且一旦用户在某个系统中修改了信息,就会导致系统之间用户信息不一致的问题。万一系统的数量增加到50个、100个了?估计企业和用户都要疯了。

    解决上述问题的根本方法是建立统一用户管理系统(UUMS)。UUMS统一存储、维护、管理所有应用系统的用户信息,所有系统的用户认证功能全部由UUMS来完成,而用户权限控制功能则由各个应用系统自己完成。可见、UUMS应具备以下基本功能:

    1. 统一用户管理:用户信息的存储、维护、管理等功能。
    2. 统一用户认证:用户身份识别、角色分配等功能。

    统一用户认证是以UUMS为基础,对所有的系统提供统一的认证方式和认证策略,以识别用户身份的合法性。

    注意:统一用户认证是为了解决多个系统的用户管理和认证的问题。

    2.2 单点登录

    对于大型企业内部的多个应用系统而言,统一用户管理系统能够很好的解决用户信息冗余和不同步的问题,也能减轻用户需要创建并管理多个账户的痛苦,即使这样也仍然存在多个系统都需要用户登录的问题。例如,用户同时使用某个大型企业内部的10个应用系统,那么就需要用户使用同一个账号信息去分别登录每个系统,这样的操作必定会导致用户体验太差。单点登录就是为了解决这个问题而提出的。

    单点登录(Single Sign On,简称SSO)是一种方便用户访问多个系统的技术,用户只需在一个系统中进行登录,就可以在多个系统间自由穿梭,不必重复输入用户名和密码来确定身份。

    注意:单点登录是为了解决同一用户在使用多个系统时的重复登录的问题。

    2.3 授权

    我们经常会遇到这样一个问题:在访问某些系统(例如知乎、豆瓣),都需要用户先注册账号,然后登录才能继续访问,而很多用户却又嫌注册太麻烦,为了方便用户使用,这些系统都会提供使用第三方账号(例如微信账号)进行登录的方式。那么问题来了,如果用户直接将自己的第三方账号和密码告诉这些系统,那么又怎样确保这些系统不会泄露用户的账号信息以及私自获取用户在第三方系统中除用户账户之外的数据?“授权”就能很好的解决这个问题。

    所谓“授权”,就是用户先授予某个系统可以使用自己的第三方账号信息的权利,然后该系统就可以使用用户的授权到第三方去获取该用户的账号信息,而第三方验证了用户的授权之后就按照用户授权的范围把用户允许的账号信息返回给该系统,而不会把用户没有允许的数据返回给该系统。这样一来,用户既可以访问这些系统,又不需要把自己的第三方账号信息告诉给这些系统,从而可以解决上述问题。

    注意:授权是为了解决多个系统之间用户信息共享的问题。

    3 原理

    3.1 统一用户认证原理

    统一用户认证的原理相对简单,基本都是判断当前正在操作的用户的账户是否存在且密码是否匹配。如果用户认证通过了,那么用户就可以使用预先设定的角色来进行操作了,至于该角色能够进行哪些操作,则由各个应用系统自己指定了。统一用户认证包括以下几种认证方式,这些认证方式采用模块化设计,可以根据需求而组合使用:

    1. 匿名认证方式:用户不需要任何认证,可以匿名的方式登录系统。
    2. 用户名/密码认证:这是最基本的认证方式。
    3. PKI/CI数字证书认证:通过数字证书的方式认证用户的身份。
    4. IP地址认证:用户只能用指定的IP地址或IP地址段访问系统。
    5. 时间段认证:用户只能在指定的时间段访问系统。
    6. 访问次数认证:累计用户的访问次数,使用户的访问次数在一定的范围之内才可以访问系统。

    Spring Security和Shiro是两种主流的统一用户认证框架。

    3.2 单点登录原理

    单点登录的原理就是:用户在使用多个应用系统时,当用户第一次访问任一应用系统时,会因为没有登录而被引导到用户认证系统中进行认证,如果认证通过,用户就会得到一个认证凭据——ticket,用户再访问其它应用系统时,就会带上这个ticket作为自己已认证的凭据,而其它应用系统校验ticket通过之后,用户就可以不需要再次认证就可以直接该其它应用系统了。

    要实现单点登录,需要以下主要功能:

    1. 所有的应用系统共享一个用户认证系统:统一的认证系统是单点登录的前提之一。
    2. 所有的应用系统能够识别和提取ticket信息:应用系统应该能对ticket进行识别和提取,从而判断当前用户是否已经认证,从而完成单点登录的功能。

    单点登录的实现方案较多,有Spring Security + OAuth方案、Spring Security + CAS方案、Shiro + CAS方案,但Spring Security + OAuth方案更常用,本文讲解的单点登录也是基于这种方案。

    3.3 OAuth授权原理

    OAuth是一种授权协议,OAuth协议区分以下四种角色:

    1. 资源拥有者:即用户
    2. 第三方应用:即客户端
    3. 认证服务器:即服务提供商专门用来处理用户统一认证的服务器
    4. 资源服务器:即服务提供商专门用来存放用户生成的资源的服务器。它与认证服务器,可以是同一台服务器,也可以是不同的服务器。

    OAuth 2.0支持四种授权模式:

    1. 授权码授权模式(Authorization Code Grant)
    2. 简化授权模式(Implicit Grant)
    3. 密码授权模式(Resource Owner Password Credentials Grant)
    4. 客户端凭证授权模式(Client Credentials Grant)

    4 OAuth 2.0的四种授权模式

    4.1 授权码授权模式流程(重点)

    授权码模式是最严格也是最重要的一种授权模式,其主要流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户访问某个应用系统的客户端
    2. 请求授权:客户端请求用户授权,允许自己获取和使用用户的特定信息数据
    3. 同意授权:用户同意授权给客户端
    4. 申请授权码:客户端使用用户的授权到服务提供商的认证服务器申请授权码
    5. 发放授权码:认证服务器校验客户端使用的用户授权,校验通过则向客户端发放授权码
    6. 申请令牌:客户端使用用户的授权到服务提供商的认证服务器申请令牌
    7. 发放令牌:认证服务器校验客户端使用的用户授权,校验通过则向客户端发放令牌
    8. 申请资源:客户端使用令牌到服务提供商的资源服务器申请用户的特定信息数据
    9. 发放资源:资源服务器校验客户端使用的令牌,校验通过则将用户指定的用户信息数据发送给客户端

    注意: 授权码授权模式既适用于同一企业的多个系统之间的授权,也适用于不同企业的多个系统之间的授权

    4.2 授权码授权模式详细示例

    这里以知乎客户端、微信认证服务器、微信资源服务器为例 ,这三个相互独立,其中认证服务器使用授权码模式对所有的微信用户进行认证,所有微信用户的数据全部保存在微信资源服务器中,而知乎客户端需要用户登录之后才能进行操作,那么用户使用微信授权知乎客户端进行操作的完整流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户在未登录知乎客户端的情况下,点击知乎客户端中的链接发送请求
    2. 请求授权:知乎客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向微信认证服务器进行认证并授权
    3. 同意授权:用户在微信认证服务器中输入微信账号信息进行认证,并进行授权
    4. 发放授权码:微信认证服务器验证用户微信账号的合法性和是否授权,如果用户账号合法且确定授权,则将授权码发送给知乎客户端
    5. 申请令牌:知乎客户端收到授权码后,使用收到的授权码到微信认证服务器换取令牌
    6. 发放令牌:微信认证服务器验证知乎客户端发送过来的授权码的正确性,如果通过,则将令牌发送给知乎客户端
    7. 申请资源:知乎客户端收到令牌后,使用收到的令牌到微信资源服务器获取用户微信账号的指定信息
    8. 发放资源:微信资源服务器验证知乎客户端发送过来的令牌的正确性,如果通过,则将用户微信账号的指定信息数据发送给知乎客户端
    9. 解析登录:知乎客户端收到用户微信账号的指定信息后解析并登录知乎客户端
    10. 展示数据:知乎客户端从知乎后台获取数据并展示给用户(这里涉及多步操作,省略)

    4.3 简化授权模式流程

    简化授权模式流程较授权码授权模式少了授权码这一环节,因此叫简化授权模式,其主要流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户访问某个应用系统的客户端
    2. 请求授权:客户端请求用户授权,允许自己获取和使用用户的特定信息数据
    3. 同意授权:用户同意授权给客户端
    4. 申请令牌:客户端使用用户的授权到服务提供商的认证服务器申请令牌
    5. 发放令牌:认证服务器校验客户端使用的用户授权,校验通过则向客户端发放令牌
    6. 申请资源:客户端使用令牌到服务提供商的资源服务器申请用户的特定信息数据
    7. 发放资源:资源服务器校验客户端使用的令牌,校验通过则将用户指定的用户信息数据发送给客户端

    注意: 简化授权模式既适用于同一企业的多个系统之间的授权,也适用于不同企业的多个系统之间的授权

    4.4 简化授权模式详细示例

    这里以知乎客户端、微信认证服务器、微信资源服务器为例 ,这三个相互独立,其中认证服务器使用简化模式对所有的微信用户进行认证,所有微信用户的数据全部保存在微信资源服务器中,而知乎客户端需要用户登录之后才能进行操作,那么用户使用微信授权知乎客户端进行操作的完整流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户在未登录知乎客户端的情况下,点击知乎客户端中的链接发送请求
    2. 请求授权:知乎客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向微信认证服务器进行认证并授权
    3. 同意授权:用户在微信认证服务器中输入微信账号信息进行认证,并进行授权
    4. 发放令牌:微信认证服务器验证用户微信账号的合法性和是否授权,如果用户账号合法且确定授权,则将令牌发送给知乎客户端
    5. 申请资源:知乎客户端收到令牌后,使用收到的令牌到微信资源服务器获取用户微信账号的指定信息
    6. 发放资源:微信资源服务器验证知乎客户端发送过来的令牌的正确性,如果通过,则将用户微信账号的指定信息数据发送给知乎客户端
    7. 解析登录:知乎客户端收到用户微信账号的指定信息后解析并登录知乎客户端
    8. 展示数据:知乎客户端从知乎后台获取数据并展示给用户(这里涉及多步操作,省略)

    4.5 密码授权模式流程

    密码授权模式要慎重使用,因为用户需要直接将账号和密码等敏感信息提供给客户端,除非客户端是整个系统的一部分,或者是值得信赖的第三方系统,才可以考虑这种授权方式。其主要流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户访问某个应用系统的客户端
    2. 要求登录:客户端要求用户登录
    3. 提供账户:用户向客户端提供账号和密码进行登录
    4. 申请令牌:客户端使用用户的账号和密码到服务提供商的认证服务器申请令牌
    5. 发放令牌:认证服务器校验客户端使用的用户授权,校验通过则向客户端发放令牌
    6. 申请资源:客户端使用令牌到服务提供商的资源服务器申请用户的特定信息数据
    7. 发放资源:资源服务器校验客户端使用的令牌,校验通过则将用户指定的用户信息数据发送给客户端

    注意: 密码授权模式主要适用于客户端属于系统的一部分的情况

    4.6 密码授权模式详细示例

    这里以新浪微博客户端、新浪微博认证服务器、新浪微博资源服务器为例 ,这三个共同组成新浪微博系统,其中认证服务器使用密码模式对所有的新浪微博用户进行认证,所有新浪微博用户的数据全部保存在新浪微博资源服务器中,而新浪微博客户端需要用户登录之后才能进行操作,那么用户使用新浪微博客户端进行操作的完整流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户在未登录新浪微博客户端的情况下,点击新浪微博客户端中的链接发送请求
    2. 请求登录:新浪微博客户端发现用户点击的是需要登录才能访问的链接,于是将用户导新浪微博客户端的登录页面进行登录
    3. 用户登录:用户在新浪微博客户端的登录页面输入新浪微博账号信息进行登录(登录成功即授权成功)
    4. 申请令牌:新浪微博客户端将用户输入的新浪微博账号信息发送到新浪微博认证服务器进行用户认证
    5. 发送令牌:新浪微博认证服务器验证新浪微博客户端发送过来的用户新浪微博账号的合法性,如果用户账号合法,则将令牌发送给新浪微博客户端
    6. 申请资源:新浪微博客户端收到令牌后,使用收到的令牌到新浪微博资源服务器获取用户新浪微博账号信息
    7. 发送资源:新浪微博资源服务器验证新浪微博客户端发送过来的令牌的正确性,如果通过,则将用户新浪微博账号信息数据发送给新浪微博客户端
    8. 解析登录:新浪微博客户端收到用户新浪微博账号信息后解析并登录新浪微博客户端
    9. 展示数据:新浪微博客户端从新浪微博资源服务器获取用户请求的数据并展示给用户(这里涉及多步操作,省略)

    4.7 客户端授权模式流程

    这种授权模式比较特殊,客户端不是以用户的名义向认证服务器申请令牌,而是以自己的名义向认证服务器申请令牌,因此,这种授权模式其它与用户没有任何关系。其主要流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户访问某个应用系统的客户端
    2. 申请令牌:客户端使用自己的名义到服务提供商的认证服务器申请令牌
    3. 发放令牌:认证服务器校验客户端是否是合法的指定客户端,校验通过则向客户端发放令牌
    4. 申请资源:客户端使用令牌到服务提供商的资源服务器申请数据资源
    5. 发放资源:资源服务器校验客户端使用的令牌,校验通过则将客户端申请的数据资源发送给客户端

    注意: 客户端授权模式主要适用于客户端和系统之间默认存在信任关系的情况

    4.8 客户端授权模式详细示例

    这里以市天气系统客户端、省天气系统认证服务器、省天气系统资源服务器为例 ,其中省天气系统认证服务器使用客户端模式对所有的市天气系统客户端进行认证,该省所有市的的天气数据全部保存在省天气系统资源服务器中,那么用户使用市天气系统客户端查看当市天气的完整流程如下图所示:
    在这里插入图片描述

    1. 用户请求:用户在市天气系统客户端中点击链接,请求查看当市天气
    2. 申请令牌:市天气系统客户端将自己的凭证发送给省天气系统认证服务器进行身份认证
    3. 发放令牌:省天气系统认证服务器验证市天气系统客户端发送过来的凭证的合法性,如果凭证合法,则将令牌发送给市天气系统客户端
    4. 申请资源:市天气系统客户端收到令牌后,使用收到的令牌到省天气系统资源服务器获取当市天气
    5. 发放资源:省天气系统资源服务器验证市天气系统客户端发送过来的令牌的正确性,如果通过,则将该市天气数据发送给市天气系统客户端
    6. 展示数据:市天气系统客户端将收到的数据展示给用户

    5 OAuth 2.0单点登录

    单点登录是指在使用多个系统时,只需一次登录就可以使用所有系统,可见,单点登录是针对多个系统而言的,而这多个系统,可能同属于某一个企业(或机构),也可能分别属于不同的企业(或机构),而从2.2小节可知,单点登录的前提是统一用户认证,因此,单点登录主要是结合授权码授权和简单授权这两模式使用。以下两个示例则以授权码授权模式展示两个系统的单点登录流程,多个系统的单点登录流程依此类推。

    5.1 同一企业内部多系统的单点登录示例

    这里以淘宝客户端、天猫客户端、阿里巴巴认证服务器、阿里巴巴资源服务器为例 ,这四个相互独立但同属于阿里巴巴集团,其中认证服务器使用授权码模式对所有的阿里巴巴用户进行认证,所有阿里巴巴用户的数据全部保存在阿里巴巴资源服务器中,而淘宝客户端和天猫客户端需要用户登录之后才能进行操作,那么阿里巴巴用户基于单点登录使用淘宝客户端和天猫客户端进行操作的完整流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户在未登录淘宝客户端的情况下,点击淘宝客户端中的链接发送请求
    2. 请求认证:淘宝客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向阿里巴巴认证服务器进行认证
    3. 用户认证:用户在阿里巴巴认证服务器中输入账号信息进行认证(认证通过即授权成功)
    4. 发放授权码:阿里巴巴认证服务器验证用户账号的合法性,如果账号合法,则将授权码发送给淘宝客户端
    5. 申请令牌:淘宝客户端收到授权码后,使用收到的授权码到阿里巴巴认证服务器换取令牌
    6. 发放令牌:阿里巴巴认证服务器验证淘宝客户端发送过来的授权码的正确性,如果通过,则将令牌发送给淘宝客户端
    7. 申请资源:淘宝客户端收到令牌后,使用收到的令牌到阿里巴巴资源服务器获取用户账号信息
    8. 发放资源:阿里巴巴资源服务器验证淘宝客户端发送过来的令牌的正确性,如果通过,则将用户账号信息数据发送给淘宝客户端
    9. 解析登录:淘宝客户端收到用户账号信息后解析并登录淘宝客户端
    10. 展示数据:淘宝客户端从阿里巴巴资源服务器获取用户请求所需要的数据并展示给用户(这里涉及多步操作,省略)
      ——————————————————————————————————————————————
    11. 用户访问:随后用户在未登录天猫客户端的情况下,点击天猫客户端中的链接发送请求
    12. 请求认证:天猫客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向阿里巴巴认证服务器进行认证
    13. 发放授权码:阿里巴巴认证服务器发现用户已经认证,因此直接将授权码发送给天猫客户端
    14. 申请令牌:天猫客户端收到授权码后,使用收到的授权码到阿里巴巴认证服务器换取令牌
    15. 发放令牌:阿里巴巴认证服务器验证天猫客户端发送过来的授权码的正确性,如果通过,则将令牌发送给天猫客户端
    16. 申请资源:天猫客户端收到令牌后,使用收到的令牌到阿时巴巴资源服务器获取用户账号信息
    17. 发放资源:阿里巴巴资源服务器验证天猫客户端发送过来的令牌的正确性,如果通过,则将用户账号信息数据发送给天猫客户端
    18. 解析登录:天猫客户端收到用户账号信息后解析并登录天猫客户端
    19. 展示数据:天猫客户端从阿里巴巴资源服务器获取用户请求所需要的数据并展示给用户

    5.2 不同企业之间多系统的单点登录示例

    这里以知乎客户端、豆瓣客户端、微信认证服务器、微信资源服务器为例 ,这四个相互独立,但分别属于三个企业,其中微信认证服务器使用授权码模式对所有的微信用户进行认证,所有微信用户的数据全部保存在微信资源服务器中,而知乎客户端和豆瓣客户端需要用户登录之后才能进行操作,那么微信用户基于单点登录使用知乎客户端和豆瓣客户端进行操作的完整流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户在未登录知乎客户端的情况下,点击知乎客户端中的链接发送请求
    2. 请求授权:知乎客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向微信认证服务器进行认证并授权
    3. 认证并授权:用户在微信认证服务器中输入微信账号信息进行认证,并进行授权
    4. 发放授权码:微信认证服务器验证用户微信账号的合法性和用户是否授权,如果账号合法且确定授权,则将授权码发送给知乎客户端
    5. 申请令牌:知乎客户端收到授权码后,使用收到的授权码到微信认证服务器换取令牌
    6. 发放令牌:微信认证服务器验证知乎客户端发送过来的授权码的正确性,如果通过,则将令牌发送给知乎客户端
    7. 申请资源:知乎客户端收到令牌后,使用收到的令牌到微信资源服务器获取用户微信账号的指定信息
    8. 发放资源:微信资源服务器验证知乎客户端发送过来的令牌的正确性,如果通过,则将用户微信账号的指定信息数据发送给知乎客户端
    9. 解析登录:知乎客户端收到用户微信账号的指定信息后解析并登录知乎客户端
    10. 展示数据:知乎客户端从知乎后台获取用户请求所需要的数据并展示给用户(这里涉及多步操作,省略)
      ——————————————————————————————————————————————
    11. 用户访问:随后用户在未登录豆瓣的情况下,点击豆瓣客户端中的链接发送请求
    12. 请求授权:豆瓣客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向微信认证服务器进行认证并授权
    13. 授权:此时用户在微信认证服务器中已经认证,因此,用户只需要进行授权
    14. 发放授权码:微信认证服务器验证用户是否授权,如果确定授权,则将授权码发送给豆瓣客户端
    15. 申请令牌:豆瓣客户端收到授权码后,使用收到的授权码到微信认证服务器换取令牌
    16. 发放令牌:微信认证服务器验证豆瓣客户端发送过来的授权码的正确性,如果通过,则将令牌发送给豆瓣客户端
    17. 申请资源:豆瓣客户端收到令牌后,使用收到的令牌到微信资源服务器获取用户微信账号的指定信息
    18. 发放资源:微信资源服务器验证豆瓣客户端发送过来的令牌的正确性,如果通过,则将用户微信账号的指定信息数据发送给豆瓣客户端
    19. 解析登录:豆瓣客户端收到用户微信账号的指定信息后解析并登录豆瓣客户端
    20. 展示数据:豆瓣客户端从豆瓣后台获取用户请求所需要的数据并展示给用户(这里涉及多步操作,省略)

    5.3 比较

    从上述两个单点登录的示例可以看出,同一企业内部多系统的单点登录与不同企业之间多系统的单点登录的流程基本相同,不同的是:同一企业内部多系统的单点登录流程中,只需要用户在首次使用系统时进行用户认证,且认证成功即默认为确定授权,而随后使用其它系统时都不需要再进行认证和授权;而不同企业内部多系统的单点登录流程中,用户在首次使用系统时不仅需要进行用户认证,还要进行授权,而随后使用其它系统时虽然不需要再进行认证,但仍需要再次授权。

    6 小结

    至此,用户统一认证、单点登录、授权的原理与详细流程就全部介绍完成,欢迎聪明的Java猿们留言补充讨论。

    如果觉得本文对您有帮助,请关注博主的微信公众号,会经常分享一些Java和大数据方面的技术案例!
    在这里插入图片描述

    展开全文
  • 统一用户认证和单点登录解决方案

    万次阅读 2016-10-15 14:57:51
     本文以某新闻单位多媒体数据库系统为例,提出建立企业用户认证中心,实现基于安全策略的统一用户管理、认证和单点登录,解决用户在同时使用多个应用系统时所遇到的重复登录问题。 随着信息技术和网络技术的迅猛...

    ■ 康威 李凯

    --------------------------------------------------------------------------------
     本文以某新闻单位多媒体数据库系统为例,提出建立企业用户认证中心,实现基于安全策略的统一用户管理、认证和单点登录,解决用户在同时使用多个应用系统时所遇到的重复登录问题。

    随着信息技术和网络技术的迅猛发展,企业内部的应用系统越来越多。比如在媒体行业,常见的应用系统就有采编系统、排版系统、印刷系统、广告管理系统、财务系统、办公自动化系统、决策支持系统、客户关系管理系统和网站发布系统等。由于这些系统互相独立,用户在使用每个应用系统之前都必须按照相应的系统身份进行登录,为此用户必须记住每一个系统的用户名和密码,这给用户带来了不少麻烦。特别是随着系统的增多,出错的可能性就会增加,受到非法截获和破坏的可能性也会增大,安全性就会相应降低。针对于这种情况,统一用户认证、单点登录等概念应运而生,同时不断地被应用到企业应用系统中。

    统一用户管理的基本原理

    一般来说,每个应用系统都拥有独立的用户信息管理功能,用户信息的格式、命名与存储方式也多种多样。当用户需要使用多个应用系统时就会带来用户信息同步问题。用户信息同步会增加系统的复杂性,增加管理的成本。

    例如,用户X需要同时使用A系统与B系统,就必须在A系统与B系统中都创建用户X,这样在A、B任一系统中用户X的信息更改后就必须同步至另一系统。如果用户X需要同时使用10个应用系统,用户信息在任何一个系统中做出更改后就必须同步至其他9个系统。用户同步时如果系统出现意外,还要保证数据的完整性,因而同步用户的程序可能会非常复杂。

    解决用户同步问题的根本办法是建立统一用户管理系统(UUMS)。UUMS统一存储所有应用系统的用户信息,应用系统对用户的相关操作全部通过UUMS完成,而授权等操作则由各应用系统完成,即统一存储、分布授权。UUMS应具备以下基本功能:

    1.用户信息规范命名、统一存储,用户ID全局惟一。用户ID犹如身份证,区分和标识了不同的个体。

    2.UUMS向各应用系统提供用户属性列表,如姓名、电话、地址、邮件等属性,各应用系统可以选择本系统所需要的部分或全部属性。

    3.应用系统对用户基本信息的增加、修改、删除和查询等请求由UUMS处理。

    4.应用系统保留用户管理功能,如用户分组、用户授权等功能。

    5.UUMS应具有完善的日志功能,详细记录各应用系统对UUMS的操作。

    统一用户认证是以UUMS为基础,对所有应用系统提供统一的认证方式和认证策略,以识别用户身份的合法性。统一用户认证应支持以下几种认证方式:

    1. 匿名认证方式: 用户不需要任何认证,可以匿名的方式登录系统。

    2. 用户名/密码认证: 这是最基本的认证方式。

    3. PKI/CA数字证书认证: 通过数字证书的方式认证用户的身份。

    4. IP地址认证: 用户只能从指定的IP地址或者IP地址段访问系统。

    5. 时间段认证: 用户只能在某个指定的时间段访问系统。

    6. 访问次数认证: 累计用户的访问次数,使用户的访问次数在一定的数值范围之内。

    以上认证方式应采用模块化设计,管理员可灵活地进行装载和卸载,同时还可按照用户的要求方便地扩展新的认证模块。

    认证策略是指认证方式通过与、或、非等逻辑关系组合后的认证方式。管理员可以根据认证策略对认证方式进行增、删或组合,以满足各种认证的要求。比如,某集团用户多人共用一个账户,用户通过用户名密码访问系统,访问必须限制在某个IP地址段上。该认证策略可表示为: 用户名/密码“与”IP地址认证。

    PKI/CA数字证书认证虽不常用,但却很有用,通常应用在安全级别要求较高的环境中。PKI(Public Key Infrastructure)即公钥基础设施是利用公钥理论和数字证书来确保系统信息安全的一种体系。

    在公钥体制中,密钥成对生成,每对密钥由一个公钥和一个私钥组成,公钥公布于众,私钥为所用者私有。发送者利用接收者的公钥发送信息,称为数字加密,接收者利用自己的私钥解密; 发送者利用自己的私钥发送信息,称为数字签名,接收者利用发送者的公钥解密。PKI通过使用数字加密和数字签名技术,保证了数据在传输过程中的机密性(不被非法授权者偷看)、完整性(不能被非法篡改)和有效性(数据不能被签发者否认)。

    数字证书有时被称为数字身份证,数字证书是一段包含用户身份信息、用户公钥信息以及身份验证机构数字签名的数据。身份验证机构的数字签名可以确保证书信息的真实性。

    完整的PKI系统应具有权威认证机构CA(Certificate Authority)、证书注册系统RA(Registration Authority)、密钥管理中心KMC(Key Manage Center)、证书发布查询系统和备份恢复系统。CA是PKI的核心,负责所有数字证书的签发和注销; RA接受用户的证书申请或证书注销、恢复等申请,并对其进行审核; KMC负责加密密钥的产生、存贮、管理、备份以及恢复; 证书发布查询系统通常采用OCSP(Online Certificate Status Protocol,在线证书状态协议)协议提供查询用户证书的服务,用来验证用户签名的合法性; 备份恢复系统负责数字证书、密钥和系统数据的备份与恢复。

    单点登录

    单点登录(SSO,Single Sign-on)是一种方便用户访问多个系统的技术,用户只需在登录时进行一次注册,就可以在多个系统间自由穿梭,不必重复输入用户名和密码来确定身份。单点登录的实质就是安全上下文(Security Context)或凭证(Credential)在多个应用系统之间的传递或共享。当用户登录系统时,客户端软件根据用户的凭证(例如用户名和密码)为用户建立一个安全上下文,安全上下文包含用于验证用户的安全信息,系统用这个安全上下文和安全策略来判断用户是否具有访问系统资源的权限。遗憾的是J2EE规范并没有规定安全上下文的格式,因此不能在不同厂商的J2EE产品之间传递安全上下文。
     
    目前业界已有很多产品支持SSO,如IBM的WebSphere和BEA的WebLogic,但各家SSO产品的实现方式也不尽相同。WebSphere通过Cookie记录认证信息,WebLogic则是通过Session共享认证信息。Cookie是一种客户端机制,它存储的内容主要包括: 名字、值、过期时间、路径和域,路径与域合在一起就构成了Cookie的作用范围,因此用Cookie方式可实现SSO,但域名必须相同; Session是一种服务器端机制,当客户端访问服务器时,服务器为客户端创建一个惟一的SessionID,以使在整个交互过程中始终保持状态,而交互的信息则可由应用自行指定,因此用Session方式实现SSO,不能在多个浏览器之间实现单点登录,但却可以跨域。

    实现SSO有无标准可寻?如何使业界产品之间、产品内部之间信息交互更标准、更安全呢?基于此目的,OASIS(结构化信息标准促进组织)提出了SAML解决方案(有关SAML的知识参看链接)。

    用户认证中心实际上就是将以上所有功能、所有概念形成一个整体,为企业提供一套完整的用户认证和单点登录解决方案。一个完整的用户认证中心应具备以下功能:

    1. 统一用户管理。实现用户信息的集中管理,并提供标准接口。

    2. 统一认证。用户认证是集中统一的,支持PKI、用户名/密码、B/S和C/S等多种身份认证方式

    3. 单点登录。支持不同域内多个应用系统间的单点登录。

    用户认证中心提供了统一认证的功能,那么用户认证中心如何提供统一授权的功能呢?这就是授权管理中,其中应用最多的就是PMI。

    PMI(Privilege Management Infrastructure,授权管理基础设施)的目标是向用户和应用程序提供授权管理服务,提供用户身份到应用授权的映射功能,提供与实际应用处理模式相对应的、与具体应用系统开发和管理无关的授权和访问控制机制,简化具体应用系统的开发与维护。PMI是属性证书(Attribute Certificate)、属性权威(Attribute Authority)、属性证书库等部件的集合体,用来实现权限和证书的产生、管理、存储、分发和撤销等功能。

    PMI以资源管理为核心,对资源的访问控制权统一交由授权机构统一处理,即由资源的所有者来进行访问控制。同公钥基础设施PKI相比,两者主要区别在于: PKI证明用户是谁,而PMI证明这个用户有什么权限,能干什么,而且PMI可以利用PKI为其提供身份认证。

    单点登录通用设计模型

    图2是统一用户认证和单点登录通用设计模型,它由以下产品组成:

    1. PKI体系: 包括CA服务器、RA服务器、KMC和OCSP服务器。

    2. AA管理服务器: 即认证(Authentication)和授权(Authorization)服务器,它为系统管理员提供用户信息、认证和授权的管理。

    3. UUMS模块: 为各应用系统提供UUMS接口。

    4. SSO: 包括SSO代理和SSO服务器。SSO代理部署在各应用系统的服务器端,负责截获客户端的SSO请求,并转发给SSO服务器,如果转发的是OCSP请求,则SSO服务器将其转发给OCSP服务器。在C/S方式中,SSO代理通常部署在客户端。

    5. PMI: 包括PMI代理和PMI服务器。PMI代理部署在各应用系统的服务器端,负责截获客户端的PMI请求,并转发给PMI服务器。

    6. LDAP服务器: 统一存储用户信息、证书和授权信息。

    为判断用户是否已经登录系统,SSO服务器需要存储一张用户会话(Session)表,以记录用户登录和登出的时间,SSO服务器通过检索会话表就能够知道用户的登录情况,该表通常存储在数据库中。AA系统提供了对会话的记录、监控和撤消等管理功能。为保证稳定与高效,SSO、PMI和OCSP可部署两套或多套应用,同时提供服务。

    链接

    SAML

    SAML(Security Assertion Markup Language,安全性断言标记语言)是一种基于XML的框架,主要用于在各安全系统之间交换认证、授权和属性信息,它的主要目标之一就是SSO。在SAML框架下,无论用户使用哪种信任机制,只要满足SAML的接口、信息交互定义和流程规范,相互之间都可以无缝集成。SAML规范的完整框架及有关信息交互格式与协议使得现有的各种身份鉴别机制(PKI、Kerberos和口令)、各种授权机制(基于属性证书的PMI、ACL、Kerberos的访问控制)通过使用统一接口实现跨信任域的互操作,便于分布式应用系统的信任和授权的统一管理。

    SAML并不是一项新技术。确切地说,它是一种语言,是一种XML描述,目的是允许不同安全系统产生的信息进行交换。SAML规范由以下部分组成:

    1. 断言与协议: 定义XML格式的断言的语法语义以及请求和响应协议。SMAL主要有三种断言: 身份认证断言、属性断言和访问授权断言。

    2. 绑定与配置文件: 从SAML请求和响应消息到底层通信协议如SOAP或SMTP的映射。

    3. 一致性规范: 一致性规范设置了一种基本标准,必须满足这一SAML标准的实现才能够称为一致性实现。这样有助于提高互操作性和兼容性。

    4. 安全和保密的问题: SAML体系结构中的安全风险,具体而言就是SAML如何应对这些风险以及无法解决的风险。

    要注意的是,SAML并不是专为SSO设计,但它却为SSO的标准化提供了可行的框架。


    ---

    (计算机世界报 2005年09月19日 第36期 C14、C15)

    原文:http://www.cnblogs.com/AndyZheng/articles/297704.html

    展开全文
  • 基于AD域实现单点登录设计文档 版本说明: 服务器类型: WinServer2016 Eclipse版本: Version: Luna Service Release 2 (4.4.2) Build id: 20150219-0600 Jdk...

    基于AD域实现单点登录设计文档

    版本说明:

    服务器类型:

    WinServer2016

    Eclipse版本:

    Version: Luna Service Release 2 (4.4.2)

    Build id: 20150219-0600

    Jdk版本:

    1.6

    客户端:

    Win10

     

    • 在WinServer2016服务器中搭建AD域:
    1. 左键单击桌面左下角开始菜单,在弹出窗口中选择服务器管理器并双击;如下图1:

     

                           图1

    2.进入服务器管理器仪表板页面,通过服务器管理器中添加角色,进行域服务角色安装。(注: winserver2012后已经不能使用命令行dcpromo进入域安装向导)如图2:

    图 2

    3.选择基于角色或基于功能的安装点击下一步:如图3

    图3

    4.选择本地服务器“WIN-MNCQVTCS7MF…”。下一步:图4

    图4

    5.选择“Active Directory” 域服务,点击下一步。图5、图5.1:

    图5

    图5.1

     

    6.默认选项下一步:图6

                图 6

    7.默认选项“下一步”图7:

     

             图 7

    8.选择“如果需要,自动重新启动目标服务器”。按“安装”。(备注:指定备用源路径,指向windows server 2016 安装盘)图8:

                  图 8

    9.安装完成。按“关闭” 图 9:

     

                   图 9

    10.选择服务器任务详细信息,选择“部署后配置”按:将此服务器提升为域控制器。 图10:

                                           图10

    11.选择“添加新林”,填写根域名:RBJF.COM.  如图11:

                                    图 11

     

     

     

     

    12.选择林和域功能级别是 Windows server 2016,提供域控制器功能,选择“域名系统(DNS)服务器”。默认是选“全局目录”。并设置活动目录还原密码。如图12

                                   图12

    13.默认选择下一步:如图13:

                                    图13

    14.默认显示NetBIOS是 MCITP 图14

                              图14

    15.默认选择下一步: 如图15:

                       图15

    16.显示安装信息如下: 图16

                                   图 16

    17.查看导出安装AD脚本

                     图17

     

    18.选择“安装” 图18

                                  图18

    19.安装过程会自动重启:图19

                              图19

     

    20.安装好后 使用域系统管理员登录 图20

                                      图20

    21.登录后进入开始菜单。 图21

                                      图21

     

     

     

    22.(在仪表板工具菜单下)通过Active Directory域和信任关系,查看操作主机信息 如图22

                                 图22

    23.Active Directory站点和服务查看站点信息。现默认站点只有一台域控服务器。 图23、

                             图23

    24.Active Directory 用户和计算机中新建OU (组),取名“OA” 如图24:

                                 图24.1

                               图24.2

    25.Active Directory 用户和计算机在IT ou中新建用户“JACK”。如图25

    图25.1

                                 图25.2

                                图25.3

                             图25.4

    26.赋予用户权限 图26

                      图26.1

     

                                          图26.2

                          图26.3

                                       图26.4

    选择相应的该用户应赋予权限即可;

     

    至此AD域服务器端搭建 完成!!!

     

     

    • 客户端连接到AD域:

    Win10下有两种方式连接到AD域:

    方法1:

     

     

     

     

     

     

    方法2:(仅限win10):

     

     

     

     

     

     

     

    如果重启后以域用户身份登录后在属性中查看到了计算机域信息并且显示登录用户为域用户则说明登录域操作成功了:如下图:

     

     

     

     

     

    三.JAVA WEB 通过AD域实现单点登录;

    条件:AD域用户名与JAVAWEB OA系统的用户名保持一致

    1. 获取通过AD域访问OA系统的客户端域信息

    工具:jar包 jcifs-1.3.15.jar

    https://download.csdn.net/download/luo201227/7739823

     

    方法:1.将jcifs-1.3.15.jar 包放在javaWEB目录的WEBINF目录下的lib目录中;

    1. 向web.xml文件中添加过滤器 内容为:

    <filter>
    <filter-name>NtlmHttpFilter</filter-name>
    <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
    <init-param>
    <param-name>jcifs.http.domainController</param-name>
    <param-value>192.168.0.90</param-value>
    </init-param>
    </filter>
    <filter-mapping>
    <filter-name>NtlmHttpFilter</filter-name>
    <url-pattern>/*</url-pattern>
    </filter-mapping>

    192.168.0.90是你AD服务器,然后在你的登陆的代码中使用
    request.getRemoteUser(),就可以得到当前域用户的用户名了

    添加好后将新添jar包引入并重启工程,再在AD域登录指向的Action类中获取客户端的域信息 参考代码:

    //取到客户端域名及客户名

        String domainuser = req.getRemoteUser();

        System.out.println(domainuser);

        String user = domainuser.substring(domainuser.indexOf("\\")+1);

        String ADdomain = domainuser.substring(0, domainuser.indexOf("\\"));

        System.out.println(user+"##"+ADdomain);

    至此单点登录核心功能已经实现完成。剩下的模拟账号密码登录过程不做陈述

    2可能遇到的问题解决办法:

     

    原因分析:因JCIFSHttpFilter并不支持NTLM2协议,而当客户端是WIN7系统时,默认采用的是NTLM2协议。如果此时域控服务器也支持NTLM2,则会默认采用NTLM2协议验证。就会出现该异常了。

    解决办法:将客户端的默认协议改为NTLM协议

    步骤:单击”开始“-“运行”,输入secpol.msc,打开“本地安全策略”,在本地安全策略窗口中依次打开“本地策略”-->“安全选项”,然后再右侧的列表中找到“网络安全:LAN
    管理器身份验证级别”,把这个选项的值改为“发送 LM 和 NTLM 
    报错解决办法

     

     

     

                                                      2016年11月15日第一版

                                                      ----------------------作者:岳利

    包含winserver2016环境搭建  exchange2013邮箱服务器集成 AD域用户权限分配 单点登录实现

    详细信息 请去我的网盘下载 地址:

    https://pan.baidu.com/s/1sm0IbUX

     

    展开全文
  • 单点登录 - SSO 现阶段互联网中拥有着大量的应用系统,极大地提升了大家的工作效率与生活质量。然而大量的应用系统拥有着不同的认证与授权模式,这使得用户需要大量记忆用户名与口令,并多次登录和注册所需要使用...

    单点登录 - SSO

         现阶段互联网中拥有着大量的应用系统,极大地提升了大家的工作效率与生活质量。然而大量的应用系统拥有着不同的认证与授权模式,这使得用户需要大量记忆用户名与口令,并多次登录和注册所需要使用的系统,这使得用户的使用体验非常的糟糕。因此,单点登录系统(SSO,Single Sign-On)应运而生。

    单点登录 - SSO
    单点登录 - SSO

     

    常见的应用有两种情况:

    • 在一个单位中,需要使用多个功能不同的系统应用,比如企业会有专门的财务系统,销售的CRM系统,人事的OA、邮箱系统,如果每个系统都用独立的账号认证体系,会给员工带来很大困扰,同时不方便管理。所以需要设计一种统一登录的解决方案。
    • 现在是App爆炸的时代,如果每个App都需要独立的登陆账号和密码,肯定不方便用户管理,所以需要设计一种可多平台授权登陆的解决方法,比如:我登陆淘宝时使用支付宝授权认证登陆,使用微博时使用微信授权登陆。

    SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。今天软盟网小编就上述的两种情况跟大家一起探索当中的流程区别和应用实践。

     

    OAuth2.0

    OAuth 2.0是一个关于授权的开放网络协议,它允许用户让第三方网站访问该用户在某一网站上存储的信息和资源,如账户信息,照片,联系人等,而不需要给第三方网站提供某一网站上的账户和密码。

    OAuth2.0
    OAuth2.0

    OAuth授权流程如下所述:

    1、用户打开客户端,客户端要求授权。

    2、用户同意客户端授权。

    3、客户端使用上一步提供的授权,向服务器授权层申请令牌。

    4、授权服务器对客户端进行认证后,同意发放令牌。

    5、客户端使用令牌,向资源服务器申请资源。

    6、资源服务器确认令牌,向客户端开放资源。

    OAuth 场景说明:

    比如小编之前在碎片时间多是使用头条来获取最新的信息资讯,最近了解抖音很火,就下载了抖音,选择登录注册页面时可以使用头条作为登录的授权

    5分钟明了单点登录SSO、OAuth、LDAP、CAS的流程与应用
    5分钟明了单点登录SSO、OAuth、LDAP、CAS的流程与应用

     

    多平台登录多用于多个合作企业间通过互联网相互协助验证用户的身份,电商网站广泛使用社交网站的账号进行多平台登录,可以起到客户引流、降低首次购买门槛、营销跟踪等效果。

    LDAP

    LDAP是一种基于轻量目录访问协议,全称是Lightweight Directory Access Protocol,是由一个为查询、浏览和搜索而优化的数据库构成,它成树状结构组织数据,类似文件目录一样。

    LDAP单点登录认证主要是改变原有的认证策略,使得需要的软件都通过LDAP服务器进行认证,在统一身份认证后,用户的所有信息都存储在AD Server中,终端用户在需要使用公司内部服务的时候,都需要通过AD服务器进行认证。

    整个LDAP登录流程由以下4个步骤组成:

    1、连接到LDAP服务器。

    2、绑定到LDAP服务器。

    3、在LDAP服务器上执行所需要的操作。

    4、释放LDAP服务器的连接。

    LDAP场景说明:

    企业内部需要认证的服务很多,员工需要记住很多的密码, 即使对这些服务进行相同的密码设置,也存在很大的安全隐患。比如我们公司,有jira、confulence、gitlab、北森等系统,

    5分钟明了单点登录SSO、OAuth、LDAP、CAS的流程与应用
    5分钟明了单点登录SSO、OAuth、LDAP、CAS的流程与应用

    使用场景是提高用户在同一个企业的多个站点(域名)之间的无缝浏览体验,例如企业内部可能有多个处理不同业务的系统(OA系统,邮箱,财务等),用户只要在一个系统上保持登录状态,即可无需再次登录访问其他内部系统。

    CAS

    SSO 仅仅是一种架构,一种设计,而 CAS 则是实现 SSO 的一种手段。两者是抽象与具体的关系。

    CAS即Central Authentication Service模型(中央式认证服务),该协议是为应用提供可信身份认证的单点登录系统,最初是由耶鲁大学开发的。CAS 包含两个部分: CAS Server 和 CAS Client。CAS Server 需要独立部署,主要负责对用户的认证工作;CAS Client 负责处理对客户端受保护资源的访问请求,需要登录时,重定向到 CAS Server。

    CAS
    CAS

    CAS的详细流程如图所示:

    CAS的详细流程
    CAS的详细流程

     

    总结

    今天介绍的几种单点登录系统,均具有较高的安全性,都能较好地完成单点登录系统的需求。

    • OAuth协议能广泛应用于互联网中,基于大企业的巨大用户量,能减少小网站的注册推广成本,并且能做到更加便捷的资源共享。
    • LDAP协议适用于企业用户使用,通过LDAP协议,能较好地管理员工在公司各系统之间的授权与访问。
    • CAS模型,作为权威机构开发的系统,具有很好的兼容性与安全性,广泛应用于各大高校等大型组织,能很好地完成大量系统的对接与大量人员的使用。

    可根据自身需求,选择不同的单点登录系统,来满足目标用户的使用。

    来自:网络。整理:www.ruanally.com

    展开全文
  • 分布式系统应对单点故障策略选择 一,引入 在现在的网络大环境下,越来越大的信息量导致了web应用系统一步步的进行变革。如下图,应用架构经历了四次大的改变:从 单一应用架构 到 垂直应用架构 再到 分布式服务...
  • 【简介】单点登录SSO(Single Sign-On)是身份管理中的一部分。SSO的一种较为通俗的定义是:SSO是指访问同一服务器不同应用中的受保护资源的同一用户,只需要登录一次,即通过一个应用中的安全验证后,再访问其他...
  • 面试:第十章:单点登录

    千次阅读 2019-03-21 07:30:43
    单点登录业务介绍 早期单一服务器,用户认证 缺点:单点性能压力,无法扩展 WEB应用集群,session共享模式 解决了单点性能瓶颈。 问题: 多业务分布式数据独立管理,不适合统一维护一份session数据。 ...
  • CAS单点登录-客户端集成(shiro、springboot、jwt)(十) 由于我们通常在业务上会有以下的使用场景: 移动端通过业务系统鉴权 移动端免登录登录一次以后) 解决方案: JWT(token认证方案) OAuth(第三方认证) PS:...
  • 单点登录设计原理

    千次阅读 2007-09-30 11:28:00
    本文以某新闻单位多媒体数据库系统为例,提出建立企业用户认证中心,实现基于安全策略的统一用户管理、认证和单点登录,解决用户在同时使用多个应用系统时所遇到的重复登录问题。 随着信息技术和网络技术的迅猛发展...
  • 浅析Web单点登录和SAML技术

    千次阅读 2010-09-26 13:34:00
    SAML连同Web单点登录共同构成了现代网络环境中的必备条件。  美国在线和eBay是两个知名网站,拥有大量的用户。通过分析,这两个网站发现他们有30%的用户是重合的,也就是说,这些用户在两个网站都有用户名和...
  • 使用cookie实现跨域系统单点登录

    万次阅读 2016-04-18 15:30:01
    上一篇博客介绍了单点登录的认证流程和实现,本文将介绍通过cookie实现单点登录。   单点登录作为目前比较流行的服务于企业业务整合的解决方案之一, 使得在多个应用系统中,用户只需要 登录一次 就可以访问...
  • CAS实现SSO单点登录原理

    万次阅读 多人点赞 2016-03-30 13:24:30
    CAS(Central Authentication Service) 是 Yale大学发起的一个企业级的、开源的项目,旨在为 Web 应用系统提供一种可靠的单点登录解决方法(属于Web SSO)。 CAS开始于2001年, 并在 2004年 12月正式成为JA-SIG的...
  • 然后在下一篇文章开始,我们将实际操作,实现单点登录功能。 身份标识的挑战 在上一篇文章也提及到了,大部分的开发人员并不是安全方面的专家,很多人对于身份验证,授权以及用户体验个性化等工作感觉非常...
  • 单点登录SSO技术资料收集

    千次阅读 2006-11-30 22:46:00
    本文以某新闻单位多媒体数据库系统为例,提出建立企业用户认证中心,实现基于安全策略的统一用户管理、认证和单点登录,解决用户在同时使用多个应用系统时所遇到的重复登录问题。 随着信息技术和网络技术的迅猛发展...
  • 线路交换 1、线路交换进行通信:是指在两个站之间有一个实际的物理连接,这种连接是...为连接提供的数据速率是固定的,因而连接起来的两个设备必须用相同的数据率发送和接收数据,这就限制了网络上各种主机以及终端...
  • 门户单点登录实现与应用集成技术

    千次阅读 2014-12-25 09:43:45
    WebSphere Portal 实现单点登录以应用集成技术规范,更好的满足客户的门户业务需求 随着企业门户平台的“平民化”,越来越多的工程师加入到门户项目实施的行列,但由于对门户技术的了解、使用的深度不同,...
  • BOS_V6.3_BOS实施指南_单点登录(V2.0版)

    千次阅读 2012-11-12 09:08:10
     本指南共分为六个章节,第一章介绍了单点登录的概念和作用,以及EAS支持的单点登录集成方案;第二章分析了单点登录的需求分析和实施过程;第三章分析了EAS单点登录各集成方案的具体实施和配置步骤;第四章介绍了...
  • 本文以某新闻单位多媒体数据库系统为例,提出建立企业用户认证中心,实现基于安全策略的统一用户管理、认证和单点登录,解决用户在同时使用多个应用系统时所遇到的重复登录问题。 随着信息技术和网络技术的迅猛...
  • java单点登录在校园身份管理系统中的实现摘要: 一个学校或企业的内部有很多信息系统,用户登录这些系统时需要进行身份认证。传统的认证机制是基于用户名和密码的,每一个系统都建立有自己的用户信息数据库,用来验证...
  • 提纲 动态缓存技术 集群与负载均衡 网罗天下实现策略 ...通过一定的替换和更新策略保证用户访问到最新的内容,对提高Web服务器峰值负载下的运行能力,减少访问动态内容的延迟时间起到优化作
  •  服务器web应用中,session信息只需存在该服务器中,这是我们前几年最常接触的方式,但是近几年随着分布式系统的流行,系统已经不能满足日益增长的百万级用户的需求,集群方式部署服务器已在很多公司运用起来,...
  • 单点登陆

    千次阅读 2011-06-16 16:26:00
    1. 单点登录简介1.1CAS简介CAS 是 Yale (耶鲁)大学发起的一个开源项目,旨在为 Web 应用系统提供一种可靠的单点登录方法,CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。http://www.jasig.org/cas CAS 具有...
  • 单点登录架构集成在一起的。 Kerberos 的 KDC ( Key Distribution Center )跟 Windows Server 2003 的域控制器 DC ( domain controller )上的安全服务集成在一起, KDC 使用域的活动目录数据库作为它的...
  • 如果想很好地理解下面的故事,请参看我半年前写的两篇博文:android中图片的三级cache策略(内存、文件、网络) 一 和 android中左右滑屏的实现(广告位banner组件)。当时没有发上来是由于如下几原因:首先...
  • redis集群解决单点故障

    千次阅读 2018-12-17 21:58:23
    Redis集群: 解决单点故障问题 设置主从 主机:master 不需要添加特殊配置 redis-server redis.conf 从机: slaver slaveof 主机的地址 连接的端口号,例如slaveof 127.0.0.1 6379 如果主从在同一个...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 263,698
精华内容 105,479
关键字:

单点登录网络策略