随着信息技术和网络技术的发展，各种应用服务的不断普及，用户每天需要登录到许多不同的信息系统，如网络、邮件、数据库、各种应用服务器等。每个系统都要求用户遵循一定的安全策略，比如要求输入用户ID和口令。随着用户需要登录系统的增多，出错的可能性就会增加，受到非法截获和破坏的可能性也会增大，安全性就会相应降低。而如果用户忘记了口令，不能执行任务，就需要请求管理员的帮助，并只能在重新获得口令之前等待，造成了系统和安全管理资源的开销，降低了生产效率。为避免这种尴尬，牢记登录信息，用户一般会简化密码，或者在多个系统中使用相同的口令，或者创建一个口令"列表"--这些都是会危及公司信息保密性的几种习惯性做法。

当这些安全风险逐步反映出来，管理员增加一些新的安全措施的时候，这些措施却在减少系统的可用性，并且会增大系统管理的复杂度。

因此，在市场上提出了这样的需求：网络用户可以基于最初访问网络时的一次身份验证，对所有被授权的网络资源进行无缝的访问。从而提高网络用户的工作效率，降低网络操作的费用，并提高网络的安全性。

 

关于认证和密钥分配系统的一个经常遇到的问题是，由于它要求对应用系统本身做出改动，所以经常受到的冷遇。考虑到这一点, 对一个认证和密钥分配系统来说, 提供一个标准化的安全API就显得格外重要。能做到这一点, 开发人员就不必再为增加很少的安全功能而对整个应用程序动大手术了。因此, 认证系统设计领域内最主要的进展之一就是制定了标准化的安全API, 即通用安全服务API(GSS-API)。德州Austin大学的研究者们开发的安全网络编程(SNP), 对GSS-API接口进行了进一步的封装, 使同网络安全性有关的编程更加方便。

"Generic Security Service Application Program Interface"简写GSS-API，译为通用安全服务应用程序接口，一个典型的GSS-API调用者是通讯协议本身，调用GSS-API，用可信性、完整性和机密性的安全服务来保护他的通讯。例如Kerberos。这就是GSS-API可以在不同的安全服务和应用程序被使用的原因，包括SSO。GSS-API 的目的是提供隐蔽特定的内在安全机制的一个接口。这可以帮助不同应用程序之间有更好的互操作性。

GSS-API的设计假定和强调以下几个基本目标：

机制独立：GSS-API定义了一个接口来使用密码技术实现强壮的认证和其他安全服务--在独立于特定的底层机制的通用层上。例如，GSS-API提供的服务可以用密钥技术实现（例如，Kerberos）或者使用公钥技术实现（例如 X.509）。

协议环境独立：GSS-API独立于使用它的通讯协议组，允许在多种协议环境中使用。在进行调用的协议和GSS-API的应用中间，加入一个面向特定的通讯协议（如RPC）的中介，可以保持GSS-API功能的起用和协议通讯的起用之间的同步。

协议联合的独立：GSS-API安全上下文构造是独立于通讯协议相关的构造的。这个特点允许单独的GSS-API实现可以被多种协议模块使用，以利于调用这些模块的应用程序。同时GSS-API服务也可以被应用程序直接调用，完全独立于协议关联。

适应多种实现：GSS-API客户不是被限制存在于实现GSS-API的系统定义的TCB（Trusted Computing Base）范围内；安全服务被以一种既适应intra-TCB调用，又适用extra-TCB调用的方式说明。

 

开放软件基金会（OSF）的分布式计算环境。DCE是一个被广泛接受的解决方案，用于开发和部署安全的、企业级的分布式计算应用，提供网络安全、透明的服务分配和跨平台通信的能力，允许在一个异构的环境中快速设计基于"主/从"或"对等"结构的应用。它能方便地对网络提供最佳的性能和可靠的保护。因为DCE是由主流操作系统厂商的行业协会所支持的，所以这个标准在很多计算平台上都得到了广泛的支持。DCE核心功能现在已经被几乎所有的UNIX系统及其变种所支持，并且，在PC操作系统日益普及的今天，DCE核心服务也在PC机上变得越来越普遍。

