Kerberos身份认证方案

Kerberos身份认证方案

5.1 身份认证概述

Kerberos是IETF发布的一种身份认证标准协议（目前最新版本为V5）。它采用对称密钥方案，也可以说是后面出现的非对称密钥方案的基础。Kerberos协议应用非常广泛，特别是在Windows系统中（包括在Windows系统的内部网络登录中，目前也主要采用的是Kerberos协议）。所以总体来说，Kerberos认证协议主要是在系统层中得到广泛应用，不过像交换机、路由器这些设备目前也有较多应用。但是目前的国内图书市场上还没有见到全面、系统地介绍这种得到广泛应用的身份认证协议工作原理，以及协议体系结构。

笔者在IETF和Microsoft英文官方网站上进行搜集和翻译，然后整理、扩展了该协议比较全面的第一手专业资料，非常感谢IETF和Microsoft公司为我们提供了如此全面、深入的第一手专业技术资料。

本章重点

* Kerberos V5身份认证机制。

* Kerberos V5身份认证的优点与缺点。

* Kerberos SSP体系架构。

* Kerberos物理结构。

* Kerberos V5身份认证的3个子协议。

* AS、TGS、CS交换。

* Kerberos交换消息。

* Kerberos的本地登录、域用户的工作站登录、单域身份认证和用户到用户的身份认证原理。

* Kerberos V5身份认证的启用与策略配置。

5.1 身份认证概述

在正式介绍Kerberos身份认证协议之前，先来了解一下什么是身份认证。这个概念同样适用于本书后面介绍的其他身份认证技术。

身份认证是系统安全的一个基础方面，它用来确认尝试登录域或访问网络资源的任何用户的身份。Windows服务器系统身份认证针对所有网络资源启用“单点登录”（Single Sign-on，SSO）。采用单点登录后，

用户可以使用一个密码或智能卡一次登录到域，然后向域中的任何计算机验证身份。身份认证的重要功能就是它对单点登录的支持。

单点登录是一种方便用户访问多个系统的技术，用户只需在登录时进行一次注册，就可以在一个网络中自由访问，不必重复输入用户名和密码来确定身份。单点登录的实质就是安全上下文（Security Context）或凭证（Credential）在多个应用系统之间的传递或共享。当用户登录系统时，客户端软件根据用户的凭证（例如用户名和密码）为用户建立一个安全上下文，安全上下文包含用于验证用户的安全信息，系统用这个安全上下文和安全策略来判断用户是否具有访问系统资源的权限。Kerberos V5身份认证协议提供一个在客户端跟服务器端之间，或者服务器与服务器之间的双向身份认证机制。

单点登录在安全性方面提供了两个主要优点。

* 对用户而言，单个密码或智能卡的使用减少了混乱，提高了工作效率。

* 对管理员而言，由于管理员只需要为每个用户管理一个账户，因此域用户所要求的管理支持减少了。

5.1.1 单点登录身份认证执行方式

包括单点登录在内的身份认证，分两个过程执行：交互式登录和网络身份认证。成功的用户身份认证取决于这两个过程。

1. 交互式登录

交互式登录过程向域账户或本地计算机确认用户的身份。这一过程根据用户账户的类型而不同。

* 使用域账户：用户可以通过存储在Active Directory目录服务中的单一注册凭据使用密码或智能卡登录到网络。如果使用域账户登录，被授权的用户可以访问该域及任何信任域中的资源；如果使用密码登录到域账户，将使用Kerberos V5进行身份认证；如果使用智能卡，则将结合使用Kerberos V5身份认证和证书。

* 使用本地计算机账户：用户可以通过存储在安全账户管理器（本地安全账户数据库，SAM）中的凭据登录到本地计算机。任何工作站或成员服务器均可以存储本地用户账户，但这些账户只能用于访问该本地计算机。

2. 网络身份认证

网络身份认证向用户尝试访问的任何网络服务确认用户的身份证明。为了提供这种类型的身份认证，安全系统支持多种不同的身份认证机制，包括Kerberos V5、安全套接字层/传输层安全性（SSL/TLS），以及为了与Windows NT 4.0兼容而提供的NTLM。

网络身份认证对于使用域账户的用户来说不可见。使用本地计算机账户的用户每次访问网络资源时，必须提供凭据（如用户名和密码），而使用域账户，则用户就具有了可用于单一登录的凭据。

5.1.2 主要的身份认证类型

5.2 Kerberos身份认证基础

Kerberos其实是希腊神话中看守地狱大门的三头猛犬的名字，这只猛犬除了比一般的狗多出两个头外，还有喷火与喷硫酸的特异功能。传说中，除非是像海格力士这样的超级肌肉男，否则一般寻常人绝非是Kerberos的对手。由于Kerberos象征着看门、守卫的意思，因此当初MIT（Massachusetts Institute of Technology，麻省理工学院）阿西娜小组便以此来命名他们所开发的认证协议。

Kerberos身份认证协议是10年前由MIT开发的。第一个公开发行的是Kerberos V4身份认证协议，在得到广泛的工业应用和重视后，又开发了Kerberos V5身份认证协议。

Kerberos可用来为网络上的各种服务器提供认证服务，使得口令不再是以明文方式在网络上传输，并

且连接之间的通信是加密的。但它与我们将在本书后面介绍的PKI认证原理不一样：PKI使用公钥机制（非对称加密机制），kerberos则基于私钥机制（对称加密机制）。Kerberos称为可信的第三方验证协议，这就意味着它运行在独立于任何客户机或服务器的服务器之上。

对称式加密机制的定义为加密与解密时使用的是相同的密钥（secret key）。显然，非对称加密机制中

加密与解密时使用的是不同的密钥。

对称加密机制中的密钥必须在事前透过其他的安全管道来交换。唯有在通信双方共享密钥的条件下，

才能进行对称式加密法的认证。例如，在一般的企业网络中，无论使用何种网络系统，网管人员势必需要

以网络以外的安全途经（直接告之或传小纸条等），来告知新使用者的账号和密码。之后，使用者才能使

用此账号和密码来登入网络进行认证。

5.2.1 Kerberos V5身份认证机制

Kerberos身份认证协议的当前版本是Kerberos V5。Kerberos V5是域内主要的安全身份认证协议。Kerberos V5协议可验证请求身份认证的用户标识（也就是对客户端身份进行认证），以及提供请求身份认证的服务器（也就是可选对服务器身份进行认证）。这种双重认证也就是通常所说的"相互身份认证"（在

NTLM身份认证机制中，它只是对客户端进行单向的身份认证）。Kerberos V5身份认证协议提供了一种在客户机和服务器之间，或者一个服务器与其他服务器之间进行相互身份认证的机制。

Kerberos V5协议假设在客户端和服务器之间初始传输是在可能被镜像，或者修改的开放网络上进行的。这种开放网络环境的典型案例就是基于互联网的应用，黑客可以轻易地入侵到客户端，或者服务器端，对合法的客户端和服务器通信进行破坏。

Kerberos V5身份认证机制主要体现在其用于访问网络服务的票证（Ticket），其实就相当于我们现实生活中的各种"门票"。这些票证包含认证符（Authenticator），经过加密的数据，其中包括加密的密码。除了输入密码或智能卡凭据外，整个身份认证过程对用户都是不可见的，也就是透明的。

Kerberos V5中的一项重要服务是密钥分发中心（Key Distribution Center，KDC），它是作为通信双方信任的第三方，身份认证的任务就是由它负责的。Kerberos KDC使用活动目录服务数据库作为它的安全账户数据库。活动目录是默认NTLM和Kerberos身份认证方式所必需的。KDC作为Active Directory目录服务的一部分在每个域控制器上运行，存储了所有客户端密码和其他账户信息。

当Windows 2000 Server/Server 2003采用Kerberos V5协议作为安全支持提供程序（Security Support Provider，SSP）时，则可以通过SSPI（Security Support Provider Interface，安全支持提供程序接口）进行安全访问。另外，Windows 2000 Server/Server 2003支持通过智能卡上的公钥证书进行身份认证初始化。

Kerberos V5服务安装在每个域控制器上，Kerberos客户端则安装在每个工作站和服务器上。每个域控制器作为KDC使用，客户端使用域名服务（DNS）定位最近的可用域控制器，域控制器在用户登录会话中作为该用户的首选KDC运行。如果首选KDC不可用，系统将定位备用的KDC来提供身份认证。

要理解Kerberos V5的基本身份认证机制，首先要明白的一点就是它是采用对称加密机制的，也就是加密和解密过程使用的是相同密钥。现假设在一个域网络上有两台计算机客户端与服务器端。客户端与服务器端各自拥有一把相同的密钥Key（当然，也不会有其他人拥有这把Key），而且双方事先已经协调好要使用什么样的方法。最后，客户端与服务器端的时间误差必须同步化（这是有关时间戳方面的，在本章后面将具体介绍）。在上述条件下，若客户端与服务器端就可进行相互验证，验证步骤如图5-1所示。

基本步骤为：客户端向KDC申请票证许可票证（TGT）→KDC响应TGT申请请求，发回加密的TGT 和会话密钥→客户端解密获取TGT和登录会话钥，并向KDC发送服务票证（ST）请求→KDC响应ST请求，发回加密的ST和会话密钥→客户端使用ST和登录会话密钥向Kerberos服务器发送服务访问请求

→Kerberos服务器通过ST和服务会话密钥验证客户端身份，并把认证符返回给客户端，由客户端验证服务器。整个过程可分为两大的步骤，首先是KDC获取网络登录所需的TGT和登录会话密钥，然后是从KDC 获取进行网络服务访问所需的ST和服务会话密钥。其中涉及到两个票证：票证许可票证（TGT）、服务票证（ST），以及登录会话密钥和服务会话密钥两个会话密钥。

详细的认证步骤说明如下，对应图5-1中的（1）~（6）步。

（1）客户端从KDC请求TGT。

