Patent Application
20080271121
1. Technical Field
The present invention relates generally to management of user sessions in a federated environment.
2. Background of the Related Art
Federated environments are well known in the art. U.S. Publication No. 2006/0021018, filed Jul. 21, 2004, is representative. A federation is a set of distinct entities, such as enterprises, organizations, institutions, or the like, that cooperate to provide a single-sign-on, ease-of-use experience to a user; a federated environment differs from a typical single-sign-on environment in that two enterprises need not have a direct, pre-established, relationship defining how and what information to transfer about a user. Within a federated environment, entities provide services that deal with authenticating users, accepting authentication assertions (e.g., authentication tokens) that are presented by other entities, and providing some form of translation of the identity of the vouched-for user into one that is understood within the local entity. Federation eases the administrative burden on service providers. A service provider can rely on its trust relationships with respect to the federation as a whole; the service provider does not need to manage authentication information, such as user password information, because it can rely on authentication that is accomplished by a user's authentication home domain or an identity provider.
A federated entity may act as a user's home domain, which provides identity information and attribute information about federated users. An entity within a federated computing environment that provides identity information, identity or authentication assertions, or identity services is termed an identity provider. Other entities or federation partners within the same federation may rely on an identity provider for primary management of a user's authentication credentials, e.g., accepting a single-sign-on token that is provided by the user's identity provider; a domain at which the user authenticates may be termed the user's (authentication) home domain. An identity provider is a specific type of service that provides identity information as a service to other entities within a federated computing environment. With respect to most federated transactions, an issuing party for an authentication assertion would usually be an identity provider; any other entity can be distinguished from the identity provider. Any other entity that provides a service within the federated computing environment can be categorized as a service provider. Once a user has authenticated to the identity provider, other entities or enterprises in the federation may be regarded as merely service providers for the duration of a given federated session or a given federated transaction.
With reference now to
In a federated space, the problem of managing a lifecycle of a user's session is complex. One solution to this problem is described in the above-identified patent application. In particular, and with reference now to
In the prior art, federated user lifecycle management application 208 comprises support for interfacing to, interacting with, or otherwise interoperating with, federated user lifecycle management plug-ins 214. The federated protocol runtime plug-ins provide the functionality for various types of independently published or developed federated user lifecycle management standards or profiles, such as: WS-Federation Passive Client; Liberty Alliance ID-FF Single Sign On (B/A, B/P and LECP); Register Name Identifier; Federation Termination Notification; and Single Logout (SLO). Different sets of federated protocols may be accessed at different Uniform Resource Identifiers. This approach allows the federated user lifecycle management application to concurrently support multiple standards or specifications of federated user lifecycle management, e.g., the WS-Federation web services specification versus the Liberty Alliance's specifications, within a single application, thereby minimizing the configuration impact on the overall environment for supporting different federation protocols.
The appropriate federated user lifecycle management functionality is invoked by the point-of-contact server by redirecting and/or forwarding user requests to the federated user lifecycle management application as appropriate. Referring again to
Thus, to facilitate session management, current solutions provide internal plug-ins that are specific for a given SSO protocol (SSOp) or a given point of contact (POC). The requirement for specialized plug-ins increases the complexity of the overall system, and it reduces scalability and reliability. Moreover, when the entity managing the authentication determines that the session should be destroyed, it typically does so by making a call across an authentication-specific application programming interface (API). This API may be serialized and, thus, it presents a potential single-point-of-failure.
The present invention is implemented in a method operative within a federated environment in which a point of contact serves as an intermediary between a client browser and an authentication service. According to a first step, the method provides an external authentication interface through which the authentication service authenticates a user associated with the client browser using information communicated in a first HTTP request-response exchange. That external authentication interface is then extended to enable the point of contact to terminate the user session using information passed in a second HTTP request-response exchange. The authentication service may be an identity provider that provides identity management in the federated environment.
Another embodiment of the invention is provided in a method that operative within a federated environment comprising at least one identity provider, and one service provider, and wherein a point of contact serves as an intermediary between a client browser and the identity provider. The method begins by issuing a first request to the identity provider using a first HTTP request-response exchange, wherein a response header associated with the first HTTP request-response exchange includes a session identifier. The session identifier is then used to create a user session. Subsequently (i.e., when it is desired to log out), a second request is issued to the identity provider using a second HTTP request-response exchange, and the HTTP response is received at the point of contact. A response header associated with the second HTTP request-response exchange includes the session identifier. Based on the HTTP response header having the associated session identifier, the POC destroys the user session.
The present invention provides a generic technique that externalizes the management of a user session, particularly in the context of a federated environment. The invention obviates any requirement to design and implement special software (or any requirement to modify a previously installed plug-in) to enable third party SSOp-aware applications to manage the lifecycle of a user session. In an illustrative embodiment, the user session lifecycle is managed externally through an external authentication interface (EAI) that has been extended to enable any POC (or SSOp-aware application) to interface to a federated identity provider component using a simple HTTP transport mechanism. In the inventive approach, HTTP request and response headers carry the information that is used by the POC to initiate and later destroy a user session, and such information is provided by a federated entity without requiring use of a special authentication API.
The foregoing has outlined some of the more pertinent features of the invention. These features should be construed to be merely illustrative. Many other beneficial results can be attained by applying the disclosed invention in a different manner or by modifying the invention as will be described.
For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
Generally, the present invention may operate in conjunction within the standard client-server paradigm in which client machines communicate with an Internet-accessible Web-based portal (or, more generally, target server or site) executing on a set of one or more machines. End users operate Internet-connectable devices (e.g., desktop computers, notebook computers, Internet-enabled mobile devices, cell phones having rendering engines, or the like) that are capable of accessing and interacting with the destination. Typically, each client or server machine is a data processing system comprising hardware and software, and these entities communicate with one another over a network, such as the Internet, an intranet, an extranet, a private network, or any other communications medium or link. As described below, a data processing system typically include one or more processors, an operating system, one or more applications, and one or more utilities. The applications on the data processing system provide native support for Web services including, without limitation, support for HTTP, SOAP, XML, WSDL, UDDI, and WSFL, among others. Information regarding SOAP, WSDL, UDDI and WSFL is available from the World Wide Web Consortium (W3C), which is responsible for developing and maintaining these standards; further information regarding HTTP and XML is available from Internet Engineering Task Force (IETF). Familiarity with these standards is presumed in the following discussion.
As will be described, the present invention typically is implemented in a system that includes an access manager, which is a component that prevents unauthorized use of resources, including the prevention of use of a given resource in an unauthorized manner. A representative access manager is the Tivoli® Access Manager product, which is available commercially from IBM. Of course, the identification of this commercial product is merely for purposes of explanation, and it is not meant to be taken to limit the present invention. More broadly, any system, device, program or process that provides a policy/access/service decision may be used for this purpose.
By way of additional background,
The authentication mechanism 304 typically executes in Web server 308, although this is not a requirement as this function may be carried out by a application server 310.
Authorization, in contrast to authentication, determines what resources an authenticated client can use. For example, a customer may only be able to access e-business applications from the Internet, whereas an employee might also be permitted to access corporate applications. An authorization mechanism 306 provides this function. The Web server component 302 also provides a single sign-on, coarse-grained access control (namely, whether one can access the Web server 308 or not), high availability, and scalability. As shown in
With the above as background, the present invention is now illustrated and described. As mentioned previously, preferably the invention is implemented within a federated identity management (FIM) scenario, wherein typically different organizations assume the role of an identity provider or a service provider. These roles are not necessarily mutually exclusive. An identity provider is an organization that directly manages end users. It acts as the authoritative source for issuing and validating user identities and network credentials for a set of users; thus, an identity provider “owns the user relationship.” For example, many companies act as identity providers for employees, customers, and contractors. Identity providers “vouch” for the user identity and their entitlements in a federated interaction with service providers. The “identity provider” role can be thought of as an authentication authority. A service provider provides “services” for end users. A service provider typically does not have a vested business interest in managing the user. Thus, service providers act as a “relying party” to validate credentials issued by a trusted identity partner, on the basis of which they provide services to that trusted identity. A federated model simplifies administration and enables companies to extend identity and access management to third-party users and third-party services.
The “lifecycle” of a user's session extends from the time of first authenticating the user (e.g., via log in, single-sign in, or the like) until the session is subsequently destroyed, either due to a lack of activity on the system, or by a voluntary user action (e.g., via log out, sign out or the like). Thus, in one embodiment, a user session lifecycle persists for the time period during which a POC session cache maintains a cache entry (or at least a valid one) about that session. As noted above, a user session is established by building a credential for the user based on authentication data, and then binding the user to the credential. According to a feature of the present invention, the user session lifecycle is “externalized” by extending an external authentication interface (EAI) 414, which is used to create the session, to allow the identity provider 410 (or some other entity) to force the POC 408 to terminate a session that the POC created. As will be seen, the external authentication interface takes advantage of simple HTTP header requests and responses to enable third party POC- and SSOp-aware applications to manage the lifecycle, namely, to create the user session, and then, as required, to destroy it.
An external authentication interface (such as the interface provided by Tivoli Access Manager) allows an independent remote service, such as a federated identity provider, to handle the authentication process for the POC (e.g., a proxy, a Web server plug-in, or the like). The identity information returned by the external authentication interface service is used to generate user credentials, as has been previously described. Typically, the external authentication interface returns user identity information in HTTP response headers rather than through an authentication module interface or other API. As described in more detail below, this existing mechanism is extended according to the present invention to fully externalize the creation and destruction of the user session.
The external authentication interface is not a replacement for built-in or custom authentication modules. Rather, the external authentication interface provides a convenient and flexible authentication capability for many environments. Thus, for example, the external authentication interface can be used with applications written in any language, including Java. Using the external authentication interface, the authentication operation is performed external to the POC (or its SSOp-aware application), e.g., by an application or component located on a remote, junctioned server. This application or component should return identity information resulting from the authentication process, preferably in HTTP response headers as will be described.
Step 2 is the authentication request and response exchange. The process of authentication may require a number of exchanges between the external authentication application and the client. Preferably, exchanges are streamed through (not intercepted) by the POC. The final authenticating request to the external authentication application typically is directed to a distinct URL. This URL, for example, could include a query string that indicates a log in task. Typically, the final URL is specified in a configuration file as a trigger URL. If the trigger URL is detected, the POC examines the corresponding response for authentication data located in HTTP headers (specified in a POC configuration file). By way of example, the user clicks a submit link on a custom log in page. This link is the trigger URL. The recognition of the trigger URL in the request causes the POC to look for authentication data in the corresponding response. The external authentication application authenticates the user and, in its response, populates the HTTP headers with authentication data. In another example, it is assumed that the external authentication application requires several exchanges with the user to receive the required login information. In such case, each request to the external authentication application uses the trigger URL. For each response, POC looks for authentication data. In particular, POC examines each corresponding response for authentication data returned from the external authentication interface in HTTP headers. When no authentication takes place, these headers are empty in each response. POC continues streaming the requests and responses without taking any action. After several exchanges, the external authentication application is presumed to receive the log in information it needs. The external authentication application authenticates the user and, in its final response, populates the HTTP headers with authentication data. In yet another example, it is assumed that the external authentication application requires several exchanges with the user to receive the required log in information. Each request to the external authentication application uses a URL that does not match the trigger URL. Therefore, for each corresponding response, the POC does not look for authentication data. The POC streams the requests and responses without taking any action. The final request to the external authentication application, however, uses the trigger URL. The recognition of the trigger URL in this final request causes the POC to look for authentication data in the corresponding response. The external authentication application authenticates the user and, in its final response, populates the HTTP headers with authentication data.
Step 3 is the authentication response. Here, the POC examines the corresponding response and finds the authentication data in the HTTP headers. At step 4, the POC uses the authentication data to build a credential for the user. Then, at step 5, the POC sends a response to the user, typically with the following precedence: if automatic redirection is enabled, the user is redirected to the location specified in a POC configuration file; if the initial request was cached, the request is reprocessed for the user; if the response from the external authentication application contains a redirection URL header, the user is redirected to the location specified by that URL; otherwise, the POC responds with a log in success page. This completes the process of initiating the user session lifecycle (which, as noted above, creates the session cache entry).
As also noted above, given HTTP headers preferably contain the authentication data returned from the external authentication application. These headers may be specially named, although this is not a requirement. There may be several categories of HTTP headers used to hold authentication data. For example, a Privilege Attribute Certificate (PAC)-named header may be used PAC is an ASN.1 data structure used to express identity information. Authentication data returned to the POC in PAC format can be directly converted to a credential. Another category is a user identity-named header. When the user identity format type is used, the information is processed by the authentication module and a credential is built by the access manager authorization API. The special HTTP headers contain authentication data provided by the external authentication application. The presence of either the PAC header or the user identity header causes the POC to extract the authentication data from the headers and build a credential for the user.
According to the present invention, the above-described external authentication interface is extended to allow the FIM (or other authentication entity) to make a log out (or sign out) call to the POC. This extension enables the POC (the calling entity) to terminate the session that it created. In a preferred embodiment, the call also is accomplished using the same HTTP request and response protocol described above in connection with the log in scenario. In this manner, it can be seen that the external authentication interface 414 now provides control over both the creation of a user session, as well as the termination of that session, in effect providing the externalized lifecycle management that is an object of the present invention. This operation provides significant advantages over the prior art. As one of ordinary skill in the art will appreciate, by extending the EAI to facilitate HTTP-header based operations (log in, sign in, log out and sign out), the inventive method provides a generic technique that externalizes the management of a user session so that third party SSOp-aware applications can easily manage the session's lifecycle. Externalizing the user session lifecycle moves specific POC implementation details away from the SSOp application, to the POC that is better able to manage the session. This has the advantage of decreasing product development time and increases the flexibility of the system to handle more POC types.
HTTP uses the known client-server model wherein an HTTP client opens a connection and sends a request message to an HTTP server; the server then returns a response message, which usually contains the resource that was requested. The format of the request and response messages are similar and each typically comprises an initial line, zero or more header lines (each with a value), a blank line, and an optional message body. Header lines provide information about the request or response, or about the object sent in the message body. The header lines are in a text format, typically one line per header, of the form “header-name: value”, ending with one or more control characters. HTTP headers are extensible to include additional information.
In one embodiment, an EAI lifecycle header has the following general format: {header-name: action|name1=value1; name2=value 2, name3=value 3, and so on for other extended attributes}. The “action” attribute may not be required if the type of action is identified by the header name itself. For example, a log in action may use header-name EaiLogin, and the log out action may use header-name EaiLogout. Because the type of action is defined by the name, there is no need for an explicit “action” attribute, for example, describing “log in” or “log out.” In some circumstances it may be desirable to use existing header names, in which case the action attribute may be used to describe the particular function. The request and response header values will depend on the action being taken. For example, for log in, the HTTP request header may include values designating user credential details (such as group membership, attributes, or the like), as well as an optional SSOp message (that may include one or more user attributes or other information that an SSOp component may require). The HTTP response header values also will depend on the action being taken. Typically, the response header values describe the action that was fulfilled by the request (e.g. log in, log out), and provide other information and data, such as server-specific details, user identifier details, and session identifier details. Thus, for example, the following is the HTTP response header returned to the POC from an FIM component after it (the FIM) has initiated a log out:
EaiLogout: userid=jon.doe; sessionid=68B86DFF8E4A8597B210531C3431965D
This HTTP response header terminates the session by deleting the session identifier entry from the session cache. As noted above, this action terminates the user session lifecycle, under external control.
There may be multiple HTTP request-response exchanges across the extended EAI to facilitate management of the user session lifecycle.
Moreover, while the above described uses HTTP as the underlying transport protocol, other request-response transport protocols, such as HTTPS, may be used as well.
The present invention is not limited to a Web-based portal having a point of contact that provides authentication, session management and authorization, but this will be a typical implementation. The invention may be used in any system, device, portal, site, or the like.
More generally, the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention (comprising the client side functionality, the server side functionality, or both) is implemented in software, which includes but is not limited to firmware, resident software, microcode, and the like. Furthermore, as noted above, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
One or more of the above-described functions may also be implemented as a service in a hosted manner.
While the above describes a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary, as alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, or the like. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic.
Finally, while given components of the system have been described separately, one of ordinary skill will appreciate that some of the functions may be combined or shared in given instructions, program sequences, code portions, and the like.
Having described our invention, what we now claim is as follows.