DCE的认证管理服务是集成了基于DES私人密钥加密技术和MIT开发的Kerberos技术的身份验证。这是一种企业级的安全解决方案，它使企业能为网络资源的使用提供安全。保管理护和通过企业Intranet的用户和通过Internet的远程用户都可以有控制地访问这些资源。

DCE对于安全涉及到4个方面：

认证（authentication），

安全通讯（secure communications），

授权（authorization），

和审计（auditing）。

 

PAM（Pluggable Authentication Modules ）是由Sun提出的一种用于实现应用程序的认证机制。其核心是一套共享库，目的是提供一个框架和一套编程接口，将认证工作由程序员交给管理员，PAM允许管理员在多种认证方法之间作出选择，它能够改变本地认证方法而不需要重新编译与认证相关的应用程序，同时也便于向系统中添加新的认证手段。

PAM最初是集成在Solaris中，目前已移植到其它系统中，如Linux、SunOS、HP-UX 9.0等，并在Linux中得到广泛的应用。

 

一、PAM的结构

 

PAM的整个框架结构如下图所示：

PAM的设计目标是：

 

管理员可以选择认证方式，从简单的密码到智能卡系统。

可以为不同的程序配置不同的认证机制。如 使telnet使用 S/Key认证。而本机的 login 缺省使用一般的 UNIX password。

支持程序的显示方式的需求。如login 需要基于终端的显示，而dtlogin需要X显示， 而`ftp' 和 `telnet'需要透过网络来认证。

支持为一个程序配置同时使用多种认证机制。

可是用户在使用多种认证机制时,不必为同一个密码敲入多次。

可是用户在认真时需要输入多个密码。

当底层的认证机制改变时上层软件不需要修改。

结构为system authentication提供一个pluggable_ model。

必须能满足现有的服务需要。

 

PAM的功能包括：

 

● 加密口令（包括DES以外的算法）；

● 对用户进行资源限制，防止DoS攻击；

● 允许随意Shadow口令；

● 限制特定用户在指定时间从指定地点登录；

● 引入概念"client plug-in agents"，使PAM支持C/S应用中的机器--机器认证成为可能。

 

PAM为更有效的认证方法的开发提供了便利，在此基础上可以很容易地开发出替代常规的用户名加口令的认证方法，如智能卡、指纹识别等认证方法。

 

 

在一个基于经纪人的SSO解决方案中，有一个集中的认证和用户帐号管理的服务器。经纪人给能被用于进一步请求的电子的身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的"第三方"。

 

Kerberos v5 是业界的标准网络身份验证协议，该协议是在麻省理工学院起草的，旨在给计算机网络提供"身份验证"。Kerberos协议的基础是基于信任第三方，如同一个经济人（broker）集中的进行用户认证和发放电子身份凭证，它提供了在开放型网络中进行身份认证的方法，认证实体可以是用户或用户服务。这种认证不依赖宿主机的操作系统或主机的IP地址，不需要保证网络上所有主机的物理安全性，并且假定数据包在传输中可被随机窃取篡改。

Kerberos协议具有以下的一些优势：

与授权机制相结合；

实现了一次性签放的机制，并且签放的票据都有一个有效期；

支持双向的身份认证，既服务器可以通过身份认证确认客户方的身份，而客户如果需要也可以反向认证服务方的身份；

支持分布式网络环境下的认证机制，通过交换"跨域密钥"来实现。

Sesame, 代表欧洲安全多环境应用系统（Secure European System for Application in Multivendor Environment）。是一个欧洲团体安全项目，被认为是一种欧洲版本的Kerberos。Sesame是建造在GSS-API上，提供单点登录服务和的在分布式环境中的数据安全性。尽管Sesame与Kerberos基于同样范例，但它们不是一对一的复制，而是在原有的设计中增加了一些新的特性。这些包括

异种环境，

访问控制，

可扩展的公钥系统，

更好的可管理性，

审计，

委托授权。

在Kerberos中，用户首先到一个认证服务器认证自己。从认证服务器获得标识在呈现给其他服务器以获得访问最终应用系统的授权。而在Sesame中，这些服务器被统称为特权属性服务器。从一个特权属性服务器，用户获得特权属性证书，最后把访问权利给需要的服务。

 