在用户试图通过提供用户凭据登录到客户端时，如果已启用了Kerberos身份认证协议（具体启用方法将在本章后面介绍），则客户端计算机上的Kerberos服务向密钥分发中心（KDC）发送一个Kerberos身份认证服务请求，以期获得TGT（Ticket-Granting Ticket，票证许可票证）。该请求包含用户名、请求TGT 所需的服务信息，以及使用用户长效密钥（Long-term Key，通常是指密码）加密的时间戳。在Windows 2000 Server或Windows Server 2003操作系统上，域控制器充当KDC，而Active Directory宿主安全账户数据库。（时间戳是由用户长效密钥（通常是指用户密码）进行加密的。）

在Kerberos V5中主要有两类密钥，一是长效密钥（Long-term Key），二是短效密钥（Short-term Key）。长效密钥通常是指密码，一般来说不会经常更改密码；短效密钥一般是指具体会话过程中使用的会话密钥。长效密钥可能长期内保持不变，比如你的密码，可能几年都不会改变。由这样的Key，以及由此派生的Key 都称为长效密钥。长效密钥的使用是有原则的，那就是被长效密钥加密的数据不应该在网络上传输。原因

很简单，一旦这些被长效密钥加密的数据包被恶意的网络监听者截获，则黑客就可以通过计算获得你用于加密的长效密钥，因为任何加密算法都不可能做到绝对保密。由于被长效密钥加密的数据包不能用于网络传送，所以我们使用另一种短效密钥来加密需要进行网络传输的数据。由于这种Key只在一段时间内有效，即使被加密的数据包被黑客截获，等他把Key计算出来的时候，这个Key早就已经过期了，相对来说安全许多。

（2）KDC发送加密的TGT和登录会话密钥。

KDC为来自Active Directory的用户获取长效密钥（即密码），然后解密随Kerberos身份认证请求一起传送的时间戳。如果该时间戳有效，则用户是有效用户。KDC身份认证服务创建一个登录会话密钥，并使用用户的长效密钥对该副本进行加密。然后，KDC身份认证服务再创建一个TGT，它包括用户信息和会话密钥。最后，KDC身份认证服务使用自己的密钥加密TGT，并将加密的登录会话密钥副本和加密的TGT

传递给客户端。

时间戳的解密也是使用用户长效密钥，登录会话密钥是由用户的长效密钥（通常是指用户密码）进行加密的，TGT是由KDC密钥进行加密的。

（3）客户端向KDC TGS请求ST。

客户端使用其长效密钥（即密码）解密登录会话密钥，并在本地缓存它。同时，客户端还将加密的TGT 存储在它的缓存中。这时还不能访问网络服务，因为它仅获得了票证许可票证（TGT）和登录会话密钥，仅完成了网络登录的过程，还没有获得访问相应网络服务器所需的服务票证（Service Ticket，ST）。客户端向KDC票证许可服务（Ticket-Granting Service，TGS）发送一个服务票证请求（ST是由TGS颁发的），请求中包括用户名、使用用户登录会话密钥加密的认证符、TGT，以及用户想访问的服务（和服务器）名称。

认证符是由用户登录会话密钥进行加密的。

（4）TGS发送加密的服务会话密钥和ST。

KDC使用自己创建的登录会话密钥解密认证符（通常是时间戳）。如果验证者消息成功解密，则TGS 从TGT提取用户信息，并使用用户信息创建一个用于访问对应服务的服务会话密钥。它使用该用户的登录会话密钥对该服务会话密钥的一个副本进行加密，创建一个具有服务会话密钥和用户信息的服务票证（ST），然后使用该服务的长效密钥（密码）对该服务票证进行加密。并将加密的服务会话密钥和服务票证返回给客户端。

认证符是由登录会话密钥解密的，服务会话密钥是由用户登录会话密钥加密的，服务票证是用服务的长效密钥加密的。

（5）客户端发送访问网络服务请求。

客户端访问服务时，向Kerberos服务器发送一个请求。该请求包含身份认证消息（时间戳），并用服务会话密钥和服务票证进行加密。

服务请求消息是由服务会话密钥和服务票证加密的。

（6）服务器与客户端进行相互验证。

Kerberos服务器使用服务会话密钥和服务票证解密认证符，并计算时间戳。然后与认证符中的时间戳进行比较，如果误差在允许的范围内（通常为5分钟），则通过测试，服务器使用服务会话密钥对认证符（时间戳）进行加密，然后将认证符传回到客户端。客户端用服务会话密钥解密时间戳，如果该时间戳与原始时间戳相同，则该服务是真正的，客户端继续连接。注意这是一个双向、相互的身份认证过程。

认证符是由服务会话密钥和服务票证解密的，而返回给客户端的时间戳是用服务会话密钥加密的，在客户端同样是用服务会话密钥解密时间戳的。

5.2.2 Kerberos V5身份认证的优点与缺点

Kerberos V5相对以前的NTLM身份认证方式来讲，具有明显的优势，但与其他身份认证方式相比，又具有一定的缺点。

1. Kerberos V5身份认证的优点

Kerberos V5协议比NTLM身份认证方式更安全、更具弹性、更有效率。Kerberos身份认证方式具有以下优点。

支持相互身份认证。

通过使用Kerberos协议，通信双方都可以对对方进行身份认证。尽管NTLM可以让服务器校验客户端身份，但它不能让客户端校验服务器的身份，也不能使一台服务器校验另一台服务器的身份。NTLM身份认证是设计用于服务器可信的网络环境中的，而Kerberos V5协议没有这种假设。当客户端使用Kerberos V5协议对特定服务器上的特定服务进行身份认证时，Kerberos为客户端提供网络上恶意代码不会模拟该服务的保证。

支持委派身份认证。

Windows服务可按照客户的意愿模仿客户端访问网络资源。在许多情况下，一个服务可以为客户端完成本地计算机上的资源访问。NTLM和Kerberos V5协议都可以为一个服务在本地模仿客户端提供所需的信息。但无论如何，有些分布式应用是按以上这种模仿机制设计的，在其他计算机上连接后端服务时，前端服务必须模仿客户端。Kerberos V5协议包括代理机制，以使一个服务在连接到其他服务时去模仿客户端。这一点，NTLM是做不到的。

为服务器提供更有效的验证。

Kerberos身份认证提供优于NTLM身份认证的改进的性能。虽然我们一再地说Kerberos是一个涉及到Client、Server、KDC三方的认证过程，但是一旦Client获得用过访问某个Server的Ticket（票证），该Server 就能根据这个Ticket实现对Client的验证，而无须KDC的再次参与。和传统的基于Windows NT 4.0的每个完全依赖信赖第三方的NTLM比较，具有较大的性能提升。因为在NTLM身份认证方式中，应用服务器必须连接到域控制器才能对客户端进行身份认证。也就是说，在Kerberos V5身份认证中，一些应用，服务器是不需要与域控制器连接的。取而代之的是，服务器是通过检验客户端提供的凭证来进行身份认证的。客户端一旦从特定服务器上获得了信任，则以后可以通过网络登录再次使用这个凭证，用可恢复的服务票证取代了身份认证通行证。

简化的信任管理。

具有多个域的网络不再需要一组复杂的显式、点对点信任关系。

互操作性。

Microsoft 实现的Kerberos 协议基于向Internet工程任务组（IETF）推荐的标准跟踪规范。因此，Windows 2003中协议的实现为与其他网络的互操作奠定了基础（其中Kerberos V5 用于身份认证）。

2. Kerberos V5身份认证的缺点

Kerberos身份认证协议的缺点主要体现在以下几个方面。

Kerberos身份认证采用的是对称加密机制，加密和解密使用的是相同的密钥，交换密钥时的安全性比较难以保障。

Kerberos服务器与用户共享的服务会话密钥是用户的口令字，服务器在响应时不需验证用户的真实性，而是直接假设只有合法用户拥有了该口令字。如果攻击者截获了响应消息，就很容易形成密码攻击。

Kerberos中的AS（身份认证服务）和TGS是集中式管理，容易形成瓶颈，系统的性能和安全也严重依赖于AS和TGS的性能和安全。在AS和TGS前应该有访问控制，以增强AS和TGS的安全。

随用户数量增加，密钥管理较复杂。Kerberos拥有每个用户的口令字的散列值，AS与TGS负责户间通信密钥的分配。假设有n个用户想同时通信，则需要维护n×（n-1）/2个密钥。

5.2.3 Kerberos V5协议标准

Kerberos V5目前是IETF的标准，在Windows Server 2003系统中执行的Kerberos协议是与定义在RFC 1510中的Kerberos V5非常接近的。在Kerberos消息中传递安全口令的机制和格式遵从RFC 1964中的定义。

1. Kerberos V5协议机制

Kerberos V5协议说明了以下机制。

验证用户标识：当用户想要与服务器访问时，服务器需要验证用户的标识。可以考虑这样一种情形，如Alice@https://www.wendangku.net/doc/811657194.html,。因为用户对资源的访问是基于标识和相关联的权限的，服务器必须确保用户真正拥有所需的标识。

安全用户名打包：用户名是用户的主体名称（User Principal Name，UPN），如Alice@https://www.wendangku.net/doc/811657194.html,。用户的凭证是封装在票证的数据结构之中的。

安全传递用户凭证：当票证加密后，消息就会在网络上传递用户凭证。

尽管Kerberos协议验证用户标识，但它不授权访问。这是一个非常重要的区别。票证中的其他上下文（如驱动协议），通常提供证明标识和授权行为或授权访问双重功能。Kerberos票证仅证明用户是用户声明的那个。当用户标识被校验后，本地安全授权机构（Local Security Authority，LSA）将授权或者拒绝该用户对资源的访问。

Kerberos身份认证机制创建并安全交付给认证者--通常是基于客户端票证中唯一的时间戳。认证者是唯一的，而且仅有效使用一次。这样就可以最大限度地避免可能企图截取和使用客户端标识的人获得并重新使用客户端票证的可能性，可以有效阻止包重放攻击。

2. Kerberos密钥

Kerberos消息是以不同的加密密钥进行加密的，以确保任何人不能篡改客户端的票证，或者Kerberos 消息中的其他数据。

1）Kerberos密钥种类

Kerberos密钥可能包括以下几个种类。

长效密钥（Long-term Key）：这种密钥仅目标服务器KDC能识别，是用客户端票证加密的。

