http://sentom.net/list.asp?id=13
创刊号-Liberty
作者:jini 来源:java 公开原始码报
申明：未经作者同意，谢绝转载
网络越来越发达，相对的，网站也越来越多，提供个性化的服务也同步地增多。那么，要如何整合各个系统之间的认证，让系统可以达到单一登陆就可以尝试进入其他属于相同认证地系统呢，这问题因为没有标准之前，都让许多系统没有办法整合认证措施，所以 liberty 专案就是来解决这个问题的。
一、Liberty 联盟主要的目标为
Enable consumers to protect the privacy and security of their network identity information
Enable businesses to maintain and manage their customer relationships without third-party
Provide an open single sign-on standard that includes decentralized authentication and authorization from multiple providers
Create a network identity infrastructure that supports all current and emerging network access devices
二、liberty 建置后的例子
先假设TestA 属于 Indentity Provider 而 TestB 属于 Service Provider 。
当你达到一个 TestA 网站，她要求你登陆，如果你登陆成功，那就代表 testA 验证你的资料成功了，我们称之 <i><b>authenticated</b></i>。
接着 testA Identity Server 会询问你要不要使用 SSO ，属于同一个 Identity Federation 相关系统就可以自动登陆了，选择同意自动登陆。
当你去另外一个 TestB 网站，如果她属于同一个 Identity Federation ，她就会询问你是否使用在 testA 已经验证过的身份直接登陆（也可以设定不询问就直接登陆了）。
此时他会让你等待一下，因为 testB 正在和 testA 做验证资料交换，如果你在 testA 的验证记录还是 authenticated 那么 testB 系统将会让你进入。
如此一來使用者的感觉就像单一登陆（SSO）。
三、liberty 是由三个组件组合而成的
(1) Web redirection
Action that enables Liberty-enabled entities to provide
services via today's user-agent-installed base.
(2) Web services
Prototcol profiles that enable Liberty-enabled entities to
directly communicate.
(3) Metadata and schemas
A common set of metadata and formats used by Liberty-enabled
sites to communicte various provider-specific and other
information.
首先来谈 Web redirection
基本上有几个方法可以做到 redirection
1.使用 HTTP-Redirect-Based Redirection(use status 302 and GET to identity server)
2.使用 Form-POST-Based Redirecton (use POST and javascript)
3.使用 Cookie( 但是 cookie 因为 domain 的限制所以不建议使用，不过如果是同一 domain 则可以使用 )
其次谈到 Web services
遵循的是 SOAP (now 1.1, 相关的 soap 请参阅 xml.apache.org base xml and http)
顺便回复 gary , 这有没有长度限制 我也不太清楚
因为我印象中没有这个条件规定 ( sorry )
最后 metadata and schemas
包含的就是 service provider and identity provider 之间传输的资料格式了
最基本具有 Account/Identity, Authentication Context,Provider Metadata,
sso 的原理就是
1. 当你到达一个 service provider 她会检查你是否已经 authenticated
2. 如果没有， service provider 将使用 http-redirect 或 form post 将网页导到 identity provider
3. 当你到达 indentity server 就会有登陆的地方
4. 执行登陆
5. identity server 将会把你导回你之前的 service provider 并且加上凭证
6. service provider 将会接受导来自identity server 的 redirect 并且 parse 凭证
7. service provider 将使用改凭证会回到 identity server 得到使用者资料
如果使用 cookie 在同一个 domain 就更简单了
1. 使用者直接到 identity server 取得认证 她将会将你导到 common domain
2. Common domain Service 将写 cookie 到你的电脑
3. 当你使用另外的 service provider site
4. service provider 将你导到 common domain
5. common domain service 将从 cookie 中取得 IDP list 并却加上 url 导回 service provider
6. 如果你还没有 login 则会要求你登陆
至于凭证资料的格式是什么样子呢 authentication context
我们将称之为 SAML
我列出范例 有兴趣的可以参阅 spec ( http://www.projectliberty.org/specs/liberty-architecture-authentication-context-v1.1.pdf )
<?xml version="1.0"?>
<saml:Assertion>
<saml:AuthenticationStatement AuthenticationMethod=" urn:ietf:rfc:2246">
<saml:Subject>
<saml:NameIdentifierFormat="http://www.oasis-open.org/committees/security/docs/cs-sstc-core-28#X509SubjectName">
cn=Joe User,dc=projectliberty,dc=org
</saml:NameIdentifier>
</saml:Subject>
</saml:AuthenticationStatement>
<saml:Advice>
<!--additional elements in separate namespace -->
</saml:Advice>
</saml:Assertion>
相关的 protocols 请参阅 protocols-schema ( 我也是从这里剪贴出来的 )
http://www.projectliberty.org/specs/liberty-architecture-protocols-schema-v1.1.pdf
至于 profile 应该如何去传递
请参阅 http://www.projectliberty.org/specs/liberty-architecture-bindings-profiles-v1.1.pdf
最后针对牛人们在讨论的 LDAP 存储资料问题
基本上 LDAP 不适合存放大量资料
在 clayton donley (manning)的书中第一章 (1.2)
就开宗名义的说
ldap is not a relational database,
is not a file system for very large objects,
is not optimal for very dynamic objects,
is not useful without applications
所以我的建议是
如果你要放置一些资料
就摆一些可能写在 session 中的小资料
至于 directory server authentication
Password 是否可以比较 use compare()
因为 directoy server 上面存储 user password 为纯粹的 text file
机会非常的少
所以呢不会使用取得 password property 再去比较
而是
先根据 username 取得 DN
尝试使用 DN and password 去 Open connection
回传 true / false;
不需要考虑她的编码方式
最后 LDAP 的工作则是 authorization
去检查是否具有使用的权限
http://www.javaworld.com/javaworld/jw-05-2002/jw-0524-signon.html
Participant interaction
Here is a brief description of how the pattern elements work:
When a gatekeeper intercepts a request to access a protected resource, it first checks to see if a login session for the user in that Web application is established. If not, the gatekeeper checks to see if a global SSO session is established with the authenticator.
If no global SSO session has been established, the user is redirected to the authenticator sign-on page and asked to provide a username and the appropriate credentials for that user (for example, password or certificate).
The authenticator receives the username and credentials and verifies them against the user credential store.
If verification succeeds, the authenticator establishes a global login session and directs the gatekeeper to establish a login session for the user in that Web application.
The authenticator communicates with the gatekeepers by sharing cookies or by redirecting the client browser with tokens in the query string or some other method.
Implementation strategy
Of course, the gatekeeper implementation must be consistent with the container version in which it runs. Because the filter is only supported in Servlet 2.3, earlier versions must use the Java Pet Store 1.1.2's servlet-based architecture. To support these applications, we will write a gatekeeper based on javax.servlet.http.HttpServlet. This servlet is deployed as the gatekeeper for each legacy Java application that wishes to participate in SSO. As described in Java Pet Store 1.3, we will write a gatekeeper based on javax.servlet.Filter to support newer containers that comply with the Servlet 2.3 specification.
We must remove pre-existing calls to application-specific sign-on code. We don't need to recode applications that use the standard interface (e.g., getUserPrincipal()) in containers that support filtering. However, we do need to recode applications that do not use the standard interface.
You can implement the authenticator in various ways. We will implement it as a Java Web application. For organizations with only Java Web applications, this approach will suffice.
However, you could extend this approach—by adding Web services to the authenticator, for example. This extension would allow non-Java applications to access the authenticator. It would also allow the authenticator to serve as a proxy for other authenticators using Security Assertion Markup Language (SAML) running under the Simple Object Access Protocol (SOAP). In this way, we could achieve the federation of user identities. (We could also support communication with both Microsoft's .Net and Sun Microsystems' Liberty Alliance servers outside the enterprise.)
To implement the credential store, we have several options. We can use an LDAP server if available, in which case the authenticator queries the LDAP server and the LDAP server queries the credential store. If an LDAP server is not available, the authenticator can query a relational database directly.
http://www.opengroup.org/security/sso/sso_intro.htm
Introduction to Single Sign-On As IT systems proliferate to support business processes, users and system administrators are faced with an increasingly complicated interface to accomplish their job functions. Users typically have to sign-on to multiple systems, necessitating an equivalent number of sign-on dialogues, each of which may involve different usernames and authentication information. System administrators are faced with managing user accounts within each of the multiple systems to be accessed in a co-ordinated manner in order to maintain the integrity of security policy enforcement. This legacy approach to user sign-on to multiple systems is illustrated below:
Legacy Approach to User Sign-on to Multiple SystemsHistorically a distributed system has been assembled from components that act as independent security domains. These components comprise individual platforms with associated operating system and applications.
These components act as independent domains in the sense that an end-user has to identify and authenticate himself independently to each of the domains with which he wishes to interact. This scenario is illustrated above. The end user interacts initially with a Primary Domain to establish a session with that primary domain. This is termed the Primary Domain Sign-On in the above diagram and requires the end user to supply a set of user credentials applicable to the primary domain, for example a username and password. The primary domain session is typically represented by an operating system session shell executed on the end user’s workstation within an environment representative of the end user (e.g., process atrributes, environment variables and home directory). From this primary domain session shell the user is able to invoke the services of the other domains, such as platforms or applications.
To invoke the services of a secondary domain an end user is required to perform a Secondary Domain Sign-on. This requires the end user to supply a further set of user credentials applicable to that secondary domain. An end user has to conduct a separate sign-on dialogue with each secondary domain that the end user requires to use. The secondary domain session is typically represented by an operating system shell or an application shell, again within an environment representative of the end user. From the management perspective the legacy approach requires independent management of each domain and the use of multiple user account management interfaces. Considerations of both usability and security give rise to a need to co-ordinate and where possible integrate user sign-on functions and user account management functions for the multitude of different domains now found within an enterprise. A service that provides such co-ordination and integration can provide real cost benefits to an enterprise through:
- reduction in the time taken by users in sign-on operations to individual domains, including reducing the possibility of such sign-on operations failing
- improved security through the reduced need for a user to handle and remember multiple sets of authentication information.
- reduction in the time taken, and improved response, by system administrators in adding and removing users to the system or modifying their access rights.
- improved security through the enhanced ability of system administrators to maintain the integrity of user account configuration including the ability to inhibit or remove an individual user’s access to all system resources in a co-ordinated and consistent manner.
Single User Sign-On To Multiple ServicesSuch a service has been termed Single Sign-On after the end-user perception of the impact of this service. However, both the end-user and management aspects of the service are equally important. This approach is illustrated in the diagram above. In the single sign-on approach the system is required to collect from the user as, part of the primary sign-on, all the identification and user credential information necessary to support the authentication of the user to each of the secondary domains that the user may potentially require to interact with. The information supplied by the user is then used by Single Sign-On Services within the primary domain to support the authentication of the end user to each of the secondary domains with which the user actually requests to interact.
The information supplied by the end-user as part of the Primary Domain Sign-On procedure may be used in support of secondary domain sign-on in several ways:
- Directly, the information supplied by the user is passed to a secondary domain as part of a secondary sign-on.
- Indirectly, the information supplied by the user is used to retrieve other user identification and user credential information stored within the a single sign-on management information base. The retrieved information is then used as the basis for a secondary domain sign-on operation.
- Immediately, to establish a session with a secondary domain as part of the initial session establishment. This implies that application clients are automatically invoked and communications established at the time of the primary sign-on operation.
- Temorarily stored or cached and used at the time a request for the secondary domain services is made by the end-user.
From a management perspective the single sign-on model provides a single user account management interface through which all the component domains may be managed in a coordinated and synchronised manner.
Significant security aspects of the Single Sign-On model are:
- the secondary domains have to trust the primary domain to:
- correctly assert the identity and authentication credentials of the end user,
- protect the authentication credentials used to verify the end user identity to the secondary domain from unauthorised use.
- The authentication credentials have to be protected when transfered between the primary and secondary domains against threats arising from interception or eavsdropping leading to possible masquerade attacks.
Trackback: http://tb.donews.net/TrackBack.aspx?PostId=565094