KryptoKnight是IBM公司的一种类似于Kerberos的鉴别和密钥分配系统。它是一种秘密密钥协议并使用DES-CBC模式或MD5增加版。支持四项保密功能：

用户鉴别

双方鉴别

密钥分配

数据源和数据内容的鉴别。

它和Kerberos的区别在于

采用单向散列函数鉴别和加密票据

不依靠同步时钟，而使用当前时间

如果甲试图和乙通信，可以允许甲发一条消息给乙，然后乙初始化密钥交换协议。

KryptoKnight极大的优化了消息数量，长度和加密的数量，而且不仅支持IP协议也支持其他通信协议如NetBIOS协议。

Broker-based解决方案的主要的问题，例如Kerberos，是确定现有哪些应用程序需要被修改的，或"kerberized"以接受票据，而对于旧系统的改造，是项艰巨的工作。

集中式的管理是在Broker-based解决方案的主要好处，一个中央数据库易于进行管理。

一个Broker-base的解决方案的设计实现安全的实际水平，取决于实施。Kerberos存在有若干安全上的争论。

旧的鉴别码有可能被存储和重用。尽管时间标记可用于防止这种攻击，但在票据有效时间内仍有风险。典型的票据有效时间是八小时。

鉴别码还基于一个假设，即网络中的所有时钟基本是同步。如果能够欺骗主机，使它的正确时间发生错误，就的鉴别码则能够被重放。大多数网络时间协议是不安全的，因此将可能导致严重问题。

在Kerberos中的认证仅仅基于口令, 这样使系统在口令猜测面前显得很脆弱。攻击者收集到大量的票据，则会有很大的可能性找到口令。

最严重的是，Kerberos假设Client已被信任，而恶意的Kerberos软件可以完成Kerberos协议并记录口令来替代所有客户的Kerberos应用。任何一种安装在不安全的计算机环境中的密码软件都会面临这样的问题。

和Kerberos一样，Sesame有一样的脆弱, 也就是口令猜测攻击的危险。

KryptoKnight在密码技术上的改进应该使了它比 Kerberos 更安全。

加强Kerberos的工作包括使用PKI技术和密钥管理中心的智能卡接口。

在集中式的模型管理中，容易受到批评的是如果认证服务器宕掉，则所有的应用，所有的用户都会受到影响。

 

在一个基于代理人的解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如, 它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人能也被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个"翻译"。 一个基于代理人的解决方案的一个例子是SSH。

SSH的英文全称是Secure Shell。通过使用SSH，你可以把所有传输的数据进行加密，这样就能够防止DNS和IP欺骗。这是一个为在网上进行安全连接的客户/服务器类型加密软件，实现了一个密钥交换协议，以及主机及客户端认证协议。SSH的用户可以使用包括RSA算法的不同认证方法。当使用RSA认证时，代理程序可以被用于单点登录。代理程序可以在PC，便携机，或终端上运行，当被认证身份加入到代理程序中，如果该代理程序有新的子连结产生，则继承原有连结的认证。远程系统往往需要一个SSH服务器，用以与代理程序通信。

 

 

基于代理人的方式能够使移植变得容易，但代理程序的软件供应商需要设计和实现与原有应用程序协议的交互。

单纯的代理方式不能够帮助管理，甚至使管理更难控制和分配代理软件的权利。

有强密码技术的保证，代理程序的通信应该是安全的，但问题可能出在恶意软件方面

也许象SSH一样的代理软件学习身份加载是的一个困难的概念。也可能是公钥密码学的概念本身就难以掌握，而用户往往并不具备这方面的知识更没有耐心。

 

现在被广泛使用的口令认证，比如FTP，邮件服务器的登陆认证，都可被称为"single-factor "口令的认证。这是一种简单易用的方式，同时也是一种会带来很多安全隐患的方式。比如：易于猜测，很少进行更换，一个口令在多种应用当中使用等等一会危及安全的习惯。再如，在明文传输的网络环境里，经常使用并很少更换的口令，更易于被窃取和造成危害。