客户/服务器会话密钥（Client-Server Session Key）：短效、单一会话密钥是由KDC创建，并在确认标识和授权后，应用于加密由客户端到服务器，或者由服务器到客户端的消息。

KDC/用户会话密钥（KDC-Client Session Key）：KDC和用户共享这个保密的加密密钥用于加密到客户端的消息，包括会话密钥消息。

客户/服务器会话密钥和KDC/用户会话密钥都是短效密钥（Short-term Key）

2）Kerberos V5协议可以使用对称和非对称两种加密方式

因为大多数Kerberos加密方法是在仅由KDC和客户端，或者由KDC和网络服务创建的密钥基础上的，所以Kerberos V5协议通常被认为是使用对称加密的。也就是说，在加密和解密过程中是使用相同密钥的，但微软所采用的Kerberos协议也可以非对称加密。私钥/公钥对可以用来加密或解密从网络客户端或者网络服务端来的初始身份认证消息。

3）支持Kerberos V5协议扩展

Ksecdd.sys。

Windows Server 2003是当做SSP来执行Kerberos V5身份认证协议的，是受操作系统的动态链接库支

持的。系统使用Kerberos SSP、Kerberos.dll来当做首选的身份认证方式。在LSA与交互用户建立安全上下文后，通过运行用户的安全上下文加载另一个Kerberos SSP实例，以支持签名和保密的消息。

因为Kerberos协议是Windows Server 2003系统中的首选身份认证协议，所有域服务支持Kerberos SSP，其中包括以下几个。

用于活动目录查询的LDAP（Lightweight Directory Access Protocol，轻量级目录访问协议）。

用于远程服务器或工作管理的RPC调用。

打印服务。

客户-服务器身份认证。

使用通用因特网文件系统/服务器消息块（Common Internet File System/Server Message Block，CIFS/SMB）的远程文件访问。

分布式文件系统管理和选举。

内部网络身份认证和因特网信息服务（Internet Information Services，IIS）。

IPSec（Internet Protocol Security，因特网协议安全）的安全授权身份认证。

域用户和计算机证书服务所需的证书。

5.2.4 Kerberos V5身份认证所用端口

在整个Kerberos V5身份认证过程中主要用到两个服务，那就是Kerberos服务和DNS服务，分别所用到的端口为TCP 88和TCP 53。所以，在域网络中要使用Kerberos协议进行身份认证，就必须确保网络防

火墙对这两个端口保持开放。

5.3 Kerberos SSP认证

本节主要讨论在Windows Server 2003系统中，Kerberos V5是如何进行身份认证的，在其他网络环境中的认证方法也可以参见此处，因为基本原理是一样的。

Windows Server 2003系统是把Kerberos V5认证协议当做安全支持提供程序（SSP）的，是以一个动态链接文件提供的。在Windows Server 2003中同样也提供一个用于NTLM（NT LAN Manager，是早期在NT4.0时期提供的一种身份认证方式，现在比较少用）身份认证的SSP。在默认情况下，这两种SSP都是由Windows Server 2003计算机在系统启动时的LSA（Local Security Authority，本地安全认证机构）服务装载的。系统

可以使用任何一个SSP来认证网络用户的登录，以及客户端和服务器端的连接。最终使用哪个SSP，要依

据网络连接的另一端计算机对两种SSP的支持能力，以及在应用中所需参数来决定。

在Windows Server 2003系统中的SSPI提供了一种通过已在客户端和服务器端建立的通信通道携带身份认证口令的机制。当通信双方需要被对方进行身份认证，以确保通信安全时，则认证请求会路由到SSPI，完成身份认证进程，而不管当前网络中所使用的网络通信协议。SSPI把认证请求转换成机器容易识别的二进制信息，通过应用层（Application Layer）传送到网络连接的另一端，在另一端这些请求信息可传送到SSPI 层（SSPI Layer）。这样，SSPI可以使用在计算机或网络中可使用的各种安全模块，而无须转换接口为安全接口。

2. Kerberos SSP

Windows Server 2003系统把Kerberos V5身份认证协议当做SSP，并以DDL链接文件提供。系统使用Kerberos.dll当做首选的身份认证方式。当LSA（Local Security Authority，本地安全认证机构）为交互用户建立安全上下文后，通过使用用户中的安全上下文进程为另一端装载Kerberos SSP实例，以便对消息进行签名和封装。

5.4 Kerberos物理结构

Kerberos身份认证为可能被监控或截取的开放式网络中客户端和服务器之间进行交互认证提供了一种机制。为了提供安全的身份认证，Kerberos身份认证采用对称密钥加密对象和Kerberos服务。

本节将包括以下部分。

在Kerberos身份认证中所使用的密钥。

Kerberos票证。

认证符（Authenticator）。

凭证缓存。

密钥分发中心。

5.4.1 Kerberos中的密钥

在Kerberos身份认证中需要用到许多种不同的密钥，了解这些不同密钥的用途和使用方法对于理解Kerberos身份认证原理来说非常重要。

2．需要加密密钥的原因

Kerberos协议主要依靠包括共享加密密码技术在内的身份证技术。共享加密密码技术可以这么简单理解：当加密密码仅是通信双方知道时，另一方就可以通过校验对方所提供的共享密码是否与共享的密码一致来确认对方的身份。

例如，假设Alice经常给Bob发送消息，Bob需要确认这个消息确实是来自Alice。为此他们决定通过设置一个仅双方知道的密码来确认。如果从Alice发送来的消息中能够显示发送者已知道这个共享密码，Bob 就可以很容易地验证消息发送者的确实是Alice了。

下面仅剩下一个需要Alice和Bob解决的问题了，那就是Alice该如何在消息中显示她是知道这个共享密码的。她可以把共享密码放在消息中的某个地方，也许是在消息末端用Alice这个名字和共享密码作为签名。如果Alice和Bob能确保没有其他人读过他们的邮件，那通过邮件方式是最简单、有效的传送方式。但不幸的是，这些信息通过网络传送时，可能被一些非法用户（如Carol）截获，他们会利用网络分析仪来扫描目标网络的通信，这样就有可能分析出这个共享密码。所以，Alice不能在消息中包含共享密码来证明自己知道共享密码。

Kerberos协议可以很好地解决以上问题，那就是利用加密密钥技术替换共享的密码。通信双方共享一个加密的密钥，然后再利用这个加密的密钥来校验另一个用户的合法性。采用这种技术，共享密钥必须是对称的，也就是说加密和解密过程用的是同一个密钥。

3. Kerberos身份认证密钥的种类

Kerberos身份认证依靠多个密钥和加密的密钥类型。密钥类型包括长效的对称密钥（Long-term Symmetric Key）、长效非对称密钥（Long-term Asymmetric Key）和短效对称密钥（Short-term Symmetric Key）。Kerberos身份认证协议设计用来进行对称加密，也就是说消息发送者和接收者共享同一个密钥来进行加密和解密。

长效对称密钥是基于密码生成的。纯文本密码（Plaintext Password）是通过加密功能传送密码文本到加密密钥的（所有执行Kerberos V5的身份认证协议必须支持DES-CBC-MD5算法，其他算法也是允许的），加密的结果就生成了加密的密钥。长效对称密钥包括用户（User Key）、系统（System Key）、服务（Service Key）和领域间（Inter-realm Key）等密钥类型。

下面对以上密钥类型分别予以介绍。

1）用户密钥（User Key）

如果用户账户已经建立，那么用户密码就会被用来创建用户密钥。在活动目录域中，用户密钥是保存在活动目录的用户对象中的。在工作站中，用户密钥是相应用户登录域网络时创建的。

2）系统密钥（System Key）

当工作站或服务器加入到Windows域时，它将收到一个密码。与用户账户一样，系统密钥也是基于系统账户密码创建的。

3）服务密钥（Service Key）

服务也是使用它们的账户密码来登录的。在同一个区域中，所有KDC（密钥分发中心）使用相同的服务密钥，这个密钥是基于分配给"krbtgt"账户的密码而创建的，每个活动目录域都会内建这个账户。

4）领域间密钥（Inter-realm Key）

为了实现领域间的身份认证，KDC必须共享一个领域间密钥（Inter-realm Key），以此来达到领域间的相互信任。

在活动目录的父、子域间是共享一个领域间密钥的。这个领域间密钥是Windows 2000和Windows Server 2003系统域间传送凭证的基础。如果已经创建了一个快捷信任，这两个域将交换他们的密钥，以验证凭证。

5）长效的非对称密钥：公钥

当前，在微软的Kerberos身份认证方式中，存储在智能卡中的公钥证书仅是长效的非对称密钥。

6）短效的对称密钥：会话密钥

会话密钥是用来进行票证许可票证（TGT）和服务票证（Service Ticket，ST）的，仅当会话或服务票证有效时被使用，是短效的。

4. Kerberos SSP加密密钥长度

Kerberos SSP支持不同的加密类型，密钥长度要依据所要完成的任务和选项配置。尽管密钥长度取决于所需的保护级别，但密钥大小并不意味着票证的大小。下面列出了Kerberos SSP支持的不同类型加密时的密钥长度，具体包括以下3种。

RC4-HMAC：128位。

DES-CBC-CRC：56位。

DES-CBC-MD5：56位。

5.4.2 Kerberos票证

票证是Kerberos身份认证的主要组成部分，Kerberos消息用来请求和释放票证。在Kerbeos身份认证中有两种类型的票证：TGT和服务票证（ST）。

Kerberos客户端在身份认证过程中会发送以下票证请求到KDC。

TGT（票证许可票证）：KDC在接收到请求后提供身份认证服务，验证请求者是否有资格获取票证。

ST（服务票证）：KDC在接收到请求后提供票证许可服务，验证请求者是否有访问对应服务或服务器的资格。

票证请求内容包括以下两个。

请求属性（标记），如票证是否可更新的。

请求加密和方法。

1. TGT

KDC通过返回自己的服务票证来响应客户端身份认证服务请求，则指定的服务票证调用票证许可票证（TGT）。TGT票证可使身份认证服务安全传送请求者的信任关系到票证许可服务。

TGT是从身份认证服务中得到的用户原始票证，用来请求服务的票证，且仅用于票证许可服务。

