|Deployment||Token API||Active naming||Trusted|
Trusted Web site support|
Before describing the trusted Web site support we must explain why we need it and why it is useful.
Users need single sign-on.
To support single sign-on in a "classical" architecture where each application has it own realm and authentication, designers must put gateways in place with a mapping mechanism.
This design has the following drawbacks:
Despite its drawbacks this design can be the only solution when you must integrate existing applications with their own authentication mechanism and thin-grained authorizations. For instance on the diagram above Application 1 and Application 2 protect their resources with Access Control Lists (ACLs). Application administrators can move users from one group to another and grant permissions to groups and users.
Most of the time at least for new application sets such complicated solutions are not needed. Let’s take the example of the Pandora architecture:
The authentication application collects information allowing charging and delivering the good.
Pandora forwards this information but doesn’t use it. Payment and delivery data are what we call MacGuffin data. MacGuffin is a major contribution of Alfred Hitchcock to science. In a film a MacGuffin is something that the characters worry about but the audience (and the scenarist and director) does not. In an application a MacGuffin data is something that maybe matters for the actor and for the partnering applications but not for the application itself.
Pandora needs two things:
Maybe Application 2 has a more demanding security. Application 2 can implement ACLs and define three or four groups of users but once again Application 2 doesn’t need to know the customer identity. Application 2 only needs to know which group the customer belongs to.
We believe that it is a general rule:
Another strong point of this design is the support of many authentication servers.
Let’s consider the case of an organization that has for historical and management reasons an authentication server for its internal users, another authentication server for its partners and a third one for its customers. All authentication servers can link to some applications with different profiles. The internal users’ and the partners’ authentication servers can link to some other applications and only the internal users’ authentication server can link to the remaining applications.
Trusted site support
When a user authenticates on an Application server the Application server records the user context in memory and writes a context identifier in a cookie sent to the browser with the HTTP response. When the user makes another request on the same Application server the Application server receives the cookie with the HTTP request and can retrieve the user context. It is important to note that:
A trusted site support requires:
Multi site support
To address the first requirement we simply need to code a dynamic link on a JSP page of site A that carries user information from site A to site B:
The code contains three sections:
The code calls a link bean (lb) JavaBean:
Site B implements an entry page for each user group. The link bean analyzes the user credentials in the context of site A to determine in which group the user should be defined on site B and eventually find out to which page the user should link. Its getLinkPage method returns that link.
In the getUserInfo method the link bean extracts the MacGuffin data from site A.
The site B entry pages:
Site B must check that the request is coming from a valid referrer site.
The most reliable solution consists in using a certificate.
Assuming that the link bean implements signature details the link page has only minor changes:
The link bean implements two new methods:
The site B entry pages get the certificate and signature along with the user data from the request. Entry pages check:
For the implementation details look at the Pandora implementation document and sources. For background information about security programming in Java you can also look at our article in the May 2001 issue of Java Developer Journal.