RSA公司提出的一种称为SecurID的解决方案。与"single-factor "不同是是它被称之为"two-factor"双因素的认证。构成认证的第一个因素是Personnel Identification Number (PIN)，即用户身份识别码，这是一串保密的数字，可由系统管理员订制。第二个要素是SecurID token，一个小型的数字发生器，这个发生器的时钟将与网络环境中提供身份鉴别的服务器（ACE）保持同步，并且与ACE上的用户数据库保持映射。数字发生器每隔一段时间（比如一分钟）产生新的数字，PIN + 同步时钟数字就是用户的登录代码。

解决方案中也有种被称为WebID的模块。在Web服务器上安装一个ACE服务器的代理程序，用来接受SecurID。当访问第一个需要认证的URL时，WebID会软件产生并加密一个标识，这个标识将在访问其他资源的时候被用到。

 

这种方案比如WebID，因为需要在系统上增加一些新的组件，增加了管理员管理的负担。

增强了系统的安全性。

 

 

当Agent-Base的解决方案和Broker-Base的解决方案被相结合时，就结合前者的灵活性和后者的中央式管理两方面的优势。Agent-Base的好处还在于是减少了改变网络应用程序的的代价。这样，与Kerberos相比，就不需要"kerberize"化的应用程序。

这里演示一个图例：

使用基于代理方式，将可以简化一些在纯粹的broker-based方案中的修改。

应比单纯的broker-based方案更易于管理。

代理软件需要增加安全和本地验证的功能。

方案中同样保留有中心组件。

在broker-based的方案中，会在网络中放置一个"看门狗"的模型。而Gateway-Based则是另一种单点登录的方法，具体的做法是提供类似象"门"一样的网关用以安全的接入到可信的网络服务。网关可以是防火墙, 或者是专门用于通讯加密的服务器。下图是解决方案的一个模型。

在确定的环境中，安装和设置一道网关是方便的。作为一个分开的部件，需要注意它的网络通信能力，而基本不会有太多的互操作性问题。唯一的问题可能是，应用程序和网关客户端软件和需要安放在网关同一侧的一台计算机上。

比较而言，网关的中央用户数据库比一个broker-based的解决方案更易于管理。带来的问题是，如果若干网关被使用，那么用户数据库不能自动地被同步。

一个通讯加密服务器应该是安全，但是也可能被攻击，可能的攻击点是其操作系统，而当网关放在防火墙上，则攻击防火墙，如SYN-flooding。推荐的方式是，用分开的防火墙保护网关。

网关作为一个中心组件，它的状态同样会受到影响到整个服务的运行。

 

 

 

 

 

Tivoli Access Manager 4.1 infrastructure, including:

Tivoli Access Manager WebSEAL

Tivoli Access Manager Policy Server

IBM Directory Server (IDS), or any other LDAP server supported by TAM 4.1 (functions as the user registry)

 

Many vendors offer products that act as access control enforcers for online sites, or security domains; a security domain is defined here as a collection of one or more online sites to which user access is protected by a single central authority. Many of these access control enforcers provide support for SSO between security domains protected by the same product. The problem with these proprietary solutions is that they do not work with other vendor's products.

To address these problems, vendors of these products need to implement open standards for performing SSO and, more generally, for exchanging user information. Such standards need to clearly define two things:

The format of the messages that will be exchanged between a source site and a destination site. The protocols that should be used to exchange these messages.

The SAML specification outlines an open message format and a number of open protocols that achieve our requirements. The solution discussed in this tutorial is an implementation of one of the SAML SSO protocols for TAM 4.1.

 

TAM WebSEAL is a reverse proxy that gives customers a single point of authentication and authorization for any number of protected Web servers. TAM WebSEAL is one of a number of policy enforcers available as part of the TAM product set. Each policy enforcer in a domain utilizes the same policy information for enforcing access control. TAM WebSEAL acts as a HTTP policy enforcer, ensuring that all HTTP traffic is protected in accordance with the configured access control policies for the TAM domain.