TGT是用KDC各服务共享的长效密钥进行加密的，客户端不能读取票证信息，仅KDC服务器可以读取，以确保用户凭证、会话密钥和其他信息的安全访问。就像普通服务票证一样，TGT包括将用于客户端通信的会话密钥副本。

对于客户端来说，TGT仅是另一个票证。在企图与任何服务连接前，客户端必须首先检查它凭证缓存中需要连接到的服务的服务票证。如果凭证缓存中没有对应的服务票证，再检查缓存中的TGT票证。如果找到了TGT票证，客户端从缓存中取出TGT会话密钥，利用这个密钥准备认证符，然后与相应服务所需的服务票证请求一起，把认证符和TGT信息发送到KDC，申请服务票证（ST）。

从KDC端来说，TGT可以使它避免在每次有用户发出服务请求时重复查找用户长效密钥（通常是用户密码）。

2. ST

服务票证（ST）可以使票证许可服务（Ticket-Granting Service，TGS）安全传输请求凭证到目标服务器或服务上。KDC通过发送客户端和服务器端两者的会话密钥副本到客户端来响应客户端连接到服务的请求。客户端会话密钥是用KDC与客户端共享的密钥进行加密的；服务器端会话密钥副本是连同称之为服务票证数据结构中的客户端信息一起嵌入的。然后，整个数据结构用KDC与服务共享的密钥进行加密。服务器端会话密钥副本安全植入，被客户端管理，直到连接到了相应服务或服务器上。

ST是区别于TGS的另一种用于服务身份认证的方式，它仅用于目标服务。它是用服务密钥进行加密的，服务密钥是一种KDC与目标服务共享的长效密钥。这样，尽管客户端管理着服务票证，但客户端仍无法读取其中的信息。仅KDC和目标服务可以读取服务票证内容，以确保安全访问用户凭证、会话密钥和其他信息。

KDC仅简单提供票证许可服务，但它不保证信息准确到达目标地址。即使KDC消息进行了错误的质询，也没有任何影响。仅那些知道客户端密钥的人才可以解密客户端会话密钥副本。仅知道服务器服务密钥的人可以读取票证中的信息。

当客户端收到来自KDC的响应时，客户端取出票证和客户端会话密钥副本，并保存在安全缓存中。当客户端被允许与服务器连接时，客户端会发送包括用服务器密钥加密的票证和用会话密钥加密的认证符信息到服务器。

3. 使用服务票证的好处

服务器并不存储与客户端通信的会话密钥。会话密钥是由客户端在其凭证缓存中为服务器管理的，而且在每次需要访问服务器时，都是以会话密钥向服务器提供票证。当服务器接收到来自客户端的服务票证

时，服务器可以使用KDC与服务器共享的密钥来解密票证，取出会话密钥。当服务器不再需要会话密钥时，则可以丢弃它。

客户端不需要在每次访问同一个服务器时返回去向KDC索要票证，因为服务票证可以重复使用。为了预防有人非法复制票证，KDC会在票证的数据结构中为服务票证设定有效期限。

票证的有效期是多长，要视领域中的策略设置而定了。尽管RFC建议最大的票证有效期为一天，但在MIT Kerberos 5 Release 1.3.1和Windows 2000 /Server 2003系统的Kerberos协议功能中，默认的最长票证时间是10个小时，满足了最普通的单次登录时间长度。因为当用户注销登录后，凭证缓存中就会自动清除所有与之相关的票证，包括会话密钥。

4. 票证内容

学习到了这里，我们完全可以列举出票证中所包括的字段，并给予它们具体的描述。精确的票证数据结构是在RFC 1510中描述的。

票证中前3个字段是没有加密的，它们的信息也是纯文本的，所以客户端可以利用这些信息在它们的凭证缓存中管理票证。票证具体所包括的字段内容如表5-4所示。

5. 客户端需要了解票证中的信息

客户端需要了解关于在票证和TGT中有哪些信息，以便管理它们的凭证缓存。当KDC以身份认证服务结果或者TGS交换返回一个票证和会话密钥时，在包的数据结构中的会话密钥副本将包括以下信息：身份认证时间、票证启用时间、票证失效时间和更新时间。整个数据包结果都是用客户端密钥加密的，最终显示的是KRB_AS_REP或者KRB_TGS_REP文件信息。

6. Windows账户中的Kerberos身份认证数据

Kerberos协议描述了在身份认证交换过程中使用的一系列字段。在这些字段中，可选的"身份认证数据"（Authorization Data）字段是用来指定终端服务的，如微软的身份认证。微软的Kerberos功能同样遵守RFC 1510参考，但使用了"身份认证"（Authorization）字段来存储关于用户标识（User ID）和所属组属性，这些信息是由域控制器在AS（身份认证服务）或者TGS请求时产生的。微软的身份认证数据结构包括以下信息。

凭证信息：票证和客户端信息，如客户端在其域中的所属组的组ID。

客户端信息：确保票证属于提交服务请求的客户端。

附加凭证：由KDC服务启用PKINIT协议返回。PKINIT是IETF对用于Kerberos中初始身份认证公钥加密草案。Windows 2000和Windows Server 2003系统使用智能卡进行交互式登录时使用此协议。

签名：微软的身份认证数据结构包括两种数字签名，一个是用于域控制器的；另一个是用于服务器提供服务的。数字签名是为了防止客户端或者非信任服务产生伪造的微软身份认证数据。

私密证书请求，预身份认证数据：通常，微软的身份认证数据包括在每个从AS中请求得到的预身份认证（包含用以证明自己身份的信息）票证中。无论如何，客户端可以明确地用"私密证书（Privilege Attribute Certificate，PAC）请求预身份认证数据"字段（可以包括，或者不包括用户的SID）发出请求。如果该字段不存在，则SID也将不包括在微软身份证字段中了。

7. KDC如何限制票证生存周期

每张票证都有一个起用时间和终止使用时间（也就是过期时间）。在启用时间和终止时间之间，客户可以为某个服务持用这个票证，以便提供票证和获取访问服务的权限，不管这个票证在此以前用过多少次。为了降低风险，管理员可以设置票证的最长使用寿命。票证的最长使用寿命是Kerberos策略中的一小部分。

当客户为连接某服务而向KDC请求一张票证时，客户可以请求一个指定的启用时间。如果请求错过了这个时间，或者当前时间已是启用时间后，KDC将设置票证的启用时间为当前时间。

不管客户端是否指定启用时间，请求必须包括一个票证过期时间（也就是时间戳）。KDC是通过在"终止时间"字段值，或者通过计算在Kerberos策略中设置的"票证最长生存时间"（Maximum Ticket Life）和票证中"启用时间"（Start Time）字段来确定票证终止时间的。无论是哪种时间先到了，票证都会终止。

KDC当服务票证或者TGT过期后是不会向客户端发出通告的。而且，除了保持短时间的记录，以阻止重放攻击外，不再为客户端提供后续的服务。

统一认证系统_设计方案

基础支撑平台

第一章统一身份认证平台 一、概述 建设方案单点登录系统采用基于Liberty规范的单点登录ID-SSO系统平台实现，为数字化校园平台用户提供安全的一站式登录认证服务。为平台用户以下主要功能： 为平台用户提供“一点认证，全网通行”和“一点退出，整体退出”的安全一站式登录方便快捷的服务，同时不影响平台用户正常业务系统使用。用户一次性身份认证之后，就可以享受所有授权范围内的服务，包括无缝的身份联盟、自动跨域、跨系统访问、整体退出等。 提供多种以及多级别的认证方式，包括支持用户名/密码认证、数字证书认证、动态口令认证等等，并且通过系统标准的可扩展认证接口（如支持JAAS），可以方便灵活地扩展以支持第三方认证，包括有登录界面的第三方认证，和无登录界面的第三方认证。 系统遵循自由联盟规范的Liberty Alliance Web-Based Authentication 标准和OASIS SAML规则，系统优点在于让高校不用淘汰现有的系统，无须进行用户信息数据大集中，便能够与其无缝集成，实现单点登录从而建立一个联盟化的网络，并且具有与未来的系统的高兼容性和互操作性，为信息化平台用户带来更加方便、稳定、安全与灵活的网络环境。 单点登录场景如下图所示：

一次登录认证、自由访问授权范围内的服务 单点登录的应用，减轻了用户记住各种账号和密码的负担。通过单点登录，用户可以跨域访问各种授权的资源，为用户提供更有效的、更友好的服务；一次性认证减少了用户认证信息网络传输的频率，降低了被盗的可能性，提高了系统的整体安全性。 同时，基于联盟化单点登录系统具有标准化、开放性、良好的扩展性等优点，部署方便快捷。 二、系统技术规范 单点登录平台是基于国际联盟Liberty规范（简称“LA”）的联盟化单点登录统一认证平台。 Liberty规范是国际170多家政府结构、IT公司、大学组成的国际联盟组织针对Web 单点登录的问题提供了一套公开的、统一的身份联盟框架，为客户释放了使用专用系统、不兼容而且不向后兼容的协议的包袱。通过使用统一而又公开的 Liberty 规范，客户不再需要为部署多种专用系统和支持多种协议的集成复杂度和高成本而伤脑筋。 Liberty规范的联盟化单点登录SSO（Single Sign On）系统有以下特点： (1). 可以将现有的多种Web应用系统联盟起来，同时保障系统的独立性，提供单点 登录服务；

网络统一身份认证计费管理系统建设方案综合

XXXX学院网络统一身份认证计费管理系 统建设方案 2016年03月 目录 一．计费系统设计规划 (2) 二．方案建设目标 (2) 三．总体方案 (3) 1.方案设计 (3) A.方案（串连网关方式） (3) B.方案（旁路方式+BRAS，BRAS产品） (4) 四．认证计费管理系统与统一用户管理系统的融合 (8) 4.1统一用户管理系统的融合 (8) 4.2一卡通系统的融合 (9) 4.3用户门户系统的融合 (9) 五．认证计费管理系统功能介绍 (9) 六．用户案例 (14) 6.1清华大学案例介绍 (14) 6.2成功案例-部分高校 (16) 6.3系统稳定运行用户证明 (16) 七.实施方案 (16)

