商业源码 ASP.NET 2.0 中的 Windows 身份验证
一 概述
身份验证是一个验证客户端身份的过程 通常采用指定的第三方授权方式 客户端可能是最终用户 计算机 应用程序或服务 客户端的标识称为安全原则 为了使用服务器应用程序进行验证 客户端提供某种形式的凭据来允许服务器验证客户端的标识 确认了客户端的标识后 应用程序可以授予执行操作和访问资源的原则
如果应用程序使用 Active Directory 用户存储 则应该使用集成 Windows 身份验证 对 ASP NET 应用程序使用集成 Windows 身份验证时 最好的方法是使用 ASP NET 的 Windows 身份验证提供程序附带的 Internet 信息服务 （IIS） 身份验证方法 使用该方法 将自动创建一个 windowsprincipal 对象（封装一个 windowsidentity 对象）来表示经过身份验证的用户 您无需编写任何身份验证特定的代码
还支持使用 Windows 身份验证的自定义解决方案（避开了 IIS 身份验证） 例如 可以编写一个根据 Active Directory 检查用户凭据的自定义 ISAPI 筛选器 使用该方法 必须手动创建一个 windowsprincipal 对象
本文阐释在具有 IIS 的 ASP NET 中 Windows 身份验证的工作机制
二 IIS 身份验证
如果 ASP NET 针对 Windows 身份验证进行配置 则 ASP NET 依靠 IIS 利用配置好的身份验证模式对其客户端进行身份验证 IIS 通过检查特定应用程序的元数据库设置来确定其身份验证模式 成功验证某个用户的身份后 IIS 将代表经过身份验证的用户的 Windows 令牌传递给宿主 ASP NET 的 ASP NET 辅助进程 （w wp exe） 如果应用程序使用在 IIS 中配置的虚拟目录来支持匿名访问 该令牌代表匿名 Internet 用户帐户 否则 该令牌代表经过身份验证的用户
iis 支持以下身份验证模式
·匿名 如果不需要对客户端进行身份验证（或者使用自定义身份验证机制 如窗体身份验证） 则可将 IIS 配置为允许匿名访问 在该事件中 IIS 创建一个 Windows 令牌来表示具有相同匿名（或客人）帐户的所有匿名用户 默认的匿名帐户是 IUSR_MACHINENAME 其中 MACHINENAME 是安装期间指定的计算机的 NetBIOS 名称
·基本 基本身份验证要求用户以用户名和密码的形式提供凭据来证明他们的身份 基本身份验证基于 Internet 标准 RFC 所有常用浏览器都支持它 用户的凭据以未加密的 Base 编码格式从浏览器传送到 Web 服务器 为了更好保护这些凭据 只要在使用基本身份验证同时再使用安全套接字层 （SSL） 即可 由于 Web 服务器包含未加密的用户凭据 因此 ASP NET 应用程序可以模拟调用方并使用他们的凭据来访问网络资源
·集成的 Windows 集成的 Windows 身份验证（以前称为 NTLM 也称为 Windows NT 质询/应答身份验证 Windows NT Challenge/Response）是使用 Kerberos v 身份验证还是 NTLM 身份验证 取决于客户端和服务器的配置 服务器与客户端协商确定要使用的协议 如果满足以下条件 则使用 Kerberos 身份验证
· Web 应用程序正在 NeorkService 帐户或自定义域帐户下运行 如果应用程序在本地帐户（如 Windows Server 上的 ASPNET 帐户）上运行 则使用 NTLM 身份验证
·域帐户的 Active Directory 中有一个服务主要名称 （SPN） 该域帐户用于运行客户端进行身份验证所使用的服务
·客户端计算机和服务器计算机至少需要运行 Windows Server 且处在相同的（即信任的）Windows 域中
注 默认情况下 对于 Windows Server 操作系统启用集成 Windows 身份验证 然而 如果 Windows Server Service Pack （SP ） 作为 Windows Server 操作系统整合安装的一部分进行安装 则默认情况下禁用集成 Windows 身份验证 如果使用 SP 升级 Windows Server 则集成 Windows 身份验证的设置与其 Windows Server 设置相同
应该使用集成 Windows 身份验证而不是基本身份验证 因为前者避免了通过网络传输用户凭据 由于 Kerberos v 身份验证支持相互身份验证 因此用户还可以对正在连接的服务器进行身份验证
集成 Windows 身份验证最适合于 Intranet 环境 其中的客户端计算机和 Web 服务器计算机都是相同（即信任的）域的一部分
三 NTLM身份验证
ntlm 是用于 Windows NT 和 Windows Server 工作组环境的身份验证协议 它还用在必须对 Windows NT 系统进行身份验证的混合 Windows Active Directory 域环境中 当 Windows Server 转换为不存在下层 Windows NT 域控制器的本机模式时 禁用 NTLM 然后 Kerberos v 变成企业级的默认身份验证协议
ntlm 身份验证机制
图 显示 NTLM 协议
图 NTLM 质询/应答机制
下面概述质询/应答机制
· 用户请求访问 用户尝试通过提供用户凭据登录到客户端 登录前 客户端计算机缓存密码的哈希值并放弃密码 客户端向服务器发送一个请求 该请求包括用户名以及纯文本格式的请求
· 服务器发送质询消息 服务器生成一个称为质询的 字节随机数（即 NONCE） 并将它发送到客户端
· 客户端发送应答消息 客户端使用由用户的密码生成的一个密码哈希值来加密服务器发送的质询 它以应答的形式将这个加密的质询发回到服务器
· 服务器将质询和应答发送到域控制器 服务器将用户名 原始质询以及应答从客户端计算机发送到域控制器
· 域控制器比较质询和应答以对用户进行身份验证 域控制器获取该用户的密码哈希值 然后使用该哈希值对原始质询进行加密 接下来 域控制器将加密的质询与客户端计算机的应答进行比较 如果匹配 域控制器则发送该用户已经过身份验证的服务器确认
· 服务器向客户端发送应答 假定凭据有效 服务器授予对所请求的服务或资源的客户端访问权
四 Kerberos 身份验证
与 NTLM 身份验证相比 Kerberos 身份验证具有以下优势
· 相互身份验证 当客户端使用 Kerberos v 协议对特定服务器上的特定服务进行身份验证 Kerberos 为客户端提供网络上恶意代码不会模拟该服务的保证
· 委托支持 使用 Kerberos 身份验证对客户端进行身份验证的服务器可以模拟这些客户端 并使用该客户端的安全上下文访问网络资源
· 性能 Kerberos 身份验证提供优于 NTLM 身份验证的改进的性能
· 简化的信任管理 具有多个域的网络不再需要一组复杂的显式 点对点信任关系
· 互操作性 Microsoft 实现的 Kerberos 协议基于向 Internet 工程任务组 （IETF） 推荐的标准跟踪规范 因此 Windows 中协议的实现为与其他网络的互操作奠定了基础（其中 Kerberos 版本 用于身份验证）
kerberos 身份验证机制
图 显示 Kerberos 身份验证协议的简化视图
图 Kerberos 身份验证
当客户端对网络服务进行身份验证之后 kerberos v 协议遵循以下步骤
· 客户端从 KDC 请求 TGT 用户试图通过提供用户凭据登录到客户端 客户端计算机上的 Kerberos 服务向密钥发行中心 （KDC） 发送一个 Kerberos 身份验证服务请求 该请求包含用户名 请求票证授予票证（ticket granting ticket TGT）所获取的服务信息 以及使用用户的长期密钥（即密码）加密的时间戳
注 在 Windows Server 或 Windows Server 操作系统上 域控制器充当 KDC 而 Active Directory 宿主安全帐户数据库
· 身份验证服务发送加密的 TGT 和会话密钥 KDC 为来自 Active Directory 的用户获取长期密钥（即密码） 然后解密随请求一起传送的时间戳 如果该时间戳有效 则用户是真正的用户 KDC 身份验证服务创建一个登录会话密钥 并使用用户的长期密钥对该副本进行加密 然后 该身份验证服务创建一个 TGT 它包括用户信息和登录会话密钥 最后 该身份验证服务使用自己的密钥加密 TGT 并将加密的会话密钥和加密的 TGT 传递给客户端
· 客户端从 TGT 请求服务器访问 客户端使用其长期密钥（即密码）解密登录会话密钥 并在本地缓存它 此外 客户端还将加密的 TGT 存储在它的缓存中 访问网络服务时 客户端向 KDC 票证授予服务（ticket granting service TGS）发送一个包含信息的请求 这些信息包括用户名 使用用户登录会话密钥加密的验证者消息 TGT 以及用户想访问的服务（和服务器）名称
· TGS 发送加密的会话密钥和票证 KDC 上的 TGS 使用自己的密钥解密 KDC 并提取登录会话密钥 它使用该登录会话密钥解密验证者消息（通常是时间戳） 如果验证者消息成功解密 TGS 从 TGT 提取用户信息 并使用用户信息创建一个用于访问该服务的服务会话密钥 它使用该用户的登录会话密钥对该服务会话密钥的一个副本进行加密 创建一个具有服务会话密钥和用户信息的服务票证 然后使用该服务的长期密钥（密码）对该服务票证进行加密 然后 TGS 将加密的服务会话密钥和服务票证添加到客户端
· 客户端发送服务票证 客户端访问服务时 向服务器发送一个请求 该请求包含验证者消息（时间戳） 该消息使用服务会话密钥和服务票证进行加密
· 服务器发送加密的时间戳以进行客户端验证 服务器解密服务票证并提取服务会话密钥 通过使用服务会话密钥 服务器解密验证者消息（时间戳）并计算它 如果验证者通过测试 则服务器使用服务会话密钥对验证者（时间戳）进行加密 然后将验证者传回到客户端 客户端解密时间戳 如果该时间戳与原始时间戳相同 则该服务是真正的 客户端继续连接
服务的主要名称
kerberos v 身份验证协议之所以使用服务的主要名称 （SPN） 原因如下
· 支持相互身份验证
· 允许一个客户端请求票证 进而允许该客户端与特定服务通讯
例如 如果某个客户端需要获得一个票证 并对在侦听端口 运行的计算机 （myserver） 上的特定服务 （myservice） 进行身份验证 则该客户端使用根据该信息构造的名称从 KDC 请求一个票证 如下所示
MyService/MyServer 在 Active Directory 中注册的 SPN 在该名称和运行所请求的服务的域帐户之间维护一个映射 通过使用该机制 恶意用户难以在网络上模拟服务 恶意用户必须禁用实际服务并从该网络移除实际服务器 然后 恶意用户必须向网络中添加一台同名的新计算机并公开重复的服务 由于客户端使用具有相互身份验证的 Kerberos v 协议 因此该客户端将无法使用重复的服务 除非它可以提供配置实际服务进行运行的域帐户的密码
五 ASP NET身份验证
iis 向 ASP NET 传递代表经过身份验证的用户或匿名用户帐户的令牌 该令牌在一个包含在 iprincipal 对象中的 iidentity 对象中维护 iprincipal 对象进而附加到当前 Web 请求线程 可以通过 属性访问 iprincipal 和 iidentity 对象 这些对象和该属性由身份验证模块设置 这些模块作为 HTTP 模块实现并作为 ASP NET 管道的一个标准部分进行调用 如图 所示
图 ASP NET 管道
管道模型包含一个 application 对象 多个 HTTP 模块对象 以及一个 HTTP 处理程序对象及其相关的工厂对象 runtime 对象用于处理序列的开头 在整个请求生命周期中 context 对象用于传递有关请求和响应的详细信息
有关 ASP NET 请求生命周期的详细信息 请参阅 ASP NET Life Cycle 网址是 （en US VS ） aspx
身份验证模块
在计算机级别的 nfig 文件中定义一组 HTTP 模块 其中包括大量身份验证模块 如下所示
<Modules> <add name= WindowsAuthentication type= System Web Security WindowsAuthenticationModule /> <add name= FormsAuthentication type= System Web Security FormsAuthenticationModule /> <add name= PassportAuthentication type= System Web Security PassportAuthenticationModule /></Modules>
只加载一个身份验证模块 这取决于该配置文件的 authentication 元素中指定了哪种身份验证模式 该身份验证模块创建一个 iprincipal 对象并将它存储在 属性中 这是很关键的 因为其他授权模块使用该 iprincipal 对象作出授权决定
当 IIS 中启用匿名访问且 authentication 元素的 mode 属性设置为 none 时 有一个特殊模块将默认的匿名原则添加到 属性中 因此 在进行身份验证之后 绝不是一个空引用（在 Visual Basic 中为 nothing）
windowsauthenticationmodule
如果 nfig 文件包含以下元素 则激活 windowsauthenticationmodule 类
<authentication mode= Windows /> WindowsAuthenticationModule 类负责创建 windowsprincipal 和 windowsidentity 对象来表示经过身份验证的用户 并且负责将这些对象附加到当前 Web 请求
对于 Windows 身份验证 遵循以下步骤
· WindowsAuthenticationModule 使用从 IIS 传递到 ASP NET 的 Windows 访问令牌创建一个 windowsprincipal 对象 该令牌包装在 context 类的 workerrequest 属性中 引发 authenticaterequest 事件时 windowsauthenticationmodule 从 context 类检索该令牌并创建 windowsprincipal 对象 用该 windowsprincipal 对象进行设置 它表示所有经过身份验证的模块和 ASP NET 页的经过身份验证的用户的安全上下文
· WindowsAuthenticationModule 类使用 P/Invoke 调用 Win 函数并获得该用户所属的 Windows 组的列表 这些组用于填充 windowsprincipal 角色列表
· WindowsAuthenticationModule 类将 windowsprincipal 对象存储在 属性中 随后 授权模块用它对经过身份验证的用户授权
注 defaultauthenticationmodule 类（也是 ASP NET 管道的一部分）将 thread currentprincipal 属性设置为与 属性相同的值 它在处理 authenticaterequest 事件之后进行此操作
授权模块
WindowsAuthenticationModule 类完成其处理之后 如果未拒绝请求 则调用授权模块 授权模块也在计算机级别的 nfig 文件中的 modules 元素中定义 如下所示
<Modules> <add name= UrlAuthorization type= System Web Security UrlAuthorizationModule /> <add name= FileAuthorization type= System Web Security FileAuthorizationModule /> <add name= AnonymousIdentification type= System Web Security AnonymousIdentificationModule /></Modules> urlauthorizationmodule
调用 urlauthorizationmodule 类时 它在计算机级别或应用程序特定的 nfig 文件中查找 authorization 元素 如果存在该元素 则 urlauthorizationmodule 类从 属性检索 iprincipal 对象 然后使用指定的动词（GET POST 等）来确定是否授权该用户访问请求的资源
fileauthorizationmodule
接下来 调用 fileauthorizationmodule 类 它检查 属性中的 iidentity 对象是否是 windowsidentity 类的一个实例 如果 iidentity 对象不是 windowsidentity 类的一个实例 则 fileauthorizationmodule 类停止处理
如果存在 windowsidentity 类的一个实例 则 fileauthorizationmodule 类调用 accesscheck Win 函数（通过 P/Invoke）来确定是否授权经过身份验证的客户端访问请求的文件 如果该文件的安全描述符的随机访问控制列表 （DACL） 中至少包含一个 read 访问控制项 （ACE） 则允许该请求继续 否则 fileauthorizationmodule 类调用 方法并将状态码 返回到客户端
六 安全上下文
net Framework 使用以下两个接口封装 Windows 令牌和登录会话
· System Security Principal IPrincipal
· System Security Principal IIdentity（它公开为 iprincipal 接口中的一个属性 ）
在 ASP NET 中 用 windowsprincipal 和 windowsidentity 类表示使用 Windows 身份验证进行身份验证的用户的安全上下文 使用 Windows 身份验证的 ASP NET 应用程序可以通过 属性访问 windowsprincipal 类
要检索启动当前请求的 Windows 经过身份验证的用户的安全上下文 使用以下代码
using System Security Principal; // Obtain the authenticated user s IdentityWindowsPrincipal winPrincipal = (WindowsPrincipal)HttpContext Current User;
windowsidentity getcurrent
WindowsIdentity GetCurrent 方法可用于获得当前运行的 Win 线程的安全上下文的标识 如果不使用模拟 线程继承 IIS （默认情况下的 NeorkService 帐户）上进程的安全上下文
该安全上下文在访问本地资源时使用 通过使用经过身份验证的初始用户的安全上下文或使用固定标识 您可以使用模拟重写该安全上下文
要检索运行应用程序的安全上下文 使用以下代码
using System Security Principal; // Obtain the authenticated user s identity WindowsIdentity winId = WindowsIdentity GetCurrent();WindowsPrincipal winPrincipal = new WindowsPrincipal(winId); thread currentprincipal
应用程序中的每个线程公开一个 currentprincipal 对象 该对象保存经过身份验证的初始用户的安全上下文 该安全上下文可用于基于角色的授权
要检索线程的当前原则 使用以下代码
using System Security Principal; // Obtain the authenticated user s identityWindowsPrincipal winPrincipal = (WindowsPrincipal) Thread CurrentPrincipal(); 表 显示从各种标识属性获得的结果标识 当您的应用程序使用 Windows 身份验证且 IIS 配置为使用集成 Windows 身份验证时 可以从 ASP NET 应用程序使用这些标识属性
表 线程公开的 CurrentPrincipal Object nfig 设置 变量位置 结果标识
<identity impersonate= true /><authentication mode= Windows />
HttpContextWindowsIdentity线程
Domain\UserNameDomain\UserNameDomain\UserName
<identity impersonate= false /><authentication mode= Windows />
HttpContextWindowsIdentity线程
Domain\UserNameNT AUTHORITY\NEORK SERVICEDomain\UserName
<identity impersonate= true /><authentication mode= Forms />
HttpContextWindowsIdentity线程
用户提供的名称Domain\UserName用户提供的名称
<identity impersonate= false /><authentication mode= Forms />
HttpContextWindowsIdentity线程
用户提供的名称NT AUTHORITY\NEORK SERVICE用户提供的名称
七 模拟
应用程序可以使用模拟来执行操作 使用经过身份验证的客户端或特定 Windows 帐户的安全上下文来访问资源
初始用户模拟
要模拟初始（经过身份验证的）用户 请在 nfig 文件中使用以下配置
<authentication mode= Windows /><identity impersonate= true /> 使用该配置 始终模拟经过身份验证的用户 且所有资源访问均使用经过身份验证的用户的安全上下文执行 如果您的应用程序的虚拟目录上启用了匿名访问 则模拟 IUSR_MACHINENAME 帐户
要暂时模拟经过身份验证的调用方 将 identity 元素的 impersonate 属性设置为 false 然后使用以下代码
using System Security Principal; // Obtain the authenticated user s identity WindowsIdentity winId = (WindowsIdentity)HttpContext Current User Identity; WindowsImpersonationContext ctx = null; try { // Start impersonating ctx = winId Impersonate(); // Now impersonating // Access resources using the identity of the authenticated user } // Prevent exceptions from propagating catch { } finally { // Revert impersonation if (ctx != null) ctx Undo(); } // Back to running under the default ASP NET process identity
这段代码模拟经过身份验证的初始用户 在 对象中维护初始用户的标识和 Windows 令牌
固定标识模拟
如果需要在应用程序的整个生命周期中模拟相同的标识 可以在 nfig 文件中的 identity 元素上指定凭据 以下示例显示如何模拟名为 TestUser 的 Windows 帐户
如果使用该方法 应该对这些凭据进行加密 使用 ASP NET 您可以使用 ASP NET IIS 注册工具 （Aspnet_regiis exe） 使用 ASP NET 版 您可以使用 Aspnet_setreg exe 实用工具 有关该实用工具的详细信息 请参阅 ？url=/library/en us/cptools//cpgrfaspnetiisregistrationtoolaspnet_regiisexe asp
要在 ASP NET 应用程序中使用固定标识进行资源访问 可使用 Windows Server 或 Windows Server 上的 identity 元素来配置凭据 如果正在运行 Windows Server 其中的 IIS 配置为运行在辅助进程隔离模式下（默认情况） 则可通过将 ASP NET 应用程序配置为在自定义应用程序池（在特定的域标识下运行）中运行来避免模拟 然后 可以使用指定的域标识访问资源而无需使用模拟
八 委托
模拟只提供对本地资源的访问 委托是一个扩展的模拟功能 它允许您使用模拟令牌访问网络资源
如果应用程序使用 Kerberos v 身份验证对其用户进行身份验证 则可使用 Kerberos 委托在应用程序的各层传递用户标识并访问网络资源 如果应用程序不使用 Kerberos v 身份验证 则可使用协议转换切换到 Kerberos 然后使用委托传递该标识
windows Server 中的约束委托需要 Kerberos 身份验证 如果您的应用程序无法使用 Kerberos 身份验证对其调用方进行身份验证 您可以使用协议转换从可选的非 Windows 身份验证模式（如 窗体或证书身份验证）切换到 Kerberos 身份验证 然后 可使用具有约束委托的 Kerberos 访问下游网络资源
约束的和未约束的委托
windows Server 上的 Kerberos 委托是未约束的 Active Directory 中配置了委托的服务器可在使用模拟的用户安全上下文的同时访问任何网络资源或网络上的任何计算机 这会带来潜在的安全威胁 尤其是 Web 服务器遭受恶意用户攻击时
为了解决该安全问题 windows Server 引入了约束的委托 这使管理员能够在使用模拟的用户安全上下文时准确指定另一个服务器或域帐户可以访问的服务
配置委托
要使用 Kerberos 委托 需要适当的 Active Directory 配置
要授予 Web 服务器委托客户端凭据的权限 请按以下方式配置 Active Directory
· 如果在 NeorkService 帐户下运行应用程序 Web 服务器计算机帐户必须在 Active Directory 中标记为受信任委托
· 如果在自定义域帐户下运行应用程序 该用户帐户必须在 Active Directory 中标记为受信任委托
· 如果应用程序模拟一个用户帐户 请确保应用程序模拟的用户帐户在 Active Directory 中未标记为 敏感帐户 不能被委托
有关协议转换和约束委托的详细信息 请参阅 How To Use Protocol Transition and Constrained Delegation in ASP NET
lishixinzhi/Article/program/net/201311/13414
最近一段时间都在折腾安全（Security）方面的东西，比如Windows认证、非对称加密、数字证书、数字签名、TLS/SSL、WS-Security等。如果时间允许，我很乐意写一系列的文章与广大网友分享、交流。对于很多读者来说，今天讨论的可能是一个既熟悉、又陌生的话题——Windows认证。目录
一、Kerberos认证简介
四、凭票入场一、Kerberos认证简介Windows认证协议有两种NTLM（NT LAN Manager）和Kerberos，前者主要应用于用于Windows NT 和 Windows 2000 Server（or Later） 工作组环境，而后者则主要应用于Windows 2000 Server（or Later） 域（Domain）环境。Kerberos较之NTLM更高效、更安全，同时认证过程也相对复杂。Kerberos这个名字来源于希腊神话，是冥界守护神兽的名字。Kerberos是一个三头怪兽，之所以用它来命名一种完全认证协议，是因为整个认证过程涉及到三方：客户端、服务端和KDC（Key Distribution Center）。在Windows域环境中，KDC的角色由DC（Domain Controller）来担当。某个用户采用某个域帐号登录到某台主机，并远程访问处于相同域中另一台主机时，如何对访问者和被访问者进行身份验证（这是一种双向的验证）？这就是Kerberos需要解决的场景。接下来我尽量以比较直白的语言来介绍我所知道的Kerberos认证的整个流程。Kerberos实际上是一种基于票据（Ticket）的认证方式。客户端要访问服务器的资源，需要首先购买服务端认可的票据。也就是说，客户端在访问服务器之前需要预先买好票，等待服务验票之后才能入场。在这之前，客户端需要先买票，但是这张票不能直接购买，需要一张认购权证。客户端在买票之前需要预先获得一张认购权证。这张认购权证和进入服务器的入场券均有KDC发售。右图（点击看大图）一张图基本揭示了Kerberos整个认证的过程。二、如何获得“认购权证”？首先，我们来看看客户端如何获得“认购权证”。这里的认购权证有个专有的名称——TGT（Ticket Granting Ticket），而TGT的是KDC一个重要的服务——认证服务（KAS：Kerberos Authentication Service）。当某个用户通过输入域帐号和密码试图登录某台主机的时候，本机的Kerberos服务会向KDC的认证服务发送一个认证请求。该请求主要包括两部分内容，明文形式的用户名和经过加密的用于证明访问者身份的Authenticator（我实在找不到一个比较贴切的中文翻译没，Authenticator在这里可以理解为仅限于验证双反预先知晓的内容，相当于联络暗号）。当KDC接收到请求之后，通过AD获取该用户的信息。通过获取的密码信息生成一个秘钥对Authenticator进行解密。如果解密后的内容和已知的内容一致，则证明请求着提供的密码正确，即确定了登录者的真实身份。KAS成功认证对方的身份之后，会先生成一个用于确保该用户和KDC之间通信安全的会话秘钥——Logon Session Key，并采用该用户密码派生的秘钥进行加密。KAS接着为该用户创建“认购权证”——TGT。TGT主要包含两方面的内容：用户相关信息和Logon Session Key，而整个TGT则通过KDC自己的密钥进行加密。最终，被不同密钥加密的Logon Session Key和TGT返回给客户端。（以上的内容对应流程图中的步骤1、2）三、如何通过“认购权证”购买“入场券”？经过上面的步骤，客户端获取了购买进入同域中其他主机入场券的“认购凭证”——TGT，以及Logon Session Key，它会在本地缓存此TGT和Logon Session Key。如果现在它需要访问某台服务器的资源，它就需要凭借这张TGT向KDC购买相应的入场券。这里的入场券也有一个专有的名称——服务票据（ST：Service Ticket）。具体来说，ST是通过KDC的另一个服务TGS（Ticket Granting Service）出售的。客户端先向TGS发送一个ST购买请求，该请求主要包含如下的内容：客户端用户名；通过Logon Session Key加密的Authenticator；TGT和访问的服务器（其实是服务）名。TGS接收到请求之后，现通过自己的密钥解密TGT并获取Logon Session Key，然后通过Logon Session Key解密Authenticator，进而验证了对方的真实身份。TGS存在的一个根本的目有两点：其一是避免让用户的密码客户端和KDC之间频繁传输而被窃取。其二是因为密码属于Long Term Key（我们一般不会频繁的更新自己的密码），让它作为加密密钥的安全系数肯定小于一个频繁变换得密钥（Short Term Key）。而这个Short Term Key就是Logon Session Key，它确保了客户端和KDC之间的通信安全。TGS完成对客户端的认证之后，会生成一个用于确保客户端-服务器之间通信安全的会话秘钥——Service Session Key，该会话秘钥通过Logon Session Key进行加密。然后出售给客户端需要的入场券——ST。ST主要包含两方面的内容：客户端用户信息和Service Session Key，整个ST通过服务器密码派生的秘钥进行加密。最终两个被加密的Service Session Key和ST回复给客户端。（以上的内容对应流程图中的步骤3、4）四、凭票入场客户端接收到TGS回复后，通过缓存的Logon Session Key解密获取Service Session Key。同时它也得到了进入服务器的入场券——ST。那么它在进行服务访问的时候就可以借助这张ST凭票入场了。该Serivce Session Key和ST会被客户端缓存。但是，服务端在接收到ST之后，如何确保它是通过TGS购买，而不是自己伪造的呢？这很好办，不要忘了ST是通过自己密码派生的秘钥进行加密的。具体的操作过程是这样的，除了ST之外，服务请求还附加一份通过Service Session Key加密的Authenticator。服务器在接收到请求之后，先通过自己密码派生的秘钥解密ST，并从中提取Service Session Key。然后通过提取出来的Service Session Key解密Authenticator，进而验证了客户端的真实身份。实际上，到目前为止，服务端已经完成了对客户端的验证，但是，整个认证过程还没有结束。谈到认证，很多人都认为只是服务器对客户端的认证，实际上在大部分场合，我们需要的是双向验证（Mutual Authentication）——访问者和被访问者互相验证对方的身份。现在服务器已经可以确保客户端是它所声称的那么用户，客户端还没有确认它所访问的不是一个钓鱼服务呢。为了解决客户端对服务器的验证，服务要需要将解密后的Authenticator再次用Service Session Key进行加密，并发挥给客户端。客户端再用缓存的Service Session Key进行解密，如果和之前的内容完全一样，则可以证明自己正在访问的服务器和自己拥有相同的Service Session Key，而这个会话秘钥不为外人知晓（以上的内容对应流程图中的步骤5、6）以上的内容仅仅讲述的是基于Kerberos的Windows认证的大体流程，并不涉及到一些细节的东西，比如如何确保时间的同步，如何抵御Replay Attack等。此外，由于本文对Windows底层的知识有限，不能确保所有的内容都是完全正确，如有错误，还往不吝指正。Windows安全认证是如何进行的？[NTLM篇]
一，业务分析
在分布式系统架构中，假设把上述的三个子系统部署在三个不同的服务器上。前提是用户登录之后才能访问这些子系统。那么使用传统方式，可能会存在这样的问题：
1当访问用户中心，需要用户登录帐号
2当访问购物车，还需要用户登录帐号
3当访问商品结算，又一次需要用户登录帐号
访问每一个子系统都需要用户登录帐号，这样的体验对于用户来说是极差。而使用单点登录就可以很好地解决上述的问题。
二，单点登录
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO 的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
我们目前的系统存在诸多子系统，而这些子系统是分别部署在不同的服务器中，那么使用传统方式的 session 是无法解决的，我们需要使用相关的单点登录技术来解决。
第一步 ：用户访问应用系统1。过滤器判断用户是否登录，没有登录，则重定向（302）到认证系统去进行认证操作。
第二步 ：重定向到认证系统，显示登录界面，用户输入用户名密码。认证系统将用户登录的信息记录到服务器的session中。
第三步 ：认证系统给浏览器发送一个特殊的凭证ticket，浏览器将凭证交给应用系统1，应用系统1则拿着浏览器交给他的凭证ticket去认证系统验证凭证ticket是否有效。凭证ticket若是有效，将用户信息保存到应用系统1的session中一份，并告知应用系统1，用户通过认证。
第四步 ：用户通过认证，浏览器与网站之间进行正常的访问。
第五步 ：当用户再次访问应用系统1，由于应用系统1的session中有用户信息，所以就不用经过认证系统认证，就可以直接访问应用系统1了。
第六步 ：当用户再去访问其他应用系统时，浏览器会带着凭证ticket过去，其他应用系统到认证系统验证凭证，凭证ticket若是有效，将用户信息保存到其他应用系统的session中一份，并告知其他应用系统，用户通过认证。
第七步 ：用户通过认证，浏览器与网站之间进行正常的访问。
第八步 ：当用户再次访问其他应用系统，由于其他应用系统的session中有用户信息，所以就不用经过认证系统认证，就可以直接访问其他应用系统了。
三、Yelu大学研发的CAS(Central Authentication Server)
1什么是CAS？
CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点：
1开源的企业级单点登录解决方案。
2CAS Server 为需要独立部署的 Web 应用。这个CAS框架已经提供
3CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括Java, Net, PHP, Perl, Apache, uPortal, Ruby 等。
从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。下图是 CAS 最基本的协议过程：
2CAS的详细登录流程
该图主要描述
1第一次访问http://shoppingxiaoguicom
2在登录状态下第二次访问http://shoppingxiaoguicom
3在登录状态下第一次访问http://payxiaoguicom
下面对图中序号代表的操作进行说明
当用户第一次访问http://shoppingxiaoguicom
序号1: 用户请求http://shoppingxiaoguicom，会经过AuthenticationFilter认证过滤器(在cas client 的webxml中配置)
主要作用：判断是否登录，如果没有登录则重定向到认证中心。
大概知道这个就行，CAS的具体实现会在以后的博客中写道
序号2: AuthenticationFilter发现用户没有登录，则返回浏览器重定向地址。
重定向的地址就是认证服务器CAS Server的地址，后面的参数是我们请求的客户端地址，这个参数目的就是为了认证成功以后，根据这个参数的地址重定向回请求的客户端
序号3: 浏览器根据响应回来的重定向地址，向casxiaoguicom认证系统发出请求
序号4: 认证系统casxiaoguicom接收请求，响应登陆页面
序号5: ：用户登陆页面输入用户名密码，提交请求
序号6: ：CAS Server 认证服务器接收用户名和密码，就行验证，验证逻辑CAS Server 已经实现，并响应给浏览器信息
这里的用户名，密码不需要关心，后续会讲到
图中1，2部分表示序号5 输入的用户名，密码，以及发出的请求。当认证服务器验证通过之后，根据请求参数service的值，进行重定向，其实就是回到了请求的客户端，同时会携带一个ticket令牌参数。同时会在Cookie中设置一个TGC，该cookie是网站认证系统casxiaoguicom的cookie，只有访问这个网站才会携带这个cookie过去。
注意：这个携带TGC的Cookie是实现CAS单点登录的关键所在！
Cookie中的TGC：向cookie中添加该值的目的是当下次访问casxiaoguicom认证系统时，浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。
TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）
TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。
ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面数字3处的ticket值。
序号7: 客户端拿到请求中的ticket信息，也就是图中1的位置
然后经过一个ticket过滤器Cas20ProxyReceivingTicketValidationFilter，去认证系统CAS Server判断ticket是否有效
这个过滤器的主要工作就是校验客户端传过来的ticket是否有效
CAS Client 客户端 shoppingxiaoguicom 中webxml的配置
序号8: 向CAS Server认证系统发出验证ticket的请求，也就是图中2的位置，然后执行ticket验证
序号9: 通过校验之后，把用户信息保存到客户端的session中，并把客户端的SessionID设置在Cookie中，同时告知客户端ticket有效。当用户再次访问该客户端，就可以根据Cookie 中的SessionID找到客户端的Session，获取用户信息，就不用再次进行验证了。也就是图中响应给浏览器的部分。
序号10: shoppingxiaoguicom客户端接收到cas-server的返回，知道了用户已经登录，ticket有效，告知浏览器可以进行访问。
至此，用户第一次访问流程结束。
当用户第二次访问http://shoppingxiaoguicom
序号11: 当用户第二次访问，仍然会经过AuthenticationFilter过滤器，但与第一次访问不同的是此时客户端session中已经存在用户的信息，浏览器中的Cookie会根据SessionID找到Session，获取用户信息，所以不需要进行验证，可以直接访问。
序号12: 客户端告知浏览器可以进行访问。
当用户第一次访问http://payxiaoguicom
序号13: 用户向payxiaoguicom CAS Client客户端发出请求
序号14: ：payxiaoguicom接收到请求，发现第一次访问，于是给他一个重定向的地址，让他去找认证中心登录。
序号15: 浏览器根据上面响应的地址，发起重定向，因为之前访问过一次了，因此这次会携带上次返回的Cookie：TGC到认证中心。
序号16: 认证中心收到请求，发现TGC对应了一个TGT，于是用TGT签发一个ticket，并且返回给浏览器，让他重定向到payxiaoguicomCAS Client客户端。
序号17: 根据上面响应回来的地址，进行重定向到payxiaoguicomCAS Client客户端
序号18: payxiaoguicomCAS Client客户端带着ticket去认证中心验证是否有效。
序号19: 认证成功，把用户信息保存到客户端的session中，并把客户端的SessionID设置在Cookie中。当用户下次访问payxiaoguicomCAS Client客户端，直接登录，无需验证。
序号20: 告知浏览器可以进行访问
CAS单点登录的原理分析大致就是上述的这些，至于CAS单点登录的具体实现，将在下篇博客中写道。
11 What is CAS ？
CAS （ Central Authentication Service ） 是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。
CAS 开始于 2001 年， 并在 2004 年 12 月正式成为 JA-SIG 的一个项目。
12 主要特性
1、 开源的、多协议的 SSO 解决方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML11 、 SAML20 等。
2、 支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X509 Certificates 等；
3、 安全策略：使用票据（ Ticket ）来实现支持的认证协议；
4、 支持授权：可以决定哪些服务可以请求和验证服务票据（ Service Ticket ）；
5、 提供高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；
6、 支持多种客户端： Java 、 Net 、 PHP 、 Perl 、 Apache, uPortal 等。
2 SSO 单点登录原理
本文内容主要针对 Web SSO 。
21 什么是SSO
单点登录（ Single Sign-On , 简称 SSO ）是目前比较流行的服务于企业业务整合的解决方案之一， SSO 使得在多个应用系统中，用户只需要 登录一次 就可以访问所有相互信任的应用系统。
22 SSO 原理
221 SSO 体系中的角色
一般 SSO 体系主要角色有三种：
1、 User （多个）
2、 Web 应用（多个）
3、 SSO 认证中心（ 1 个 ）
222 SSO 实现模式的原则
SSO 实现模式一般包括以下三个原则：
1、 所有的认证登录都在 SSO 认证中心进行；
2、 SSO 认证中心通过一些方法来告诉 Web 应用当前访问用户究竟是不是已通过认证的用户；
3、 SSO 认证中心和所有的 Web 应用建立一种信任关系，也就是说 web 应用必须信任认证中心。（单点信任）
223 SSO 主要实现方式
SSO 的主要实现方式有：
1、 共享 cookies
基于共享同域的 cookie 是 Web 刚开始阶段时使用的一种方式，它利用浏览同域名之间自动传递 cookies 机制，实现两个域名之间系统令牌传递问题；另外，关于跨域问题，虽然 cookies 本身不跨域，但可以利用它实现跨域的 SSO 。如：代理、暴露 SSO 令牌值等。
缺点：不灵活而且有不少安全隐患，已经被抛弃。
2、 Broker-based( 基于经纪人 )
这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的 " 第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （凭证库思想 ) 等。 Kerberos 是由麻省理工大学发明的安全认证服务，已经被 UNIX 和 Windows 作为默认的安全认证服务集成进操作系统。
3、 Agent-based （基于代理人）
在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如，它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个 " 翻译 " 。例如 SSH 等。
4、 Token-based
例如 SecureID,WebID ，现在被广泛使用的口令认证，比如 FTP 、邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。
5、 基于网关
6、 基于 SAML
SAML(Security Assertion Markup Language ，安全断言标记语言）的出现大大简化了 SSO ，并被 OASIS 批准为 SSO 的执行标准 。开源组织 OpenSAML 实现了 SAML 规范。
3 CAS 的基本原理
31 结构体系
从结构体系看， CAS 包括两部分： CAS Server 和 CAS Client 。
311 CAS Server
CAS Server 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 / 密码等凭证 (Credentials) 。
312 CAS Client
负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。
CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。
32 CAS 原理和协议
321 基础模式
基础模式 SSO 访问流程主要有以下步骤：
1 访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。
2 定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。
3 用户认证：用户身份认证。
4 发放票据： SSO 服务器会产生一个随机的 Service Ticket 。
5 验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。
6 传输用户信息： SSO 服务器验证票据通过后，传输用户认证结果信息给客户端。
下面是 CAS 最基本的协议过程：
cas基础协议图
基础协议图
如上图： CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同时， CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket( ST 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的；于是 CAS Client 会重定向用户请求到 CAS Server （ Step 2 ），并传递 Service （要访问的目的资源地址）。 Step 3 是用户认证过程，如果用户提供了正确的 Credentials ， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，并且重定向用户到 Service 所在地址（附带刚才产生的 Service Ticket ） , 并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ） ； CAS Client 在拿到 Service 和新产生的 Ticket 过后，在 Step 5 和 Step6 中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。
在该协议中，所有与 CAS Server 的交互均采用 SSL 协议，以确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向 的过程。但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的（使用 HttpsURLConnection ）。
CAS 请求认证时序图如下：
cas认证时序图
321 CAS 如何实现 SSO
当用户访问另一个应用的服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：
1) 如果 User 持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果；
2) 如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。
322 CAS 代理模式
该模式形式为用户访问 App1 ， App1 又依赖于 App2 来获取一些信息，如： User -->App1 -->App2 。
这种情况下，假设 App2 也是需要对 User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致 User 的 IE 窗口不停地闪动 ) ， CAS 引入了一种 Proxy 认证机制，即 CAS Client 可以代理用户去访问其它 Web 应用。
代理的前提是需要 CAS Client 拥有用户的身份信息 ( 类似凭据 ) 。之前我们提到的 TGC 是用户持有对自己身份信息的一种凭据，这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借 TGC ， User 可以免去输入密码以获取访问其它服务的 Service Ticket ，所以，这里凭借 PGT ， Web 应用可以代理用户去实现后端的认证，而 无需前端用户的参与 。
下面为代理应用（ helloService ）获取 PGT 的过程： （注： PGTURL 用于表示一个 Proxy 服务，是一个回调链接； PGT 相当于代理证； PGTIOU 为取代理证的钥匙，用来与 PGT 做关联关系；）
cas代理PGT获取
如上面的 CAS Proxy 图所示， CAS Client 在基础协议之上，在验证 ST 时提供了一个额外的 PGT URL( 而且是 SSL 的入口 ) 给 CAS Server ，使得 CAS Server 可以通过 PGT URL 提供一个 PGT 给 CAS Client 。
CAS Client 拿到了 PGT(PGTIOU-85 … ti2td) ，就可以通过 PGT 向后端 Web 应用进行认证。
下面是代理认证和提供服务的过程：
如上图所示， Proxy 认证与普通的认证其实差别不大， Step1 ， 2 与基础模式的 Step1,2 几乎一样，唯一不同的是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。
323 辅助说明
CAS 的 SSO 实现方式可简化理解为： 1 个 Cookie 和 N 个 Session 。 CAS Server 创建 cookie ，在所有应用认证时使用，各应用通过创建各自的 Session 来标识用户是否已登录。
用户在一个应用验证通过后，以后用户在同一浏览器里访问此应用时，客户端应用中的过滤器会在 session 里读取到用户信息，所以就不会去 CAS Server 认证。如果在此浏览器里访问别的 web 应用时，客户端应用中的过滤器在 session 里读取不到用户信息，就会去 CAS Server 的 login 接口认证，但这时 CAS Server 会读取到浏览器传来的 cookie （ TGC ），所以 CAS Server 不会要求用户去登录页面登录，只是会根据 service 参数生成一个 Ticket ，然后再和 web 应用做一个验证 ticket 的交互而已。
33 术语解释
CAS 系统中设计了 5 中票据： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。
Ø Ticket-granting cookie(TGC) ：存放用户身份认证凭证的 cookie ，在浏览器和 CAS Server 间通讯时使用，并且只能基于安全通道传输（ Https ），是 CAS Server 用来明确用户身份的凭证；
Ø Service ticket(ST) ：服务票据，服务的惟一标识码 , 由 CAS Server 发出（ Http 传送），通过客户端浏览器到达业务服务器端；一个特定的服务只能有一个惟一的 ST ；
Ø Proxy-Granting ticket （ PGT ）：由 CAS Server 颁发给拥有 ST 凭证的服务， PGT 绑定一个用户的特定服务，使其拥有向 CAS Server 申请，获得 PT 的能力；
Ø Proxy-Granting Ticket I Owe You （ PGTIOU ） : 作用是将通过凭证校验时的应答信息由 CAS Server 返回给 CAS Client ，同时，与该 PGTIOU 对应的 PGT 将通过回调链接传给 Web 应用。 Web 应用负责维护 PGTIOU 与 PGT 之间映射关系的内容表；
Ø Proxy Ticket (PT) ：是应用程序代理用户身份对目标程序进行访问的凭证；
其它说明如下：
Ø Ticket Granting ticket(TGT) ：票据授权票据，由 KDC 的 AS 发放。即获取这样一张票据后，以后申请各种其他服务票据 (ST) 便不必再向 KDC 提交身份认证信息 (Credentials) ；
Ø Authentication service(AS) --------- 认证用服务，索取 Credentials ，发放 TGT ；
Ø Ticket-granting service (TGS) --------- 票据授权服务，索取 TGT ，发放 ST ；
Ø KDC( Key Distribution Center ) ---------- 密钥发放中心；
4 CAS 安全性
CAS 的安全性仅仅依赖于 SSL 。使用的是 secure cookie 。
41 TGC/PGT 安全性
对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问 所有 授权资源。 PGT 的角色跟 TGC 是一样的。
从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。
TGT 的存活周期默认为 120 分钟。
42 ST/PT 安全性
ST （ Service Ticket ）是通过 Http 传送的，因此网络中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通过以下几方面来使 ST 变得更加安全（事实上都是可以配置的）：
1、 ST 只能使用一次
CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该 Ticket ，从而可以确保一个 Service Ticket 不被使用两次。
2、 ST 在一段时间内失效
CAS 规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。默认有效时间为 5 分钟。
3、 ST 是基于随机数生成的
ST 必须足够随机，如果 ST 生成规则被猜出， Hacker 就等于绕过 CAS 认证，直接访问 对应的 服务。
5 参考资料
1、 https://wikijasigorg/display/CASUM/Introduction
2、 http://wwwjasigorg/cas/protocol/
3、 http://wwwibmcom/developerworks/cn/opensource/os-cn-cas/indexhtml
4、 http://wwwblogjavanet/security/archive/2006/10/02/sso_in_actionhtml
5、 http://baikebaiducom/view/190743htm
1：YUM安装软件
[root@node2 Packages]# rpm -qa | grep iscsi
iscsi-initiator-utils-620873-2el6x86_64
[root@node2 Packages]# rpm -qa | grep scsi
iscsi-initiator-utils-620873-2el6x86_64
scsi-target-utils-1024-2el6x86_64
[root@node2 Packages]# lsb_release -a 服务器版本
LSB
Version:
:base-40-amd64:base-40-noarch:core-40-amd64:core-40-noarch:graphics-40-amd64:graphics-40-noarch:printing-40-amd64:printing-40-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 64 (Santiago)
Release: 64
Codename: Santiago
因为这台服务器是当RAC 数据库服务器之一的，所以此服务器需要安装客户端工具和服务器端工具。
YUM软件安装可以参考我的经验：rhel64 yum本地yum源配置
http://jingyanbaiducom/article/59a015e340de67f7948865bchtml
2
2：启动并设置开机自启动
[root@node2 Packages]# service tgtd start
Starting SCSI target daemon: [ OK ]
[root@node2 Packages]# chkconfig tgtd on
[root@node2 Packages]# chconfig --list | grep tgtd
-bash: chconfig: command not found
[root@node2 Packages]# chkconfig --list | grep tgtd
tgtd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
3：确定共享磁盘
[root@node2 Packages]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 629G 113G 484G 19% /
tmpfs 39G 167M 37G 5% /dev/shm
/dev/sda1 194M 33M 152M 18% /boot
/dev/sda3 194M 59M 178M 4% /home
/dev/sda2 289G 191M 274G 1% /share
或者使用DD创建一个大文件
dd if=/dev/zero of=/target_scsi bs=2M count=500 //使用dd
共享出来的设备源可以是DD出来的一个文件，或者是/dev/sda2这样的分区。
如果使用/dev/sda2这个分区，那么/share目录将会变成只读模式
这里我采用DD出一个文件，因为VOTE表决磁盘200M左右大小。
4：编辑配置文件
[root@node2 ~]# cat /etc/tgt/targetsconf
default-driver iscsi
<target iqn2015-07wiscom:wiscom20>
<backing-store /targe_scsi>
scsi_id wiscom20
lun 1
</backing-store>
</target>
默认所有用户都可以访问
编写规范：
target iqn2015-07wiscom:wiscom20 iqn年-月公司名称:scsi_id号 为后期编写多路径规则方便
scsi_id wiscom20 自定义 （客户端挂载后wwid）经过试验，我的服务器必须更改scsi_id,否则多路径无法指定别名
lun 1 默认为1
注意：
如果配置完文件之后，没有重启服务器，只是重启了iscsi服务 service tgtd restart 。执行tgt-admin -s 命令查看的时候没有lun 1 设备。最终发现重启服务器才生效
5：重启服务器 --至关重要
如果是服务器中已经跑了RAC，需要将node2集群关闭再重启服务器。
在试验过程中，发现自定义scsi_id无法生效，不管怎么修改都不行。最终重启发现生效。
tgt-admin -s 或者tgtadm --lld iscsi --mode target --op show 都可以查看qin号、设备连接信息和scsi_id号
6：本机挂载--node2挂载
[root@node2 ~]# iscsiadm -m discovery -t sendtargets -p 1010107:3260
1010107:3260,1 iqn2015-07wiscom:wiscom20
[root@node2 ~]# iscsiadm -m discovery -t sendtargets -p 1010117:3260
1010117:3260,1 iqn2015-07wiscom:wiscom20
[root@node2 ~]# iscsiadm -m node -T iqn2015-07wiscom:wiscom20 -p 1010107:3260 -l
Logging in to [iface: default, target: iqn2015-07wiscom:wiscom20, portal: 1010107,3260] (multiple)
Login to [iface: default, target: iqn2015-07wiscom:wiscom20, portal: 1010107,3260] successful
[root@node2 ~]# iscsiadm -m node -T iqn2015-07wiscom:wiscom20 -p 1010117:3260 -l
Logging in to [iface: default, target: iqn2015-07wiscom:wiscom20, portal: 1010117,3260] (multiple)
Login to [iface: default, target: iqn2015-07wiscom:wiscom20, portal: 1010117,3260] successful
扫描并挂载存储
如何挂载iscsi存储参考我的经验：rhel 6挂载以及卸载iscsi存储
http://jingyanbaiducom/article/046a7b3edda53bf9c27fa9a2html
7：查看scsi_id
scsi_id是设备唯一标识符，类似wwid
[root@node2 ~]# scsi_id -g -u -d /dev/adap
[root@node2 ~]# scsi_id -g -u -d /dev/sdap
1wiscom20
[root@node2 ~]# scsi_id -g -u -d /dev/sdaq
1wiscom20
8：节点2添加磁盘多路径
[root@node2 mapper]# vi /etc/multipathconf
[root@node2 mapper]# service multipathd restart
ok
Stopping multipathd daemon: [ OK ]
Starting multipathd daemon: [ OK ]
/etc/multipathconf 添加如下：
multipath {
wwid "1wiscom20"
alias crsC01
path_grouping_policy multibus
uid 1300
gid 1301
mode 666
}
在配置之前，一旦挂载就会发现/dev/mapper下已经生成了多路径磁盘mpathm,但是需要在多路径配置文件中添加以上配置生成统一别名。
磁盘多路径配置可以参考我的经验：ASM磁盘多路径及udev配置
http://jingyanbaiducom/article/aa6a2c14f89b180d4c19c4d3html
9：节点2 udev修改/dev/mapper/crsC01设备读写权限
[root@node2 dev]# vi /etc/udev/rulesd/99-oracle-asmdevicesrules
添加以下内容：
KERNEL=="dm-20", OWNER="grid", GROUP="asmadmin", MODE="0666"
[root@node2 dev]# /sbin/udevadm control --reload-rules
[root@node2 dev]# /sbin/start_udev
Starting udev: [ OK ]
至此，节点2 添加磁盘成功。但是节点1还需要添加磁盘。
10：节点1挂载共享iscsi设备
节点1挂载：node1
[root@node1 nodes]# iscsiadm -m discovery -t sendtargets -p 1010107:3260
1010107:3260,1 iqn2015-07wiscom:wiscom20
[root@node1 nodes]# iscsiadm -m discovery -t sendtargets -p 1010117:3260
1010117:3260,1 iqn2015-07wiscom:wiscom20
[root@node1 nodes]# iscsiadm -m node -T iqn2015-07wiscom:wiscom20 -p 1010107:3260 -l
Logging in to [iface: default, target: iqn2015-07wiscom:wiscom20, portal: 1010107,3260] (multiple)
Login to [iface: default, target: iqn2015-07wiscom:wiscom20, portal: 1010107,3260] successful
[root@node1 nodes]# iscsiadm -m node -T iqn2015-07wiscom:wiscom20 -p 1010117:3260 -l
Logging in to [iface: default, target: iqn2015-07wiscom:wiscom20, portal: 1010117,3260] (multiple)
Login to [iface: default, target: iqn2015-07wiscom:wiscom20, portal: 1010117,3260] successful
10：节点1添加磁盘多路径和udev修改权限
步骤和添加内容和第8步骤、第9步骤一致。
11：查看ASM中是否识别到该设备
两个节点均需要查看
[oracle@node1 ~]$ export ORACLE_SID=+ASM1
[oracle@node1 ~]$ export ORACLE_HOME=/u01/app/11204/grid/
[oracle@node1 ~]$ export PATH=$PATH:$ORACLE_HOME/bin
[oracle@node1 ~]$ sqlplus sys as sysasm
SQLPlus: Release 112040 Production on Tue Jul 28 16:33:01 2015
Copyright (c) 1982, 2013, Oracle All rights reserved
Enter password:
Connected to:
Oracle Database 11g Enterprise Edition Release 112040 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options
SQL>
SQL>
SQL>
SQL> col name for a20
SQL> col name for a20
col path for a30
col mount_status for a10
set linesize 300SQL> SQL> SQL>
SQL>
SQL>
SQL>
SQL> select name,path,failgroup,mount_status from v$asm_disk order by name;
0条评论