TAM WebSEAL introduces a concept called junctions, which are network connections from the WebSEAL server to the protected Web servers. Clients view protected Web server content in junction directories coming off the WebSEAL server root directory. Client requests to content under these directories are reissued by WebSEAL to the appropriate Web servers transparently. WebSEAL then forwards the responses back to the client, so the client thinks everything is coming from WebSEAL.

The following diagram shows a high-level overview of our implementation of the SAML Browser/Artifact. The SAML Toolkit for TAM 4.1 User Guide gives a much more in-depth description of the process flow, but for our purposes we will limit the detail to enough to deploy and test the solution in a basic environment.

There are a couple of basic things to note about this solution:

1. The trust between the two domains, domain A and domain B, is established by the token passed in the URL query string of the client request to domain B. WebSEAL leaves the responsibility of interpreting and validating the token to the plug-in CDSSO consume module. In our case, the type of token passed between the two domains is known as a SAML artifact.

The SAML artifact is a fixed-length token consisting of two main parts:

A unique 20-byte value, known as a SAML source ID. The SAML artifact's source ID identifies the source domain of the user holding the artifact.

A unique 20-byte value that acts as a lookup number for a single SAML assertion. The SAML assertion verifies the authenticity of the holder of the matching artifact. The assertion is generated by the source domain at the same time the artifact is generated. It must be retrieved securely from the source domain by the destination domain in the final phase of the SSO process.

2. Most of the SAML-related processing is forwarded to the SAML runtime servlets running on the WebSphere machines. At the source domain, the SAML runtime servlets are responsible for generating the SAML artifacts and their matching SAML assertions. At the destination domain, the runtime servlets are responsible for taking SAML artifacts passed by the WebSEAL SSO consume module, and retrieving and verifying each artifact's matching SAML assertion from the source domain.

1. 基于表单的认证

2. HTTP的标准认证

3. 数字证书的认证(X.509v3)

4. RSA SecurID Token的认证

5. 基于WAP的认证

6. 资源敏感的认证方式

7. 第三方的认证方式

 

1. 通过通过HTTP Header HTTP Header 来传递参数来传递参数iv iv--user user

2. 基于表单的基于表单的SSO SSO

3. Lightweight Third Lightweight Third--Party Authentication (LTPA) Party Authentication (LTPA)

a. WebSphere WebSphere和和Domino Domino特有的特有的SSO SSO方式方式

b. LTPA LTPA 服务器认证用户，并且利用服务器认证用户，并且利用session cookie session cookie来保持状态来保持状态

c. WebSEAL WebSEAL可以作为一个可以作为一个LTPA LTPA 服务器服务器

c1 WebSEAL WebSEAL 和和WebSphere WebSphere 需要共享一个用户注册库需要共享一个用户注册库

c2 LTPA cookie LTPA cookie 不会到达用户端不会到达用户端

4. Trust Association Interceptor Trust Association Interceptor

a.是运行在是运行在WebSphere WebSphere 上的一个代码程序上的一个代码程序

b.从从HTTP Header HTTP Header 中读取参数中读取参数iv iv--user user 并且把它转换成并且把它转换成WebSphere WebSphere Token Token

5. GSO Junction GSO Junction

 安全的用于存储用户密码的密码箱安全的用于存储用户密码的密码箱

 

应用服务器中的SSO并不是J2EE中的标准实现，而是各家中间件提供商在提供J2EE应用服务器集群时提供的一种认证信息共享的机制，所以各家厂商提供的实现方式不一样，IBM的WebSphere是通过cookies记录认证信息，BEA的WebLogic通过session共享技术实现认证信息的共享，国内深圳金蝶的apusic采用的和BEA的技术基本一致。

但是不管各家的实现技术怎么样，他们的理论基础都缘于J2EE中的安全技术：Java Authorization Contract for Containers (Java ACC)和JavaTM Authentication and Authorization Service（JAAS）。 Java Authorization Contract for Containers (Java ACC)和JavaTM Authentication and Authorization Service（JAAS）是j2ee技术中实现安全访问机制的规范和标准，其中Java ACC属于j2ee规范的一部分，而JAAS是Java ACC的实现部分。

 