7.1实施前准备工作 (16) 7.2认证计费系统安装 (16) 7.3实施割接前测试工作 (16) 7.4实施中割接、割接后测试工作 (17) 一．计费系统设计规划 XXXX技术学院整体用户规模设计容量为10000用户，同时在线用户规模为5000人，具有多个出口线路；网络特点呈现高带宽，高用户，多种接入方式使用人群，并且在未来还会以多种网络架构存在（有线，无线）。因此安全认证管理计费系统的设计要充分考虑系统性能满足出口带宽容量，同时也必须能满足复杂的接入模式，多种灵活的控制计费策略。 在充分满足IPv4用户的认证计费需求的前提下，设计要考虑对实现IPv6+IPv4双栈认证计费及日志采集等功能需求，同时还需要满足无线和有线认证的融合统一认证管理模式；目前学校已经使用一卡通系统，安全认证计费管理系统必须和一卡通系统实现对接，能支持未来的数字化校园，能够融合到统一身份认证平台。 有线网和无线网是实现账户统一，避免一个用户需要多账户登录有线网和无线网的情况，并可通过上网账户认证实现与校园门户系统、校园一卡通系统的平滑对接，实现用户账号的同步关联。 二．方案建设目标 针对目前学校对于用户认证计费系统的需求，通过安全认证网络管理计费系统，搭建一套包括用户接入、认证、计费及用户管理的综合平台，为校园网提供功能完善、可靠和高性能适合的宽带接入管理计费解

sso_统一身份认证及访问控制解决方案

统一身份认证及访问控制 技术方案

1.方案概述 1.1. 项目背景 随着信息化的迅猛发展，政府、企业、机构等不断增加基于Internet/Intranet 的业务系统，如各类网上申报系统，网上审批系统，OA 系统等。系统的业务性质，一般都要求实现用户管理、身份认证、授权等必不可少的安全措施；而新系统的涌现，在与已有系统的集成或融合上，特别是针对相同的用户群，会带来以下的问题： 1)如果每个系统都开发各自的身份认证系统将造成资源的浪费，消耗开发成本，并延缓开发进度； 2)多个身份认证系统会增加整个系统的管理工作成本； 3)用户需要记忆多个帐户和口令，使用极为不便，同时由于用户口令遗忘而导致的支持费用不断上涨； 4)无法实现统一认证和授权，多个身份认证系统使安全策略必须逐个在不同的系统内进行设置，因而造成修改策略的进度可能跟不上策略的变化； 5)无法统一分析用户的应用行为；因此，对于有多个业务系统应用需求的政府、企业或机构等，需要配置一套统一的身份认证系统，以实现集中统一的身份认证，并减少整个系统的成本。 单点登录系统的目的就是为这样的应用系统提供集中统一的身份认证，实现“一点登录、多点漫游、即插即用、应用无关"的目标，方便用户使用。 1.2. 系统概述 针对上述状况，企业单位希望为用户提供统一的信息资源认证访问入口，建立统一的、基于角色的和个性化的信息访问、集成平台的单点登录平台系统。该系统具备如下特点： ?单点登录：用户只需登录一次，即可通过单点登录系统（SSO）访问后台的多个应用系统，无需重新登录后台的各个应用系统。后台应用系统的用户名和口令可以各不相同，并且实现单点登录时，后台应用系统无需任何修改。 ?即插即用：通过简单的配置，无须用户修改任何现有B/S、C/S应用系统，即可使用。解决了当前其他SSO解决方案实施困难的难题。 ?多样的身份认证机制：同时支持基于PKI/CA数字证书和用户名/口令身份认证方式，可单独使用也可组合使用。 ?基于角色访问控制：根据用户的角色和URL实现访问控制功能。 ?基于Web界面管理：系统所有管理功能都通过Web方式实现。网络管理人员和系统管理员可以通过浏览器在任何地方进行远程访问管理。此外，可以使用HTTPS安全地进行管理。

网络统一身份认证计费管理系统建设方案综合

XXXX学院网络统一身份认证计费管理系统 建设方案 2016年03月 目录 一．计费系统设计规划......................................... 二．方案建设目标............................................. 三．总体方案................................................. 1.方案设计 .............................................. A.方案（串连网关方式）................................. B.方案（旁路方式+BRAS，BRAS产品） 四．认证计费管理系统与统一用户管理系统的融合................. 4.1统一用户管理系统的融合 ................................ 4.2一卡通系统的融合 ...................................... 4.3用户门户系统的融合 .................................... 五．认证计费管理系统功能介绍................................. 六．用户案例................................................. 6.1清华大学案例介绍 ...................................... 6.2成功案例-部分高校...................................... 6.3系统稳定运行用户证明 ..................................

身份认证、接入控制解决方案

身份认证、接入控制解决方案 金盾身份认证、接入控制解决方案以身份识别，杜绝非法入侵和接入保护为 主要设计理念，金盾准入控制保护系统是金盾软件公司独创的，国际领先的 产品功能，是产品的核心功能之一，具有实施简单，主动发现、自动防御、效果显著等特点，极大提升了内网的防御能力和用户的体验效果。 方案简介 □如何防止非授权终端的接入内部局域网窃取涉密资料？ □如何防止“黑户”电脑和“问题“笔记本擅自进入内部网络成为传播病毒的源头? □ 如何防止假冒身份的非法计算机带入内网肆意访问内部办公系统？

方案功能 安全状态评估 □终端补丁检测：评估客户端的补丁安装是否合格，包括：操作系统(Windows 98/me/2000/XP/2003/Vista/win7/2008 )。 □客户端版本检测：检测安全客户端的版本，防止使用不具备安全检测能力的客户端接入网络，同时支持客户端自动升级。 □终端运行状态实时检测：可以对上线用户终端的系统信息进行实时检测，发现异常客户端或被卸载时自动阻断网络，强制安装。 □终端防病毒联动：主要包含两个方面，终端用户接入网络时，检查其计算机上防病毒软件的安装运行情况以及病毒库和扫描引擎版本是否符合安全要求等，不符合安全要求可以根据策略阻止用户接入网络或将其访问限制在隔离区。 □端点用户接入网络后，定期检查防病毒软件的运行状态，如果发现不符合安全要求可以根据策略强制让用户下线或将其访问限制在隔离区。 安全接入审核 □强身份认证：非授权用户接入网络需要身份认证，在用户身份认证时，可绑定用户接入IP、MAC、接入设备IP、端口等信息，进行强身份认证，防止帐号盗用、限定帐号所使用的终端，确保接入用户的身份安全。 □网络隔离区：对于安全状态评估不合格的用户，可以限制其访问权限，被隔离到金盾网络隔离区，待危险终端到达安全级别后方可入网。 □软件安装和运行检测：检测终端软件的安装和运行状态。可以限制接入网络的用户必须安装、运行或禁止安装、运行其中某些软件。对于不符合安全策略的用户可以记录日志、提醒或隔离。 □终端授信认证：对于外来计算机由于业务需要接入内网或者访问Internet时，针对对方IP、MAC等端口做授信暂时放行。 □内网安全域：可以限制用户只能在允许的时间和网络IP段内（接入设备和端口）使用网络。

统一身份认证平台功能描述

统一身份认证平台功能 描述 文稿归稿存档编号：[KKUY-KKIO69-OTM243-OLUI129-G00I-FDQS58-

数字校园系列软件产品统一身份认证平台 功能白皮书 目录

1产品概述 1.1产品简介 随着校园应用建设的逐步深入，已经建成的和将要建成的各种数字校园应用系统之间的身份认证管理和权限管理出现越来越多的问题：用户需要记录多个系统的密码，经常会出现忘记密码的情况；在登 录系统时需要多次输入用户名/密码，操作繁琐。 各个系统之间的账号不统一，形成信息孤岛现象，导致学校管理工 作重复，增加学校管理工作成本。 新开发的系统不可避免的需要用户和权限管理，每一个新开发的系 统都需要针对用户和权限进行新开发，既增加了学校开发投入成 本，又增加了日常维护工作量 针对学生、教职工应用的各种系统，不能有效的统一管理用户信 息，导致学生在毕业时、教职工在离退休时不能及时地在系统中 清除这部分账号，为学校日后的工作带来隐患。 缺乏统一的审计管理，出现问题，难以及时发现问题原因。 缺乏统一的授权管理，出现权限控制不严，造成信息泄露。 统一身份认证平台经过多年的实践和积累，通过提供统一的认证服务、授权服务、集中管理用户信息、集中审计，有效地解决了以上问题，赢得客户的好评。

1.2应用范围 2产品功能结构 统一身份认证平台功能结构图 3产品功能 3.1认证服务 3.1.1用户集中管理 统一身份认证平台集中管理学校的所有教职员工和学生信息，所有的用户信息和组织机构信息存储在基于LDAP协议的OpenLDAP目录服务中，保证数据的保密性和读取效率。通过用户同步功能，及时地把关键业务系统中的用户信息同步到统一认证平台中，然后通过平台再分发给需要的业务系统，保证账号的一致性。 为所有的用户设置权限生效起止日期，即使不对用户做任何操作，在权限生效期外的用户也无法通过认证，保证了系统的安全性。 用户管理

浅谈身份认证系统技术方案

******身份认证系统 技术方案

目录 1.概述 (3) 1.1前言 (3) 1.2身份认证系统用户认证需求描述 (3) 1.3身份认证系统认证解决之道 (5) 1.3.1身份认证系统的模式 (5) 1.3.2建立身份认证系统 (6) 1.3.3证书在身份认证系统上的安全应用 (6) 2.详细设计方案 (8) 2.1 身份认证系统 (8) 2.2产品设计原则 (8) 2.2.1认证系统的设计原则 (8) 2.2.2 网络环境设计原则 (9) 2.3功能模块架构 (10) 2.4 身份认证系统功能简介 (12) 2.5身份认证系统安全性分析 (13) 2.5.1本系统安全性保护的必要性 (14) 2.5.2安全性要求 (14) 2.5.3安全性设计原则 (15) 2.5.4安全性设计方案 (15) 2.6身份认证系统应用开发接口 (17) 2.6.1身份认证系统接口函数 (17)

2.6.2 API与身份认证系统结合开发应用系统 (17) 2.7身份认证系统使用案例 (18) 3.系统配置 (21) 3.1 设备配置 (21)

1. 概述 1.1 前言 随着网络技术的高速发展，个人和企业将越来越多地把业务活动放到网络上，因此网络的安全问题就更加关键和重要。据统计，在全球围，由于信息系统的脆弱性而导致的经济损失，每年达数十亿美元，并且呈逐年上升的趋势。 利用数字证书、PKI、对称加密算法、数字签名、数字信封等加密技术，可以建立起安全程度极高的身份认证系统，确保网上信息有效、安全地进行，从而使信息除发送方和接收方外，不被其他方知悉（性）；保证传输过程中不被篡改（完整性和一致性）；发送方确信接收方不是假冒的（身份的真实性和不可伪装性）；发送方不能否认自己的发送行为（不可抵赖性）。 本方案根据*****的业务流程、管理模式的实施方案，充分运用现代网络信息技术及CA认证体系，建立*****身份认证系统，并可作为公务网CA的配套系统。 1.2 身份认证系统用户认证需求描述 在***********业务发展过程中，为了更好的实现数据资源共享，充分发挥信息化对*********系统发展的促进作用，************将综合开发一套身份认证系统对目前的用户身份进行管理，为社会、相关职能部门以及各级机构提供服务。 在此系统的开发应用过程中，一个重要的任务是解决如何对应用系统用户

统一身份认证系统技术方案

智慧海事一期统一身份认证系统 技术方案

目录 目录...................................................................................................................................................... I 1.总体设计 (2) 1.1设计原则 (2) 1.2设计目标 (3) 1.3设计实现 (3) 1.4系统部署 (4) 2.方案产品介绍 (6) 2.1统一认证管理系统 (6) 2.1.1系统详细架构设计 (6) 2.1.2身份认证服务设计 (7) 2.1.3授权管理服务设计 (10) 2.1.4单点登录服务设计 (13) 2.1.5身份信息共享与同步设计 (15) 2.1.6后台管理设计 (19) 2.1.7安全审计设计 (21) 2.1.8业务系统接入设计 (23) 2.2数字证书认证系统 (23) 2.2.1产品介绍 (23) 2.2.2系统框架 (24) 2.2.3软件功能清单 (25) 2.2.4技术标准 (26) 3.数字证书运行服务方案 (28) 3.1运行服务体系 (28) 3.2证书服务方案 (29) 3.2.1证书服务方案概述 (29) 3.2.2服务交付方案 (30) 3.2.3服务支持方案 (36) 3.3CA基础设施运维方案 (38) 3.3.1运维方案概述 (38) 3.3.2CA系统运行管理 (38) 3.3.3CA系统访问管理 (39) 3.3.4业务可持续性管理 (39) 3.3.5CA审计 (39)

智慧眼社保行业生物识别身份认证解决方案

智慧眼社保行业生物识别身份认证 解决方案 姓名： 学号： 班级：

一、基于社保卡的生物识别身份认证平台 1、平台概述 基于社保卡的生物识别身份认证平台是在遵循社保核三平台标准的基础上开发的集生物识别、认证管理、模板管理、统计决策分析、身份认证子系统等功能于一体的身份认证平台。 平台前端可支撑多种人社业务对身份认证的需求，如：养老金待遇领取资格认证、失业保险金发放签到、工伤保险待遇领取、医疗保险待遇资格认证、网上业务申报身份认证等等，可通过认证子系统针对不同的险种、不同的认证对象进行身份认证。平台后端兼容多种生物识别技术，如：人脸识别、指静脉识别、指纹识别、虹膜识别、掌静脉识别、声纹识别等等。该平台具有较好的兼容性与扩展性，只需要增加相应的生物识别引擎和业务子系统，就能支撑相应的人社业务。

2、功能简述 身份认证平台功能示意图 3、技术优势 自主研发的人脸识别和指静脉识别算法识别率高，识别速度快。 采用生物识别技术，将社保卡与参保用户联系起来，真正实现人卡合一，有效地提供身份识别服务。 兼容多种生物识别技术，支持人脸识别、指静脉识别、指纹识别、虹膜识别、声纹识别等，可根据实际情况和业务需求进行多种选择。 依据“同人同城同模板”的原则，只需要进行一次建模，就可以在人社领域的所有业务系统中共用，大大降低建模投资成本。 身份认证平台具有多个身份认证子系统，满足人社领域内的所有相关业务的身份认证需求，并且各个业务系统可以共享认证结果。 多险种共享终端采集认证设备，大大减少设备部署数量，节约投资成本。 可远程验证，远程管理，不受时间与空间限制，随时随地实现身份认证。

身份管理平台解决方案

身份管理平台解决方案 1. 应用背景 计算机网络和信息技术的迅速发展使得企业信息化的程度不断提高，在企业信息化过程中，诸如OA、CRM、ERP、OSS等越来越多的业务系统应运而生，提高了企业的管理水平和运行效率。与此同时，各个应用系统都有自己的认证体系，随着应用系统的不断增加，一方面企业员工在业务系统的访问过程中，不得不记忆大量的帐户口令，而口令又极易遗忘或泄露，为企业带来损失；另一方面，企业信息的获取途径不断增多，但是缺乏对这些信息进行综合展示的平台。 在上述背景下，企业信息资源的整合逐步提上日程，并在此基础上形成了各业务系统统一认证、单点登录（SSO）和信息综合展示的企业门户（Portal）。现有的门户产品多集中于口令方式的身份认证，如何更安全的进行统一认证，并保证业务系统访问的安全性，成为关注的焦点。 2. 基于CA认证的统一身份管理平台 时代亿信推出的基于CA认证的统一身份管理平台解决方案，以资源整合（业务系统整合和内容整合）为目标，以CA认证和PKI技术为基础，通过对用户身份的统一认证和访问控制，更安全地实现各业务系统的单点登录和信息资源的整合。 平台兼容口令认证、PFX证书文件认证、USB智能卡认证等多种认证方式，并采用SSL 加密通道、关键信息加密签名、访问控制策略等安全技术充分保证身份认证和业务系统访问过程的安全性。 2.1 系统功能及架构 平台的系统架构如图1所示，主要包括以下部分： 门户系统（Portal）：各业务系统信息资源的综合展现； 平台管理系统：平台用户的注册、授权、审计；各业务系统的配置；门户管理； CA系统：平台用户的数字证书申请、签发和管理； 用户统一认证：用户身份的CA数字证书认证、认证过程的SSL加密通道； 单点登录（SSO）：业务系统关联（mapping）、访问控制、访问业务系统时信息的加密签名和SSL加密通道； 图1 基于CA认证的统一身份管理平台架构 2.2 系统的实现和安全机制 2.2.1 用户注册和授权 （1）企业每一个用户在平台完成用户注册，得到自己的统一帐户（passport）； （2）如果采用证书文件或USB智能卡认证方式，则CA系统自动为平台用户签发数字证书，并与用户的统一帐户对应。 （3）注册的用户可以由管理员进行分组，并根据分组设定相应的业务系统访问权限。 2.2.2 业务系统的配置 接受统一认证的业务系统必须完成以下工作： （1）安装业务系统访问前置并配置证书和私钥，用以建立客户端与业务系统之间的SSL 加密通道，并接收处理平台提供的加密签名的用户认证信息； （2）提供关联（mapping）接口和访问验证接口，并在平台进行配置。关联信息主要是平台统一帐户与业务系统用户信息（可能包括业务系统的用户名和密码）的对应关系。

统一身份认证平台

统一身份认证平台设计方案 1）系统总体设计 为了加强对业务系统和办公室系统的安全控管，提高信息化安全管理水平，我们设计了基于PKI/CA技术为基础架构的统一身份认证服务平台。 1.1.设计思想 为实现构建针对人员帐户管理层面和应用层面的、全面完善的安全管控需要，我们将按照如下设计思想为设计并实施统一身份认证服务平台解决方案： 内部建设基于PKI/CA技术为基础架构的统一身份认证服务平台，通过集中证书管理、集中账户管理、集中授权管理、集中认证管理和集中审计管理等应用模块实现所提出的员工帐户统一、系统资源整合、应用数据共享和全面集中管控的核心目标。 提供现有统一门户系统，通过集成单点登录模块和调用统一身份认证平台服务，实现针对不同的用户登录，可以展示不同的内容。可以根据用户的关注点不同来为用户提供定制桌面的功能。 建立统一身份认证服务平台，通过使用唯一身份标识的数字证书即可登录所有应用系统，具有良好的扩展性和可集成性。 提供基于LDAP目录服务的统一账户管理平台，通过LDAP中主、从账户的映射关系，进行应用系统级的访问控制和用户生命周期维护

管理功能。 用户证书保存在USB KEY中，保证证书和私钥的安全，并满足移动办公的安全需求。 1.2.平台介绍 以PKI/CA技术为核心，结合国内外先进的产品架构设计，实现集中的用户管理、证书管理、认证管理、授权管理和审计等功能，为多业务系统提供用户身份、系统资源、权限策略、审计日志等统一、安全、有效的配置和服务。 如图所示，统一信任管理平台各组件之间是松耦合关系，相互支撑又相互独立，具体功能如下： a)集中用户管理系统：完成各系统的用户信息整合，实现用户生 命周期的集中统一管理，并建立与各应用系统的同步机制，简 化用户及其账号的管理复杂度，降低系统管理的安全风险。

统一身份认证与单点登录系统建设方案