Java ACC规范定义了授权策略模块和J2EE容器之间的实现规范，这样容器安全提供者就可以根据操作环境的要求提供J2EE容器的授权功能。

Java ACC规范分为三个部分，分别是：提供着配置规范，安全策略配置规范，策略判断和执行规范。这三个部分组合在一起共同描述了授权提供者的安装和配置，J2EE容器使用者可以根据这些规范来实现访问控制。

 

1. 安全提供者配置规范规定了对安全提供者和容器的要求，这些是安全策略提供者和容器之间整合的基础。

2. 安全策略配置规范定义了容器配置工具和安全提供者之间的交互规范，所谓的交互是指如何将声明的授权策略信息转化为J2SE策略提供者可以识别的指令的过程。

3. 策略判断和执行规范定义了容器策略执行点和安全提供者之间的交互，他实现了J2EE容器需要的安全策略判断。

 

JAAS全名是JAVA认证和授权服务，它是一组java包，为提供基于用户的认证和访问控制提供支持，它是标准可嵌入式认证模型（PAM）的java版本实现，支持基于用户的身份认证。

JAAS是J2SE1.3中的可选包，但是J2SE1.4中已经集成了JAAS.

 

 

SSO在IBM的产品中得到了完全的体现，包括在WebSphere集群中，在WebSphere和Domino的集成中，都可以实现。

SSO允许网络用户在访问多个WebSphere域的多个应用时只要向其中的某一个WebSphere应用服务器进行认证，就可以访问其他WebSphere域中的各种资源，包括HTML页面，JSP文件，Servlet和企业EJB,也可以访问其他Domino中的文档，而不需要登录多个WebSphere域。

WebSphere中默认不支持SSO，如果需要实现SSO,需要对每一台WebSphere服务器进行配置，如果需要实现WebSphere和Domino之间的SSO，则对WebSphere和 Domino 都要重新配置。

 

要实现WebSphere服务器之间的SSO，必须满足以下前提条件：

1. 所有的服务器必须配置成同一个DNS域的一部分。

比如： DNS域配置为mydomain.com,那么，SSO将在所有Domino和WebSphere服务器起作用，只要他在属于这个DNS域的某个主机上，比如说在a.mydomain.com和b.mydomain.com的主机上配置的两台webpshere服务器之间。

2. 所有服务器必须共享用户注册表，用户注册表可以是LDAP数据库，在WebSphere服务器之间实现SSO还可以采用用户自己实现的用户注册表，但是Domino不支持用户自己实现的用户注册表，所以WebSphere和Domino之间实现SSO时只能采用LDAP数据库作为公有的用户注册表。

3. 所有的用户定义在一个单一的LDAP目录中。

4. 用户的浏览器必须支持Cookies,因为服务器生成的信息将通过Cookies传递到客户端，然后会提交给用户访问的其他服务器进行认证。

5. WebSphere应该是3.5版本或者以上版本。

WebSphere中的SSO授权机制比较简单，采用了类似于windows文件的权限管理的机制，就是先定义一些角色，然后给这些角色授予访问某些服务器资源的权限，然后再将这些角色映射到具体的用户或者用户组。

比如：我们开发了一个WebSphere服务器上的web应用，这个应用的管理员可以使用这个web应用的管理权限，和管理权限相关的文件都放在这个应用的/admin目录下，那么我们就可以给这个应用增加一个admin的角色，它可以访问/admin目录下的所有文件，然后把这个admin角色映射到所有管理员角色所在的LDAP数据库中的某个组，如图所示：

 

 

 

Sun Java System Access Manager 原名 Sun Java System Identity Server，简称为 Access Manager。Sun Java System Directory Server Enterprise Edition 原名 Sun Java System Directory Server，简称为 Directory Server。

 

单一登录 (SSO) 是在应用程序之间传送用户的身份证明的方法，以便使用户每次访问其他应用程序时无需验证身份；它实际是一种在不同身份域之间无缝识别用户的一种机制。本节描述了在利用 Access Manager 来实现 SSO 时必须考虑的各个方面，并讨论了一些最佳实践。

 