福建省公安公众服务平台 统一身份认证及单点登录系统建设方案 福建公安公众服务平台建设是我省公安机关“三大战役”社会管理创新的重点项目之一；目前平台目前已经涵盖了公安厅公安门户网 站及网站群、涵盖了5+N服务大厅、政民互动等子系统；按照规划，平台还必须进一步拓展便民服务大厅增加服务项目，电子监察、微博监管等系统功能，实现集信息公开、网上办事、互动交流、监督评议 功能为一体的全省公安机关新型公众服务平台。平台涵盖的子系统众多，如每个子系统都用自己的身份认证模块，将给用户带来极大的不便；为了使平台更加方便易用，解决各子系统彼此孤立的问题，平台 必须增加统一身份认证、统一权限管理及单点登录功能。 一、建设目标 通过系统的建设解决平台用户在访问各子系统时账户、密码不统一的问题，为用户提供平台的统一入口及功能菜单；使平台更加简便易用，实现“一处登录、全网漫游”。同时，加强平台的用户资料、授权控制、安全审计方面的管理，确保用户实名注册使用，避免给群 众带来安全风险；实现平台各子系统之间资源共享、业务协同、互联 互通、上下联动；达到全省公安机关在线服务集成化、专业化的目标。 二、规划建议 统一身份认证及单点登录系统是福建公安公众服务平台的核心 基础系统；它将统一平台的以下服务功能：统一用户管理、统一身份 认证、统一授权、统一注册、统一登录、统一安全审计等功能。系统 将通过标准接口（WebService接口或客户端jar包或dll动态链接库）向各子系统提供上述各类服务；各业务子系统只要参照说明文档，做适当集成改造，即可与系统对接，实现统一身份认证及单点登录， 实现用户资源的共享，简化用户的操作。

用友U8身份认证解决方案(9)

身份认证解决方案 目前在U8中用户的身份认证支持四种模式：用户+口令(静态密码),动态密码、CA认证和域身份认证，同一时间，一个用户只能使用一种认证方式，但是不同用户可以根据权限，重要程度交叉使用不同的认证方式。 1.设置认证方式 在系统管理模块中增加操作员的时候设置认证方式，默认支持用户+口令，用户可以更改以便于支持其余三种模式。

图一 2.合作伙伴支持的身份认证在U8系统中的使用 2.1易安全动态密码 1.在U8的应用服务器上，安装“易安全动态密码系统”，根据《U8_动态密码安装配置手 册（深圳海月）》进行相关配置。 2.在系统管理里设置认证方式为“动态密码”，如图一所示，默认支持的是静态口令。 3.配置完成后，在客户端登录产品，密码输入框必须输入由设备动态产生的密码才可，如 图二所示： 图二 备注： 两个系统要求用户编码共用，即不论采用哪种认证方式，用户名必须是通过U8的系统管理产生的，易安全动态密码系统支持批量导入U8用户，权限控制必须在系统管理中完成，如果使用动态密码认证，在系统管理增加用户时，可以不考虑密码信息，同时关于密码的安全策略将不起作用。 详细介绍见《U8动态密码解决方案（深圳海月）》 2.2BJCA的证书使用 BJCA支持两种PKI/CA建设模式：企业自建CA和托管CA。 企业自建CA就是企业自己创建和维护根证书，自行颁发证书。用户身份只需要企业内部审查即可，用户唯一标识为自定义名称，比如test、demo等。

托管CA是企业到BJCA申请证书，BJCA使用Public Trust CA体系为其颁发证书，用户的身份要经过BJCA严格审查，默认唯一标识为身份证号码或企业组织机构代码。 具体使用步骤： 1.通过企业自建CA中心或者托管CA中心申请合法的数字证书。 2.在U8的客户端安装BJCA的客户端证书管理工具，请参阅《U8_CA安装配置手册（BJCA）》进行相关配置。 3.在U8的服务器端安装BJCA的服务器端证书管理工具。在安装BJCA服务器端组件时务必填写正确企业系统名称，名称必须是字母或数字，不能含中文。如图三所示： 图三 4.配置完成后，在客户端登录产品，密码输入框输入的是在U8系统设置的用户密码， 点击确定后，验证U8密码正确后，再次弹出证书PIN码的输入框，如图四所示： 图四 输入PIN码，确定后，系统自动验证证书的合法性。 备注： 目前U8系统中的CA认证采用的是传统的用户名（密码）+证书的双重认证，使用CA密码认证同时也要保证系统管理里设置的U8密码也必须正确，安全策略中的密码策略只对U8密码起作用，修改密码也仅修改U8自身的密码。 用户在托管CA申请证书时，必须正确提交企业系统名称。 详细介绍见《U8安全解决方案（BJCA）》 2.3天威诚信的证书使用 天威诚信也支持两种PKI/CA建设模式：第三方托管CA服务和自建型CA系统。 第三方托管CA服务，是指客户通过天威诚信认证中心的现有的CA认证系统直接获取数字证书，用户在本地只要建设少量的CA模块，就可以实现CA认证的功能。 自建型CA系统是指客户购买天威诚信开发的PKI/CA软件，建设一个独立的PKI/CA 系统，除了购买系统软件之外，还包括系统、通信、数据库以及物理安全、网络安全配置、

统一身份认证系统

1.1. 统一身份认证系统 通过统一身份认证平台，实现对应用系统的使用者进行统一管理。实现统一登陆，避免每个人需要记住不同应用系统的登陆信息，包含数字证书、电子印章和电子签名系统。 通过综合管理系统集成，实现公文交换的在线电子签章、签名。 统一身份认证系统和SSL VPN、WEB SSL VPN进行身份认证集成。 2. 技术要求 ?基于J2EE实现，支持JAAS规范的认证方式扩展 ?认证过程支持HTTPS，以保障认证过程本身的安全性 ?支持跨域的应用单点登陆 ?支持J2EE和.NET平台的应用单点登陆 ?提供统一的登陆页面确保用户体验一致 ?性能要求：50并发认证不超过3秒 ?支持联合发文：支持在Office中加盖多个电子印章，同时保证先前加 盖的印章保持有效，从而满足多个单位联合发文的要求。 ?支持联合审批：支持在Office或者网页（表单）中对选定的可识别区 域内容进行电子签名，这样可以分别对不同人员的审批意见进行单独的电 子签名。 ? Office中批量盖章：支持两种批量签章方式： ?用户端批量盖章； ?服务器端批量盖章。 ?网页表单批量签章：WEB签章提供批量表单签章功能，不需要打开单个 表单签章，一次性直接完成指定批量表单签章操作，打开某一表单时，能 正常显示签章，并验证表单完整性。 ?提供相应二次开发数据接口：与应用系统集成使用，可以控制用户只能 在应用系统中签章，不能单独在WORD/EXCEL中签章，确保只有具有权限的人才可以签章,方便二次开发。 ?满足多种应用需求：电子签章客户端软件支持MS Office、WPS、永中 Office、Adobe PDF、AutoCAD等常用应用软件环境下签章，网页签章控件 或电子签章中间件则为几乎所有基于数据库的管理信息系统提供了电子签

统一身份认证系统建设方案

统一身份认证系统建设方案 发布日期：2008-04-01 1.1 研发背景 随着信息技术的不断发展，企业已逐渐建立起多应用、多服务的IT 架构，在信息化建设中起到十分重要的作用。但是各信息系统面向不同管理方向，各有其对应的用户群体、技术架构、权限体系，限制了系统之间的信息共享和信息交换，形成的信息孤岛。同时，每一个信息系统的用户拥有不同的角色（职能），需要操作不同的系统，难以对其需要和拥有的信息和操作进行综合处理，限制信息系统效率的发挥。在这种背景下企业准备实施内网信息门户系统。其中统一身份管理系统是内网信息门户系统的一个重要组成部分。 统一身份管理将分散的用户和权限资源进行统一、集中的管理，统一身份管理的建设将帮助实现内网信息门户用户身份的统一认证和单点登录，改变原有各业务系统中的分散式身份认证及授权管理，实现对用户的集中认证和授权管理，简化用户访问内部各系统的过程，使得用户只需要通过一次身份认证过程就可以访问具有相应权限的所有资源。 1.2 组成架构 汇信科技与SUN公司建立了紧密合作关系，汇信科技推出的统一身份认证解决方案基于SUN公司的Sun Java System Identity Manager和Sun Java System Access Manager以及Sun Java System Directory Server实现。主要包括受控层、统一访问控制系统（统一认证服务器）、统一身份管理系统（统一身份管理服务器）、目录服务器。 受控层位于各应用服务器前端，负责策略的判定和执行，提供AGENT和API两种部署方式。 统一认证服务器安装统一身份认证系统（AM），主要提供身份认证服务和访问控制服务。 统一认证服务器安装统一身份管理系统（IM），主要实现身份配给、流程自动化、委任管理、密码同步和密码重置的自助服务。 目录服务器部署Sun Java System Directory Server,是整个系统的身份信息数据中心。 1.1 功能描述 1.1.1 实现“一次鉴权”（SSO） “一次鉴权（认证和授权）”是指建立统一的资源访问控制体系。用户采用不同的访问手段（如Intranet、PSTN、GPRS等）通过门户系统

XX身份认证系统技术方案

身份认证系统技术方案

目录

1. 概述 前言 随着网络技术的高速发展，个人和企业将越来越多地把业务活动放到网络上，因此网络的安全问题就更加关键和重要。据统计，在全球范围内，由于信息系统的脆弱性而导致的经济损失，每年达数十亿美元，并且呈逐年上升的趋势。 利用数字证书、PKI、对称加密算法、数字签名、数字信封等加密技术，可以建立起安全程度极高的身份认证系统，确保网上信息有效、安全地进行，从而使信息除发送方和接收方外，不被其他方知悉（保密性）；保证传输过程中不被篡改（完整性和一致性）；发送方确信接收方不是假冒的（身份的真实性和不可伪装性）；发送方不能否认自己的发送行为（不可抵赖性）。 本方案根据*****的业务流程、管理模式的实施方案，充分运用现代网络信息技术及CA认证体系，建立*****身份认证系统，并可作为公务网CA的配套系统。 身份认证系统用户认证需求描述 在*****业务发展过程中，为了更好的实现数据资源共享，充分发挥信息化对***系统发展的促进作用，将综合开发一套身份认证系统对目前的用户身份进行管理，为社会、相关职能部门以及各级机构提供服务。 在此系统的开发应用过程中，一个重要的任务是解决如何对应用系统用户进行身份认证从而确保数据的安全。下面将针对在此系统的开发应用中对用户身份认证所做的需求加以说明。 整个系统的逻辑结构如图1所示： 图1：系统逻辑结构示意图 如图1示，整个系统涉及了应用服务器、证书服务器以及相应的客户端。

系统运作流程简述如下： 客户端访问应用服务器，应用服务器向认证服务器发出认证请求； 认证服务器完成对用户身份的认证并将与该用户相对应的认证信息 返回相应的应用服务器； 用户在通过认证之后获得在应用服务器获得相应的授权，从而可以 对应用系统进行相应的访问。 所提交的认证系统在满足上述流程之外需要提供应用开发接口，满足与应用服务器之间的交互。这是将认证系统集成到整个身份认证系统的基础条件，使得后续的开发工作能够利用认证信息做进一步的数据处理。考虑到平台的兼容性，应用系统开发方可以开发一个统一的接口程序与认证系统进行交互。另外还有如下几点要求需注意： 认证服务器的用户信息需要依据数据库服务器中的用户信息为基 础； 对于客户端的身份认证最好采用硬件方式； 客户端通过广域网连接到认证服务器，要求认证服务器是能够面向 广域网用户的； 客户端数量可以按250用户计算； 提供认证系统的安全模式说明，详细介绍如何确保系统的安全； 系统对认证系统的操作系统平台无特殊要求。 身份认证系统认证解决之道 根据身份认证系统的设计原则，系统安全需要解决如下几个方面的问题：数据的保密性。包括数据静态存储的保密性和数据传输过程中的保 密性； 有效的身份认证和权限控制。系统中的各个授权人员具有其特定级 别的权限，可以进行该权限的操作，无法越权操作；操作者事后无 法否认其进行的操作；未授权人员无法进入系统。 我们建议利用业界行之有效的高强度的加解密技术和身份认证技术保证身

统一身份认证权限管理系统方案

统一身份认证权限管理系统 使用说明

目录 第1章统一身份认证权限管理系统 (3) 1.1 软件开发现状分析 (3) 1.2 功能定位、建设目标 (3) 1.3 系统优点 (4) 1.4 系统架构大局观 (4) 1.5物理结构图 (5) 1.6逻辑结构图 (5) 1.7 系统运行环境配置 (6) 第2章登录后台管理系统 (10) 2.1 请用"登录"不要"登陆" (10) 2.2 系统登录 (10) 第3章用户（账户）管理 (11) 3.1 申请用户（账户） (12) 3.2 用户（账户）审核 (14) 3.3 用户（账户）管理 (16) 3.4 分布式管理 (18) 第4章组织机构（部门）管理 (25) 4.1 大型业务系统 (26) 4.2 中小型业务系统 (27) 4.3 微型的业务系统 (28) 4.4 外部组织机构 (29) 第5章角色（用户组）管理 (30) 第6章职员（员工）管理 (34) 6.1 职员（员工）管理 (34) 6.2 职员（员工）的排序顺序 (34) 6.3 职员（员工）与用户（账户）的关系 (35) 6.4 职员（员工）导出数据 (36) 6.5 职员（员工）离职处理 (37) 第7章部通讯录 (39) 7.1 我的联系方式 (39) 7.2 部通讯录 (40) 第8章即时通讯 (41) 8.1 发送消息 (41) 8.2 即时通讯 (43) 第9章数据字典（选项）管理 (1) 9.1 数据字典（选项）管理 (1) 9.2 数据字典（选项）明细管理 (3) 第10章系统日志管理 (4) 10.1 用户（账户）访问情况 (5) 10.2 按用户（账户）查询 (5) 10.3 按模块（菜单）查询 (6) 10.4 按日期查询 (7) 第11章模块（菜单）管理 (1) 第12章操作权限项管理 (1) 第13章用户权限管理 (4) 第14章序号（流水号）管理 (5) 第15章系统异常情况记录 (7) 第16章修改密码 (1) 第17章重新登录 (1) 第18章退出系统 (3)

统一身份认证系统设计与实现

统一身份认证系统设计与实现 随着信息化的日益普及,以及中国信息化建设步伐的逐步加快,信息化正以几何倍数增长的方式支撑着能源、通信、金融、交通、工农业及服务业等各行业的生产建设活动,信息化已成为当前社会生产经营活动必不可少的辅助手段。在此情况下,国家电网公司在“十一五”期间大力发展信息化建设,但随着公司信息化建设的推进,公司各业务部门对本部门业务系统的需求单一性、不可复用性以及管理成本的浪费日见明显,如何利用信息系统为各业务部门创造价值、节约人力成本、提高管理效率的同时,加强各业务系统的统一管控力度、降低信息系统的运行维护成本,并且在不影响当前业务支撑多样性的前提下整合各业务系统数据来源、对面向不用的业务应用提供统一身份、单点登录、身份管理等基础服务变得越来越重要。本文的研究重点是在国网公司内构建一套统一身份认证系统,实现对不同平台、不同数据库之间的业务应用系统的统一支撑管理。本文通过对国家电网公司各部门(单位)以及各业务应用系统现状充分调研的基础上,遵循集成性、安全性、稳定性、先进性等原则,提出了一个基于轻量级目录访问协议的统一身份认证系统的设计框架,利用目录技术实现对各部门(单位)组织架构、各组织层级下的用户信息以及各业务应用基础用户数据的统一管理,任何应用系统均可取消自身用户系统,使用统一身份认证系统的日录数据源作为业务系统的用户数据库：利用反向代理和统一认证技术实现对同一用户登录不同业务应用系统的单点登录,以及同一用户在不同业务应用系统中的权限角色配置；利用身份管理服务技术在强化数据通道安全性的条件下,实现不同数据源之间的数据复制、同步,以及数据复制、同步过程中的属性变更等一系列的过程控制：利用J2EE 架构实现了统一身份管理工具的设计,实现了针对目录数据源的组织架构管理、用户信息管理、应用管理、授权管理等。 本系统在设计中,考虑到国家电网公司信息化建设速度快、系统更新升级频繁、业务需求多、变化快等特点,同地考虑统一身份认证系统自身特点可能带来的单点故障等原因,系统的各个子系统设计相对独立,保证了系统的稳定性的同时,强化了易更新、易集成的特性,为国家电网公司构建全球最大的集团企业级信息系统提供有力支撑,同时,随着统一身份认证系统的逐步完善,将在大规模、多平台信息系统建设中发挥重要的作用。

智慧校园建设方案!高校统一身份认证解决方案

智慧校园建设方案！高校统一身份认证解决方案

1.项目背景 所谓身份认证，就是判断一个用户是否为合法用户的处理过程。而统一身份认证是针对同一网络不同应用系统而言，采用统一的用户电子身份判断用户的合法性。 数字化校园网络中各个应用系统完成的服务功能各不相同，有些应用系统具有较高的独立性，如财务系统，有些应用系统需要协同合作完成某个特定任务，如教学系统、教务系统等。由于这些应用系统彼此之间是松耦合的，各应用系统的建立没有遵循统一的数据标准，数据格式也各不相同，系统间无法实现有效的数据共享，于是便形成了网络环境下的信息孤岛。对于需要使用多个不同应用系统的用户来说，如果各系统各自存储管理一份不同的身份认证方式，用户就需要记忆多个不同的密码和身份，并且用户在进入不同的应用系统时需要进行多次登录。这不仅给用户也给系统管理带来了极大地不便。 随着现在信息技术的发展，校园网络提供的信息服务质量的提升，对信息安全性的要求也越来越高。同时对用户的身份认证、权限管理的要求相应地提高。原来各个应用系统各自为政的身份认证的方式难以达到这个要求。这就必须要有一个统一的、高安全性和高可靠性的身份认证及权限管理系统。该系统可以完成对整个校园网用户的身份和权限管理，保证各应用系统基于统一的模式、集中的环境开发与升级，一方面降低了系统整体运行的维护成本，另一方面保证了整个校园系统能够随着平台的升级而同步升级，方便使用和管理，也保证了整个系统的先进性与安全性。 有了统一身份认证系统，管理员就可以在整个网络内实现单点管理、用户可以实现一次登录、全网通行，各种管理应用系统可以通过统一的接口接入信息平台。对用户的统一管理，一方面用在访问各个成员站点时无需多次注册登录，既给用户的使用带来方便，也为成员站点节约资源，避免各个成员站点分散管理统一用户带来的数据冗余。另一方面也给新的成员站点(新的应用系统)的开发提供方便。 2.参数要点说明 浏览器单次会话当中，通过一次登录就可以访问互相信任的系统。

统一身份认证设计方案(最终版)

统一身份认证设计方案(最终版)

统一身份认证设计方案 日期：2016年2月

目录 1.1 系统总体设计 (5) 1.1.1 总体设计思想5 1.1.2 平台总体介绍6 1.1.3 平台总体逻辑结构7 1.1.4 平台总体部署8 1.2 平台功能说明 (8) 1.3 集中用户管理 (9) 1.3.1 管理服务对象10 1.3.2 用户身份信息设计11 1.3. 2.1 用户类型11 1.3. 2.2 身份信息模型12 1.3. 2.3 身份信息的存储13 1.3.3 用户生命周期管理13 1.3.4 用户身份信息的维护14 1.4 集中证书管理 (15) 1.4.1 集中证书管理功能特点15 1.5 集中授权管理 (17) 1.5.1 集中授权应用背景17 1.5.2 集中授权管理对象18

1.5.3 集中授权的工作原理19 1.5.4 集中授权模式19 1.5.5 细粒度授权20 1.5.6 角色的继承21 1.6 集中认证管理 (22) 1.6.1 集中认证管理特点22 1.6.2 身份认证方式23 1.6. 2.1 用户名/口令认证24 1.6. 2.2 数字证书认证24 1.6. 2.3 Windows域认证24 1.6. 2.4 通行码认证25 1.6. 2.5 认证方式与安全等级25 1.6.3 身份认证相关协议25 1.6.3.1 SSL协议26 1.6.3.2 Windows 域26 1.6.3.3 SAML协议27 1.6.4 集中认证系统主要功能29 1.6.5 单点登录29 1.6.5.1 单点登录技术30 1.6.5.2 单点登录实现流程32 1.7 集中审计管理 (36)