完善的应用程序通常都提供有用于与外部身份验证和授权源进行集成的机制。使用 Access Manager，可以用多种方法实现 SSO；决定选择哪一种方法取决于如何可以最佳地集成您的应用程序。

 

您可以使用或不用政策代理来获得用户身份证明，如下所述：

 

安装一个政策代理来保护应用程序，然后将 HTTP_HEADER 和 REMOTE_USER 传递给应用程序以便捕获用户身份证明。您可能需要也可能不需要自定义身份验证模块。

自定义应用程序的身份验证模块，从请求对象或从 SSO cookie 来创建 SSO 令牌 (SSOToken)。然后，通过 SSO API 检索出用户身份证明，然后使用应用程序的 API 来创建会话。

 

身份验证是确认用户身份的过程，通常时要验证用户 ID 及其密码。遵照下面的实践：

 

使用 Access Manager 政策代理保护应用程序 URL。这些代理支持当今市场许多的多种 Web 服务器和应用程序服务器。

 

让 Access Manager（和 Directory Server 一起）成为身份验证的授权源，并采用来自 Sun Java System Identity Manager 提供的解决方案。被保护的应用程序会将用户的身份验证请求重定向到 Access Manager 以进行身份验证。

 

使用 Access Manager 可通过以下两种方法之一来验证用户身份：

使用政策代理将 HTTP 头变量插入请求对象，这是一种仅适用于 Web 应用程序的方法。好处：应用程序可以通过 Access Manager 进行身份验证，同时最大限度减小对代码的更改（如果有）。

使用身份验证 API （作为 Software Development Kit (SDK) 的一部分而被捆绑）来验证和检索用户身份，这是一种 Web 和非 Web 应用程序均可使用的方法。好处：确保安全。

 

授权是决定允许或拒绝某项操作（如用户请求或服务请求）的过程。

实现共享或国际化的授权模型。最佳实践是将授权集中在 Access Manager 中。如果无法实现，则采用共享模式，通过这种模式可以向应用程序传递规则以检索政策并执行其他相关任务。

可以借助于政策代理或 API 实现授权，如下所述：

使用政策代理保护应用 URL (声明性或配置安全)；应用程序假定另外一个实体正控制该访问。这种机制最适用于基于 URL 的资源或简单的应用程序。

在应用程序中内嵌 Access Manager API (程序性安全) 来评估和决定访问政策。这种机制可实现对应用程序的更精确细的控制。

 

遵循下列建议管理用户数据库:

通过使 Access Manager 成为用户数据库的中心库来外化用户管理进程：也就是，使所有的应用程序要么使用 Access Manager 库，要么同步数据仓库。

扩展 schema，向用户数据中增加特定于应用程序的属性。

 

通过 Access Manager API 访问 Directory Server 中的身份对象。不要使用 Lightweight Directory Access Protocol (LDAP)、Java Developer's Kit (JDK)、LDAP Software Development Kit (SDK) 或 Java Naming and Directory Interface (JNDI) API。Access Manager 提供对那些底层 API 的 wrapper，从而使得应用程序的使用与厂商无关并降低复杂度。

 

熟悉 SSO API 和用于创建 SSO 令牌的许多可选方法。

注意：只能使用针对命令行应用程序的 com.iplanet.sso 软件包中的 SSOTokenManager 类的 createSSOToken(user, password) 方法。用这种方法创建的令牌仅在调用应用程序的上下文中有效。一旦退出进程，令牌就被销毁。

当在 Access Manager 中管理会话时应牢记以下提示：

确保当用户从应用程序注销时，相关的 Access Manager createSSOToken(user, password) 会话也同时结束。对用户透明情况下，可以将会话重定向到一个再次确认注销的页面。另一种可选的做法是，可以使用 SSO API 销毁令牌并在应用程序的注销方法中调用它们。

 

确保解决方案也能处理 Access Manager 会话可能会因其他原因而中断的情况。对于那些另外的情况，应中断应用程序会话并将用户重新定向到 Access Manager 以进行再次登录。

 

为了终止应用程序会话，执行下列操作之一：

为 SSOTokenListener 接口注册应用程序，以使应用程序可接收终止会话的通知并在必要时清除。

 

 

应用 Appendix A, "AMAgent Properties" in the Web Policy Agents Guide 中所描述的注销功能来终止 Access Manager 上的会话。

 

为执行该功能，在安装 Access Manager 后人工编辑手工编辑 AMAgent.properties 文件并设置用于注销 URL 特性的下列属性（除应用程序的其他特性外）之后:

 

com.sun.am.policy.agents.logout.url = list of logout URLs, separated by spaces

com.sun.am.policy.agents.logout.cookie_reset_list = list of cookies to be reset upon logout, separated by spaces

 

例如，下面的行在默认域（第一个）、主机（第二个）和 red.iplanet.com 域（最后一个）中重新设置 iPlanetDirectoryPro cookie：

 

iPlanetDirectoryPro, iPlanetDirectoryPro;

Domain=, iPlanetDirectoryPro;red.iplanet.com

 

下面提供更多的关于如何配置 URL 政策代理的提示：

首先将代理配置为 SSO_ONLY，以确保用户在获准访问受保护应用程序之前，按照 Access Manager 的身份验证服务进行身份验证。然后按照访问控制需求重新配置代理。

 

当在 Sun Java System Application Server （简称为 Application Server）中安装策代理以保护捆绑了 XML 分析器的应用程序时，只要重新部署该应用程序，代理设置就会消失。为恢复这些设置，必须重新启动 Application Server.

为避免重新启动，应确保应用程序所使用的分析器与代理所所加载的相同，分离应用程序并删除分析器库，然后重新部署应用程序。

 

在 Access Manager 中可以用下列三种方法之一来实现跨域 SSO：

建立政策代理。利用政策代理实现 SSO 的另外一个好处是：以后如果需要可以跨域来扩展实现。

应用 Security Assertions Markup Language (SAML) SSO 配置文件。

最佳实践是采用 Liberty Alliance 提供的联合和到 SAML 的 SSO 扩展。

Liberty Alliance 是由许多行业领先者参与的以制定联合和管理身份身份的标准为目的的标准组织。遵守标准使程序更具互操作性。

 

身份与两种类型的实体相交互：

在线开展业务并交付信息的服务提供者应用程序

维护和管理身份数据的身份提供者

身份联合是一种跨多个服务提供者和身份提供者来捆绑或关联身份的方法。

 

为建立联合 SSO，必须首先建立以上各节所述的 SSO 集成。然后，配置 SSO 集成并使应用程序以服务提供者的角色参与与 Access Manager 的联合，这构成了 Liberty 协议的基础设施。

 

在建立联合的过程中，所有的服务提供者和身份提供者都必须共享同步时钟。要实现同步，可以指向一个外部时钟源，或在接收响应时发生延迟的情况下，确保通过调整超时来成功地捕捉响应。

 

考虑这种情况：在联合建立过程中，Access Manager 担当服务提供者，并管理在 Sun Java System Web Server 上的一个不同实例上运行的应用程序。必须如下配置用于保护该应用程序的代理：

将 AMAgent.properties 文件中的 com.sun.am.policy.loginURL 条目指向以 Access Manager 运行的预登录服务 URL。

例如:

com.sun.am.policy.loginURL = http://www.sp1.com:58080/amserver/preLogin?metaAlias=www.sp1.com

将 AMAgent.properties 文件中的 com.sun.am.policy.am.library.loginURL 指向服务提供者角色的 Access Manager 的登录 URL。

例如:

com.sun.am.policy.am.library.loginURL = http://www.sp1.com:58080/amserver/UI/Login

 

服务提供者应用程序上的全局注销

对所有的服务提供者应用程序而言，用 Liberty Logout 方法实现注销进程过程。进行如下操作：

复制 AMClient.properties 文件到服务提供者的应用程序容器。

修订 Logout 方法, 如下所述：

ResourceBundle rsbu =ResourceBundle.getBundle("AMClient");

String logouturl = rsbu.getString

("com.sun.identity.federation.client.samples.logoutURL");

response.sendRedirect(logouturl);