KR100992016B1 - Method and apparatus for providing federated functionality within a data processing system - Google Patents

Abstract

A method and system for providing federated functionality within a data processing system is disclosed. Receive the first input request at the contact functionality. In response to determining that the information derived from the received request requires processing by the federated user lifecycle management functionality, the derived information is transferred from the contact functionality to the federated user lifecycle management functionality.

Federated User Lifecycle Management Capabilities, Data Processing Systems, Contacts

Description

Method and apparatus for providing federated functionality within a data processing system {METHOD AND APPARATUS FOR PROVIDING FEDERATED FUNCTIONALITY WITHIN A DATA PROCESSING SYSTEM}

The present invention relates to an improved data processing system, and more particularly, to a method and apparatus for multicomputer data transmission. In particular, the present invention relates to a network computer system.

Businesses generally want to provide secure access to protected resources to authorized users in a user-friendly manner through various networks, including the Internet. Although providing a secure authentication mechanism reduces the risk of access to unauthorized protected resources, such authentication mechanisms can be a barrier to access to protected resources. Users generally want the ability to change from interacting with one application to another, regardless of the authentication failure that protects each particular system that supports the application.

As the user becomes more complex, the user expects the computer system to adjust the actions to reduce the burden on the user. This type of expectation also applies to the authentication process. Once a user is authenticated by any computer system, the authorization must be valid for the user's work session or at least a certain period of time, regardless of the various computer architecture boundaries that the user rarely sees. Organizations typically meet these expectations in the operating characteristics of systems deployed to increase user efficiency, as well as to calm users, whether user efficiency is related to employee productivity or customer satisfaction. I'm trying.

In particular, in current computing environments with a web-based user interface where many applications can be accessed through a common browser, users may experience low or infrequent obstacles and more to moving from one web-based application to another. Expect high user friendliness. In this context, the user expects a jump from an interaction with an application on one Internet domain to another application on another domain, regardless of the authentication impairment protecting each particular domain. However, even though many systems provide secure authentication via an easy-to-use web-based interface, a user can still be forced to consider multiple authentication processes that prevent user access through a set of domains. Receiving multiple authentication processes within a given time frame can have a big impact on the efficiency of the user.

For example, various techniques have been used to reduce the authentication burden on users and computer system administrators. These techniques are generally described as a "single-sign-on (SSO) process, because these techniques allow the user to perform other authentication after the user completes a signing operation, that is, after authentication. This is because it has a common purpose that does not require you to perform an action, so the goal is for the user to complete only one authentication process during a particular user session.

In order to improve interoperability among businesses and reduce user management costs, federated computing spaces have been created. The federation is a loose alliance of firms adhering to any standard of interoperability, which provides a mechanism for trust between firms for any computational operations on users within the federation. For example, the federation partner can act as the user's home domain or identity provider. Other partners in the same federation may trust the user's identity provider for primary management of the user's authentication credentials, such as accepting a single-sign-on token provided by the user's identity provider.

As companies support federated enterprise interactions, these companies must provide a user experience that reflects the increased interaction between the two companies. As noted above, a user authenticates one party acting as an identity provider and provides single-sign-on to a federated business partner acting as a service provider. In combination with single-sign-on functionality, additional user lifecycle functionality such as account linking / unlinking and single-sign-off must also be supported within the federated computing environment.

Conventional, standards-based single-sign-on solutions, such as the WS-Federation specification or the free alliance ID-FF profile, provide a model for federated user lifecycle management to some extent, but these conventional specifications are particularly concerned with federated user lifecycle management functionality. It is not handled in such a way that the existing environment must be changed to include the functionality defined in the specification. In addition, existing computing environments may require extensive changes to support federated specifications or changes to existing computing environments to support federated specifications may not be feasible. Requires placement.

Additional user lifecycle functionality, such as link / disconnect and single-sign-off, should be supported so that federated user lifecycle management (FULM) functionality, in particular, does not require any infrastructure changes at any party.

Current computing environments solve this problem by providing single-sign-on functionality or by using private protocols. However, this solution does not allow for a "loosely coupled" environment where no new partners are brought online or remove old partners from the computing environment without making any changes to the environment. In addition, previous solutions do not allow a single entity to play multiple roles, for example, a business should be able to operate as an identity provider with one partner and as a service provider with a partner accordingly.

Summary of the Invention

According to a first aspect, a method for providing a federation function in a data processing system, the method comprising: receiving a first input request at a contact functionality; And in response to determining that information derived from the received request requires processing by federated user lifecycle management functionality, transferring the derived information from the contact functionality to the federated user lifecycle management functionality. This is provided.

In a preferred embodiment, the first request is received from a client of the contact functional component of the first service provider, the contact functional component performs session management for the first service provider for the client of the first service provider, and the service provider It is coupled with a plurality of service providers within a federated computing environment. In this embodiment, the step of sending responds to the determination that subsequent processing of the first request requires prior invoking of the federated user lifecycle management function. In this embodiment, the sending comprises sending a second request from the contact functional component of the first service provider to the federated user lifecycle management functional component of the first service provider, wherein the second request is the first request. Include information derived from

In a preferred embodiment, the contact functionality is in a domain and the domain is combined with a plurality of domains in a federated computing environment. In this embodiment, the method includes analyzing an input request for contact functionality; And in response to determining that the received request does not require processing by the federated user lifecycle management functionality to access a resource controlled by the resource access functionality, sending the received request from the contact functionality to the resource access functionality. It includes. In this embodiment, the information derived from the received request is the received request itself, and in this embodiment, the federated user lifecycle management function is combined with the federated user lifecycle management function to provide one or more federated user lifecycle management functions. Invoke one or more plug modules that interact.

According to another aspect, an apparatus for providing federated functionality in a data processing system, comprising: means for receiving a first input request at a contact functionality; And means for transmitting the derived information from the contact functionality to the federated user lifecycle management functionality in response to determining that the information derived from the received request requires processing by the federated user lifecycle management functionality. Is provided.

In a preferred embodiment, the first request is received from a client of the contact functional component of the first service provider, the contact functional component is operable to perform session management for the first service provider for the client of the first service provider, The service provider is coupled with a plurality of service providers in a federated computing environment. In this embodiment, the means for sending responds to the determination that subsequent processing of the first request requires prior invoking of the federated user lifecycle management function. In this embodiment, the means for sending comprises means for sending a second request from the contact functional component of the first service provider to the federated user lifecycle management functional component of the first service provider, the second request being the first request. Include information derived from

In a preferred embodiment, the contact functionality is in a domain and the domain is combined with a plurality of domains in a federated computing environment. In this embodiment, the apparatus comprises means for analyzing an input request for contact functionality; And means for sending the received request from the contact functionality to the resource access functionality in response to determining that the received request does not require processing by the federated user lifecycle management functionality to access a resource controlled by the resource access functionality. It includes. The information derived from the received request is the received request itself, and the federated user lifecycle management function provides access to federated user lifecycle management functions by invoking one or more plug-in modules that interact with the federated user lifecycle management functions. Respond to the request.

According to another aspect, a computer program product on a computer readable medium for use in a data processing system that provides federated functionality, comprising: means for receiving a first input request in contact functionality; And means for transferring the derived information from the contact functionality to the federated user lifecycle management functionality in response to determining that the information derived from the received request requires processing by the federated user lifecycle management functionality. Program product is provided.

In a preferred embodiment, the first request is received from a client of the contact functional component of the first service provider, the contact functional component is operable to perform session management for the first service provider for the client of the first service provider, The service provider is coupled with a plurality of service providers in a federated computing environment. In this embodiment, the means for sending responds to the determination that subsequent processing of the first request requires prior invoking of the federated user lifecycle management function. In this embodiment, the means for sending comprises means for sending a second request from the contact functional component of the first service provider to the federated user lifecycle management functional component of the first service provider, the second request being the first request. Include information derived from

In a preferred embodiment, the contact functionality is in a domain and the domain is combined with a plurality of domains in a federated computing environment. In this embodiment, the computer program product comprises means for analyzing an input request for contact functionality; And means for sending the received request from the contact functionality to the resource access functionality in response to determining that the received request does not require processing by the federated user lifecycle management functionality to access a resource controlled by the resource access functionality. It includes. The information derived from the received request is the received request itself, and the federated user lifecycle management function provides access to federated user lifecycle management functions by invoking one or more plug-in modules that interact with the federated user lifecycle management functions. Respond to the request.

According to another aspect, a contact server that receives an input request; And a second application server for interacting with the contact server, wherein the second application server includes means for responding to a request for access to a federated user lifecycle management function.

In a preferred embodiment, the input request is sent to a domain, which domain is combined with a plurality of domains in a federated computing environment. In this embodiment, the system comprises a first application server that interacts with the contact server, the first application server comprising means for responding to a request for access to a control resource, and a federated user lifecycle management function The second application server means for responding to a request for access to the device comprises one or more plug modules that interact with the second application server.

According to another aspect, a method of providing federated functionality in a data processing system, comprising: receiving an input request at a contact functionality in a domain, the domain being coupled with a plurality of domains in a federated computing environment; Analyzing an input request for the contact functionality; In response to determining that the received request does not require processing by the federated user lifecycle management functionality to access a resource controlled by the resource access functionality, sending a received request from the contact functionality to the resource access functionality. step; In response to determining that the received request requires processing by federated user lifecycle management functionality, sending the received request from the contact functionality to the federated user lifecycle management functionality, wherein the federated user life A cycle management function is provided for invoking one or more plug modules that interact with the federated user lifecycle management function to provide one or more federated user lifecycle management functions.

According to another aspect, an apparatus for providing federated functionality in a data processing system, comprising: means for receiving an input request at a contact functionality in a domain, the domain being combined with a plurality of domains in a federated computing environment; Means for analyzing an input request for the contact functionality; Means for sending a received request from the contact functionality to the resource access functionality in response to determining that the received request accesses a resource controlled by a resource access functionality; Means for sending the received request from the contact functionality to the federated user lifecycle management functionality in response to determining that the received request accesses federated user lifecycle management functionality, wherein the federated user lifecycle management functionality is included. A function is provided for responding to a request for access to a federated user lifecycle management function by invoking one or more plug-in modules that interact with the federated user lifecycle management function.

According to another aspect, a computer program product on a computer readable medium for use in a data processing system that provides federated functionality, comprising: means for receiving an input request at contact functionality in a domain, the domain associated with a plurality of domains in a federated computing environment -; Means for analyzing an input request for the contact functionality; Means for sending a received request from the contact functionality to the resource access functionality in response to determining that the received request accesses a resource controlled by a resource access functionality; Means for sending the received request from the contact functionality to the federated user lifecycle management functionality in response to determining that the received request accesses federated user lifecycle management functionality. A computer program product is provided that responds to a request for access to a federated user lifecycle management function by invoking one or more plug-in modules that interact with the federated user lifecycle management function.

According to another aspect, a contact server for receiving an input request sent to a domain, the domain being combined with a plurality of domains in a federated computing environment; A first application server for interacting with the contact server, the first application server comprising means for responding to a request for access to a control resource; And a second application server for interacting with the point-of-contact server, the second application server comprising means for responding to a request for access to a federated user lifecycle management function. Means for responding to a request for access of a data processing system are provided that include one or more plug modules for interacting with the second application server.

According to another aspect, a method for providing federated functionality within a data processing system, the method comprising: receiving a first request from a client at a contact functional component of a first service provider, the contact functional component to a client of the first service provider; Perform session management for the first service provider and the contact functional component is coupled with a plurality of service providers in a federated computing environment; And in response to determining that subsequent processing of the first request requires pre-invoke of a federated user lifecycle management function, from the junction functional component of the first service provider, the federated user lifecycle management functional component of the first service provider. Sending a second request to the second request, wherein the second request includes information derived from the first request.

According to another aspect, an apparatus for providing federated functionality within a data processing system, comprising: means for receiving a first request from a client at a contact functional component of a first service provider, the contact functional component being directed to a client of the first service provider Perform session management for the first service provider and the contact functional component is coupled with a plurality of service providers in a federated computing environment; And in response to determining that subsequent processing of the first request requires pre-invoke of a federated user lifecycle management function, from the junction functional component of the first service provider, the federated user lifecycle management functional component of the first service provider. Means for sending a second request to the second request, wherein the second request includes information derived from the first request.

According to another aspect, a computer program product on a computer readable medium for use in a data processing system that provides a federated environment, comprising: means for receiving a first request from a client at a contact functional component of a first service provider—the contact functional component Perform session management for the first service provider for a client of the first service provider and the contact functional component is coupled with a plurality of service providers in a federated computing environment; And in response to determining that subsequent processing of the first request requires pre-invoke of a federated user lifecycle management function, from the junction functional component of the first service provider, the federated user lifecycle management functional component of the first service provider. Means for sending a second request in a second order, the second request including information derived from the first request.

A method and system are disclosed in which a federated service provider preferably interacts within a federated environment to initiate federated operations. According to a preferred embodiment, the contact component providing session management capabilities of the first service provider receives a request from the client. The request is preferably sent via a client to the federated user lifecycle management functional component of the first service provider, and the federated user lifecycle management functional component of the first service provider interacts with the contact component of the second service provider. To initiate the federated user lifecycle management function of the second service provider, and participate in the assistance of the federated user lifecycle management functional component of the second service provider. In response to the completion of the federated user lifecycle management function, the contact component of the first service provider preferably receives a response from the federated user lifecycle management functional component of the first service provider, and the original request may be further processed. .

Methods and systems are disclosed in which federated domains interact within a federated environment. Domains in a federation may preferably initiate federation operations for users of other federated domains. The point-of-contact server in the domain preferably relies on a trust proxy in the domain to manage the trust relationship between the domain and the federation. The contact server preferably receives input requests sent to the domain and interacts with the first application server and the second application server, the first application server preferably responding to the request for access to the control resource, and the second application. The server responds to a request for access to a federated user lifecycle management function, preferably implemented using one or more plug modules that interact with the second application server.

Preferably, a method and system are provided for implementing a federated specification incorporating functionality such that minimal changes to the infrastructure of an existing computing environment are required. Preferably, a method and system are provided for integrating federated user lifecycle management functionality with minimal impact on an existing computing environment.

Preferably, methods and systems are provided that enable an enterprise to implement federated user lifecycle management functionality in a highly configurable manner. In addition, the solution preferably supports multiple variations of federated user lifecycle management within a single environment, without additional infrastructure changes or additional instances of FULM applications.

Hereinafter, exemplary embodiments of the present invention will be described with reference to the following drawings.

1A illustrates a general network of data processing systems that may implement the present invention in accordance with a preferred embodiment.

1B illustrates a general computer architecture that may be used in a data processing system in which the present invention may be implemented in accordance with a preferred embodiment.

1C is a data flow diagram illustrating a general authentication process that may be used when a client attempts to access a protected resource at a server.

1D illustrates a network representing a typical web-based environment in which the present invention may be implemented.

1E is a block diagram illustrating an example of a typical online transaction requiring multiple authentication actions from a user.

2A is a block diagram illustrating terms of a federated environment for transactions initiated by a user to a first federated enterprise that invokes an action at a downstream entity in the federated environment in response.

2B is a block diagram illustrating the integration of an existing system with a portion of the federated architecture component of the present invention in accordance with an embodiment of the present invention in a given domain.

2C is a block diagram illustrating a federated architecture in accordance with an implementation of the present invention.

FIG. 2D is a block diagram illustrating an exemplary set of trust relationships between federated domains using a trust proxy and a trust broker in a preferred embodiment of the present invention. FIG.

3A is a flow diagram illustrating a process generalized in an issuing domain for generating assertions in a federated environment, in accordance with a preferred embodiment.

3B is a flow diagram illustrating a generalized process in a dependency domain resolving assertions in accordance with a preferred embodiment.

3C is a flow diagram illustrating a particular process for sending an assertion from an issuing domain to a dependent domain in response to a user action in the issuing domain, in accordance with a preferred embodiment.

FIG. 3D is a flow diagram illustrating a particular process for sending an assertion from an issuing domain to a dependent domain in response to an issuing domain that actively prevents an output request to the dependent domain, in accordance with a preferred embodiment.

FIG. 3E illustrates a pull model in which the dependent domain requires any requested assertion for the user from the issuing domain while attempting to satisfy a resource request received by the dependent domain from the requesting user, according to a preferred embodiment. Flowchart Indicating.

4 is a block diagram illustrating a federated environment supporting federated single-sign-on operation, in accordance with a preferred embodiment.

5 is a block diagram illustrating some of the components in a federated domain that implement federated user lifecycle management functionality in accordance with an embodiment of the present invention.

6 is a data flow diagram illustrating a process for performing a single-sign-on operation using a federated user lifecycle management function in accordance with a preferred embodiment of the present invention.

Figure 7 is a block diagram illustrating the organization of logical components that separate trust relationship management from federated user lifecycle management, in accordance with a preferred embodiment.

8A is a block diagram illustrating high abstraction of logical functionality of a federated computing environment, in accordance with a preferred embodiment.

FIG. 8B is a block diagram illustrating a high level abstraction of the logical functions of a federated computing environment illustrating how the present invention provides separation of federated and contact functionality from trust relationship management functionality, in accordance with a preferred embodiment; FIG.

FIG. 8C is a block diagram illustrating the high abstraction of logical functionality of a federated computing environment illustrating how the present invention provides for separation of federated operational functionality from contact functionality, in accordance with a preferred embodiment; FIG.

8D is a block diagram illustrating a high level abstraction of logical functions of a federated computing environment illustrating how the present invention provides separation of federated operational functionality into federated user lifecycle management functionality and federated relationship management functionality, in accordance with a preferred embodiment;

9A, 9B and 9C are Venn diagrams illustrating how a federated relationship includes a trust relationship with respect to the selection of the federation function, according to a preferred embodiment.

10 is a data flow diagram illustrating a series of operations performed by a pair of business partners for interaction within a federated computing environment, in accordance with a preferred embodiment.

11 is a block diagram illustrating the interaction between business partners for establishing a trust relationship in preparation for establishing a federated relationship, in accordance with a preferred embodiment.

12 is a block diagram illustrating a configuration of a computing environment for including federation functionality, in accordance with a preferred embodiment.

 FIG. 13A is a block diagram illustrating a federated relationship management console application that may be used by a system administrator user to establish a federated relationship within an enterprise computing environment, in accordance with the preferred embodiment. FIG.

FIG. 13B illustrates a graphical user interface window in a federated relationship management application used by an administrative user to establish a federated relationship between federated partners, in accordance with a preferred embodiment. FIG.

13C and 13D are block diagrams illustrating the data flow initiated by a federated relationship management console application for obtaining data according to a partner to establish a federated relationship within an enterprise computing environment, according to a preferred embodiment.

FIG. 14 is a flow diagram illustrating a process in which a federation is established in an automated manner through the use of an exported / imported file exchanged between federated partners interacting through a federated relationship, according to a preferred embodiment.

In general, an apparatus including or related to the present invention includes various data processing techniques. Therefore, before describing the present invention in detail, the general organization of hardware and software components within a distributed data processing system is described.

Referring to the drawings, FIG. 1A illustrates a general network of data processing systems that can implement preferred embodiments of the present invention. Distributed data processing system 100 includes a network 101, which is a medium that can be used to provide a communication link between various devices and computers coupled together within distributed data processing system 100. Network 101 includes a permanent connection, such as a wired or fiber optic cable, or a temporary connection formed through telephone or wireless communication. In the example shown, server 102 and server 103 are connected to a network with storage unit 104. In addition, clients 105-107 are also connected to network 101. Clients 105-107 and servers 102-103 may be represented by various computing devices, such as mainframes, personal computers, personal digital assistants (PDAs), and the like. Distributed data processing system 100 may include another server, client, router, other device, and peer-to-peer architecture, not shown.

In the illustrated example, the distributed data processing system 100 uses a network that uses various protocols to communicate with each other, such as Lightweight Directory Access Protocol (LDAP), Transport Control Protocol / Internet Protocol (TCP / IP), HyperText Transport Protocol (HTTP), and the like. And the Internet having a network 101 representing a worldwide collection of gateways. Of course, distributed data processing system 100 may also include many other types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN). For example, server 102 directly supports network 110 and client 109 incorporating a wireless communication link. Networkable telephone 111 is connected to network 110 via wireless link 112 and PDA 113 is connected to network 110 via wireless link 114. Telephone 111 and PDA 113 may also transmit data to each other over wireless link 115 using appropriate techniques such as Bluetooth ^™ wireless technology to create a so-called personal area network or personal ad hoc network. . In a similar manner, PDA 113 may transmit data to PDA 107 via wireless communication link 116.

The invention can be implemented on a variety of hardware platforms and software environments. 1A is not intended to limit the architecture of the present invention but is intended as an example of a heterogeneous computing environment.

Referring to FIG. 1B, it illustrates a general computer architecture of a data processing system as shown in FIG. 1A in which the present invention may be implemented. The data processing system 120 includes one or more central processing units (CPUs) 122 connected to an internal system bus 123, the internal system bus 123 being a random access memory (RAM) 124, read only. Memory (ROM) 126 and input / output adapters 128 that support various I / O devices, such as printer 130, disk unit 132, or other devices not shown, such as an audio output system, are interconnected. The system bus 123 also connects a communication adapter 134 that provides access to the communication link 136. The user interface adapter 148 connects various user devices, such as keyboard 140 and mouse 142, or other devices not shown, such as touch screens, stylus, microphones, and the like. The display adapter 144 connects the system bus 123 to the display device 146.

It will be apparent to those skilled in the art that the hardware of FIG. 1B may vary with system implementation. For example, Intel ^TM Pentium ^TM One or more processors, such as a base processor and a digital signal processor (DSP), and one or more types of volatile and nonvolatile memory. Other peripheral devices may be used instead of or in addition to the hardware shown in FIG. 1B. The illustrated examples are not intended to limit the architecture of the present invention.

In addition to being able to be implemented on a variety of hardware platforms, the present invention can be implemented in a variety of software environments. General operating systems can be used to control program execution within each data processing system. For example, one device runs the Unix ^TM operating system, while the other device contains a simple Jave ^TM runtime environment. Typical computer platforms include a variety of graphics files, word processing files, Extensible Markup Language (XML), Hypertext Markup Language (HTML), Handheld Device Markup Language (HDML), Wireless Markup Language (WML), and a variety of other formats and types of files. A browser, which is a known software application that accesses a hypertext document in a format. The distributed data processing system shown in FIG. 1A is expected to be able to support various peer-to-peer subnets and peer-to-peer services.

1C is a data flow diagram illustrating a general authentication process that may be used when a client attempts to access a protected resource at a server. As shown, a user of client workstation 150 requires access via a computer network to a protected resource on server 151 via a user web browser running on the client workstation. Protected or controlled resources are those resources whose access is controlled or restricted (applications, objects, documents, pages, files, executable code or other computing resources, communication resources, etc.). Protected resources are identified by a Uniform Resource Locator (URL) or a Uniform Resource Identifier (URI) that can only be accessed by authorized and / or authorized users. The computer network may be the Internet, an intranet, or other network, as shown in FIG. 1A or 1B, and the server may be a web application server (WAS), server application, servlet process, or the like.

The process is initiated when the user requests a server-side protected resource such as a web page in the domain "ibm.com" (step 152). The terms "server side" and "client side" refer to an action or entity of a server or a client, respectively, in a networked environment. The web browser (or associated application or applet) issues an HTTP request that is sent to the web server hosting the domain "ibm.com" (step 153). The terms "request" and "response" should be understood to include data formatting for the transmission of information included in a particular operation, such as a message, communication protocol information or other related information.

The server determines that it does not have an active session for the client (step 154) and initiates and completes the establishment of a Secure Sockets Layer (SSL) session that transfers a large amount of information between the client and the server (step 155). After the SSL session is established, subsequent communication messages are sent within the SSL session, and any secret information is secure because of the encrypted communication message in the SSL session.

However, the server needs to determine the identity of the user before sending the client any type of authentication request, requiring the server to perform authentication processing to allow the user to access the protected resource (step 156). The certification application may be in various formats, such as an HTML form. The user then provides the requested information, such as a user name or other type of user identifier, along with the associated password or other form of secret information (step 157).

Authentication response information is sent to the server (step 158), at which point the server authenticates the user or client by retrieving previously submitted registration information and matching the presented authentication information with the user's stored information (step 159). Assuming authentication succeeds, an active session is established for the authenticated user or client. The server generates a session identifier for the client, and any subsequent request message from the client in the session may be accompanied by the session identifier.

The server then retrieves the originally requested web page and sends an HTTP response message to the client (step 160) to fulfill the user's original request for the protected resource. At this point, the user can request another page in " ibm.com " by clicking on a hypertext link in the browser window (step 161), and the browser sends another HTTP request message to the server (step 162). At this point, because the user's session identifier is returned to the server via an HTTP request message, the server recognizes that the user has an active session (step 163), and the server sends the requested web page via another HTTP response message to the client. Is sent to (step 164). Although FIG. 1C illustrates a typical conventional process, other session state management techniques, such as a URL that rewrites or uses a cookie that identifies the user as an active session, may be described, which uses the same cookie used to prove authentication. It may include doing.

1D is a diagram illustrating a network representing a general web-based environment in which the present invention may be implemented. In this environment, a user of the browser 170 of the client 171 wants to access a protected resource on the web application server 172 of the DNS domain 173 or the web application server 174 of the DNS domain 175.

In a manner similar to that shown in FIG. 1C, a user may request a protected resource in one of many domains. In contrast to FIG. 1C, which represents only a single server in a particular domain, each domain of FIG. 1D has multiple servers. In particular, each domain may have associated authentication servers 176 and 177.

In this example, after client 172 issues a request for a protected resource in domain 173, web application server 172 determines that it does not have an active session with client 171, and authentication server 176. Request a proper authentication operation with the client 171. The authentication server 176 sends the result of the authentication operation to the web application server 172. If the user (or browser 170 or client 171 representing the user) is successfully authenticated, the web application server 172 establishes a session with the client 171 and returns the requested resources. In general, once a user is authenticated by the authentication server, a cookie may be set and stored in a cookie cache in the browser. 1D is merely one example of how a domain's processing resources may be shared among multiple servers, in particular to perform an authentication operation.

In a similar manner, after client 171 requests a protected resource in domain 175, authentication server 177 performs the appropriate authentication operation with client 171, after which web application server 174 Establish a session for 171 and return the requested protected resource. Therefore, FIG. 1D shows that the client 171 has multiple concurrent sessions in different domains and needs to complete multiple authentication operations to establish a concurrent session.

1E is a block diagram illustrating an example of a typical online transaction requiring multiple authentication actions from a user. Referring back to FIGS. 1C and 1D, the user may be required to complete an authentication operation before accessing the control resource as shown in FIG. 1C. Although not shown in FIG. 1C, an authentication manager is placed on the server 151 to search and employ user information required to authenticate the user. As shown in FIG. 1D, a user may have multiple current sessions in different domains 173 and 175, although not shown in FIG. 1D, each domain employs an authentication manager in addition to or instead of an authentication server. can do. In a similar manner, FIG. 1E represents a set of domains, each of which supports any type of authentication manager. 1E illustrates some of the difficulties a user may experience when accessing multiple domains requiring the user to complete an authentication operation for each domain.

User 190 may be registered in ISP domain 191, which may support authentication manager 192 for authenticating user 190 for the purpose of completing a transaction with domain 191. ISP domain 191 may be an Internet service provider (ISP) that provides Internet connection services, email services, and other possible e-commerce services. Alternatively, ISP domain 191 may be an Internet portal frequently accessed by user 190.

Similarly, domains 193, 195 and 197 represent generic web service providers. Management domain 193 supports authentication manager 194 for authenticating users to perform various management related transactions. The banking domain 195 supports an authentication manager 196 that authenticates a user to conduct a transaction with an online bank. E-commerce domain 197 supports authentication manager 198 for authenticating users to fulfill online purchases.

As mentioned above, if a user attempts to move from one domain to another within the Internet or the World Wide Web by accessing resources from different domains, the user may receive multiple user authentication requests or requests, which is a set of domains. This can slow down the user's progress considerably. Using FIG. 1E as an exemplary environment, user 190 may participate in a complex online transaction with e-commerce domain 197, where the user is at least 18 years old and has a valid license, a valid credit card, and a U.S. Attempt to purchase an online service that is restricted to users with bank accounts. This online transaction may require domains 191, 193, 195 and 197.

In general, a user cannot maintain the identity and / or attributes within each domain that participated in a general online transaction. In this example, user 190 may be registered with his identity with a user ISP, but in order to complete an online transaction, the user may be required to authenticate to domains 193, 195, and 197. If each of the domains does not maintain an identity for the user, the user's online transaction may fail. Even if a user can be authenticated by each domain, it is not guaranteed that different domains can communicate with each other to complete a user's transaction. For user 190 shown in FIG. 1E, conventionally allows user 190 to authenticate a first web server, for example ISP 191, and, for single-sign-on purposes, authenticates an authentication token. There is no environment for delivering to other web service providers, such as domains 193, 195, and 197.

Prior to the brief description of the present technology, the description of the remaining figures relates to a federated computer environment in which the present invention may be operated. Before describing the preferred embodiment of the present invention in detail, several terms are introduced.

Terms

The term "entity" or "party" generally refers to an organization, person, or system that operates on behalf of an organization, person, or other system. The term "domain" implies additional characteristics within the network environment, but the terms "entity", "party" and "domain" may be used interchangeably. For example, the term "domain" may also refer to a data processing system that includes various devices and applications that appear as a logical unit for a Domain Name System (DNS) domain or more generally an external entity.

The term "request" or "response" should be understood to include data formatting for the transmission of information included in a particular operation, such as a message, communication protocol information or other related information. Protected resources are resources (applications, objects, documents, pages, files, executable code, other computing resources, communication resources, etc.) whose access is controlled or restricted.

The token provides direct evidence of a successful operation and is generated by the entity that performed the operation, for example, an authentication token generated after a successful authentication operation. The Kerberos token is an example of an authentication token that can be used in the present invention. More information about Cerberus can be found in Kohl et al., "The Kerberos Network Authentication service (V5)," Internet engineering Task Force (IETF) Request for comments (RFC) 1510, 09/1993.

Assertions are indirect evidence of any action. An assertion can provide indirect evidence of identity, authentication, attributes, authorization decisions, or other information and / or actions. The authentication assertion is not an authentication service but provides indirect evidence of authentication by an entity according to the authentication service.

Secure Assertion Markup Language (SAML) assertion is an example of a possible assertion format that can be used in the present invention. SAML has been disseminated by the Organization for the Advancement of Structured Information Standards (OASIS), a non-profit global consortium. SAML is described in "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)", Committee Specification 01, 05/31/2002, as follows.

Security Assertion Markup Language (SAML) is an XML-based framework for exchanging security information. This security information is represented in the form of an assertion for a subject, which is an entity (person or computer) with an identity in any security domain. A common example of a subject is a person identified by the email address of a particular Internet DNS domain. The assertion can convey information about authentication actions performed by the subject, attributes of the subject, and authorization decisions as to whether the subject is allowed to access a given resource. An assertion is represented as an XML construct and has a nested structure so that one assertion can contain several different internal statements for authentication, authorization, and attributes. An assertion containing an authentication statement simply describes the action of the authentication that occurred previously. Assertions are issued by the SAML authority, that is, the certification authority, attribute authority, and policy decision point. SAML defines the protocol by which a client can request an assertion from a SAML authority and get a response from them. The protocol, which consists of XML-based request and response message formats, can be coupled to many different underlying communication and transport protocols, and SAML currently defines what is coupled to SOAP over HTTP. In generating their responses, the SAML authority may use various sources of information, such as received assertions and external policy accumulation, as inputs to the request. Thus, the client always consumes the assertion, while the SAML authority can be the producer and soba of the assertion.

The SAMP specification describes that an assertion is an information package that supplies one or more statements made by an issuer. SAML allows three different types of assertion statements to be issued by the issuer: an authentication in which the specified subject is authenticated by a certain means at a specific time, an authorization that is granted or denied to allow the specified subject to access the specified resource, or an attribute provided with the specified subject. Create a property related to. As described below, various assertion formats can be converted to other assertion formats as needed.

Authentication is the process of validating the set of certificates provided on behalf of or by a user. Authentication is accomplished by verifying what the user knows, what the user has, the physical characteristics of the user, ie the user. Knowing a user may include what is only known to a particular user, such as a shared secret such as a user's password or a user's encryption key. What the user has may include a smart card or hardware token. Any physical characteristic for the user may include a biological input, such as a fingerprint or retinal map.

A certificate is a set of application / response information used in various authentication protocols. For example, a username and password combination is the best known form of a certificate. Other forms of certificates may include other forms such as application / response information, public key infrastructure (PKI) certificates, smart cards, biometrics, and the like. Certificates are distinct from authentication assertions. That is, the certificate is given by the user as part of an authentication protocol sequence with an authentication server or service, and the authentication assertion is a statement for successful submission and validation of the user's certificate that is subsequently sent between entities as needed.

Conventional single-on-sign Solution  division

As mentioned above, conventional single-sign-on solutions are limited to homogeneous environments with pre-established business agreements between participating companies. These business agreements establish reliable, limited and secure information transfer between companies. These business agreements also include technical agreements on rules about how to transfer and map user identities from one company to another, and how to pass information used to endorse users between participating companies.

In other words, previous single-sign-on solutions allow one company to trust authentication assertions (along with the user's identity provided to the assertion) generated by another company based on pre-negotiated or preconfigured agreements. Each separate company knows how to create and interpret authentication assertions that can be understood by other companies that exchange similar agreements, such as those in the e-commerce market. These homogeneous environments are tightly coupled. This is because there is a deterministic relationship known by companies that map user identities through these systems. This tight coupling is possible because of the business agreement used to establish a single-sign-on environment.

Preferred of the present invention Example  Union model

In view of the world wide web, users expect the ability to jump from interaction with an application on one Internet domain to another application on another domain for the information barrier between each particular domain. The user does not want to be frustrated by authenticating multiple domains for a single transaction. In other words, the user expects the organization to interact, but the user does not want a domain for their privacy. In addition, the user may want to restrict the domains that permanently store personal information. These user expectations exist in a rapidly evolving heterogeneous environment in which many companies and organizations compete for authentication technology.

In contrast to conventional systems, the present invention provides a federation model that allows an enterprise to provide a single-sign-on experience to a user, in accordance with a preferred embodiment. In other words, the present invention supports a federated heterogeneous environment in accordance with a preferred embodiment. For example, referring back to FIG. 1E, user 190 can authenticate domain 191 and enable domain 191 to provide appropriate assertions for each downstream domain that may be required for a transaction. . These downstream domains need to understand and trust authentication assertions and / or other types of assertions, even if there are no preset assertions between domain 191 and other downstream domains. In addition to recognizing assertions, even if there is no pre-set identity mapping relationship, the downstream domain needs to convert the identity contained within the assertion to an identity representing a user 190 in a particular domain. The present invention may be applied to various types of domains and is not limited to the ISP type domain shown in FIG. 1E as an exemplary domain.

The present invention relates to a federated environment. In general, a company has its own user registry and maintains a relationship with its set of users. Each enterprise generally has its own means of authenticating these users. However, the federation scheme of the preferred embodiment of the present invention allows enterprises to collaborate in a collaborative manner so that users within an enterprise can influence relationships between the companies through their participation in the enterprise's federation. Users can access resources from one of their federated companies as if they had a direct relationship with each company. The user is not required to register with each enterprise of interest and is not always required to identify and authenticate the user. Therefore, within this federated environment, authentication schemes allow for a single-sign-on experience in heterogeneous environments that are rapidly evolving in information technology.

In a preferred embodiment of the present invention, federation is a collection of discrete entities such as corporations, organizations, associations, etc. that cooperate to provide a single-sign-on and easy-to-use experience for the user. In a preferred embodiment of the present invention, the federated environment differs from a typical single-sign-on environment in that no two enterprises need a pre-established direct relationship that defines what information is delivered to the user. In a federated environment, an entity handles authentication users, accepting authentication assertions, for example, authentication tokens presented by other entities, and providing a transition to an identity that can be understood within a local entity by an authenticated user's identity. Provide service.

The coalition eases the administrative burden on service providers. The service provider can rely on a reliable relationship to the federation as a whole. The service provider does not need to manage authentication information such as user password information. This is because the authentication achieved by the user's authentication home domain / identity provider can be trusted.

The present invention is directed to a federated identity management system that establishes a basis for loosely coupled authentication, user enrolment, user profile management, and / or authorization services to collaborate across secure domains. Federated identity management allows services residing in heterogeneous security domains to operate and collaborate, even if there are differences in underlying security mechanisms and operating systems in heterogeneous domains. The single-sign-on experience is established when the user joins the federation.

Home domain or identity  Provider to dependent domain or service provider

As will be described in detail below, the present invention provides the user with significant advantages. The present invention allows a user to authenticate a first entity (hereinafter also referred to as a user home domain, user authentication home domain, or user identity provider) in accordance with a preferred embodiment. This first entity can act as an issuing party that issues authentication assertions for users used at the second entity, which can be considered as generalized service providers. The user can then access the protected resource at a second entity, a separate second entity called a dependency party, by presenting an authentication assertion issued by the first entity without explicitly re-authenticating at the service provider. The information passed from the issuing party to the dependent party is in the form of an assertion, which may include other types of information in the form of statements. For example, an assertion can be a statement for a user's authenticated identity or a statement for user attribute information associated with a particular user.

2A is a block diagram illustrating the terminology of a federated environment for a transaction initiated by a user to a first federated enterprise that invokes an action at a downstream entity in the federated environment in response. 2A indicates that the terminology may vary depending on the entity's perspective within the federation for a given federation operation. In particular, FIG. 2A illustrates that the present invention supports the transitivity of trust and the transitability of the authentication assertion process in accordance with a preferred embodiment and based on the trust of the identity as the domain is asserted by another domain. Indicates that an assertion can be issued. User 202 initiates a transaction with a request for a protected resource at enterprise 204. If user 202 is authenticated by enterprise 204 or will eventually be authenticated by enterprise 204 in the course of a transaction, enterprise 204 may, during this federation session, user home domain, i.e., a user identity provider. to be. Assuming a transaction requires any type of operation by enterprise 206 and enterprise 204 passes the assertion to enterprise 206, enterprise 204 is the issuing domain for the particular operation and enterprise 206 Becomes the dependency domain for that operation. In other words, enterprise 206 becomes a service provider for the current transaction. If the transaction requires another operation for the enterprise 206 to forward the assertion to the enterprise 208, the enterprise 206 is the issuing domain for the requested operation and the enterprise 208 is the dependent domain for that operation. In this case, even though the federated transaction is described as including only two domains including an identity provider and a service provider, the enterprise 208 can be considered as another downstream service provider.

In the federated environment of the preferred embodiment, the domain to which the user authenticates is called the user (authentication) home domain or user identity provider. The identity provider maintains a certificate that can be physically supported by the user's employee, the user's ISP, or any other commercial entity. Since there may be many companies with the ability to generate and validate a user's certificate, there may be many companies in the federated environment that can act as user home domains, but federated transactions generally involve one identity provider. It may be described.

In terms of authentication, the issuing party for the authentication assertion is generally the user identity provider, i.e., the user authentication home domain. The user home domain may or may not maintain profile information or personal information for the user. Therefore, in terms of attributes including personally identifiable information, personalization information, or other user attributes, the publishing party for the attribute assertion may or may not be the user home domain. To avoid any confusion, separate terms may be employed for the attribute home domain and the authentication home domain, but the term “home domain” may be interpreted hereinafter as the authentication home domain.

However, within the scope of a given federated session, there is only one domain that acts as a user identity provider, i. E. A user home domain. Once a user is authenticated in this domain, during that session, all other domains or enterprises in the federation are treated as service providers, i.e., dependent parties.

If the present invention preferably provides a federated infrastructure that can be added to an existing system while minimizing conflicts with existing non-federated architectures, authentication at the user's home domain can be avoided by the fact that the home domain can participate in the federated environment. It does not necessarily change. In other words, even if the home domain is integrated into a federated environment implemented in accordance with the preferred embodiment of the present invention, the user must have the same end user experience while performing authentication operations in the user home domain. Not all users of a given enterprise will necessarily participate in the federated environment.

In addition, user registration, eg, establishing a user account, is not necessarily changed by the fact that the home domain can participate in a federated environment. For example, a user can still establish an account in a domain through an existing registration process or legacy that is independent of the federated environment. In other words, the establishment of a user account in the home domain may or may not include the establishment of valid account information across the federation, for example through identity translation information. However, if there is a single federated domain that can authenticate users, that is, if a user is within a registered federation, that domain will act as a user home domain or identity provider to support user transactions within the federated environment. It is expected.

If a user has as many home domains as possible within the federated environment, the user can enter the federation through one or more entry points. In other words, a user may have an account in multiple domains that may act as an identity provider for the user, and these domains do not necessarily have information about other domains or information about user identities in other domains.

A user authenticated domain is called a user home domain or user identity domain, but an issuing domain is a federated entity that issues assertions used by other domains, that is, dependent domains. The issuing domain is typically, but not necessarily, a user home domain or a user identity provider. Therefore, there may be a case where the issuing party issues a user through a general authentication protocol as described above. However, since the issuing party is previously operable as a dependent party, it receives an assertion from another issuing party. In other words, since the user initial transaction is performed in stages through a series of enterprises in a federated environment, the receiving party can later act as an issuing party for downstream transactions. In general, any domain that has the ability to issue authentication assertions on behalf of a user can act as an issuing domain.

The dependency domain is the domain that receives the assertion from the publishing party. The relying party can accept, trust and understand assertions issued by the third party on behalf of the user, that is, the issuing domain. It is the duty of the dependent party to interpret the authentication assertion using the appropriate certification authority. In addition, the relying party may operate as a specific user, that is, as a user home domain or identity provider, but the relying party may not authenticate the specific user through conventional methods. Therefore, the relying party is a domain that is presented by the user and believes in an authentication assertion that provides the user with a single single-sign-on experience instead of prompting the user for the user's certificate as part of an interactive session with the user. Or enterprise.

Union Architecture - Legacy  Federation front-end to the system

2B is a block diagram illustrating the integration of an existing system with a portion of the federated architecture component of the present invention in accordance with an embodiment of the present invention in a given domain. The federated environment includes federated entities that provide various services for users. User 212 interacts with client device 214, which may support browser application 216 and various other client applications 218. User 212 is different from client device 214, browser 216, or any other software that acts as an interface between the user and other devices and services. In any case, the following description may distinguish between a user who explicitly acts in the client application and a client application that acts on behalf of the user. In general, requestors are intermediaries that can act on behalf of users such as client-based applications, browsers, SOAP clients, and so on.

Browser application 216 may be a general browser, including one on a mobile device that includes many modules, such as HTTP communication component 220 and markup language (ML) interpreter 222. The browser application 216 may also support plug-ins such as downloadable applets and / or web service clients 224 that may or may not require a virtual machine runtime environment. The web service client 224 can use the Simple Object Access Protocol (SOAP), a lightweight protocol that defines the exchange of structured and classified information in a distributed, distributed environment. SOAP is an XML-based protocol that contains three parts, an envelope that defines a framework that describes how to process and what is in the message, a set of encoding rules that represent instances of application-defined data types, and Contains conventions representing remote procedure calls and responses. The user 212 can access the web based service using the browser application 216, but the user 212 can also access the web service through another web service client on the client device 214. Some of the examples of the invention shown in the following figures employ HTTP redirection through a user browser to exchange information between entities in the federated environment. However, the present invention may be carried out through various communication protocols and is not limited to HTTP-based communication. For example, entities in a federated environment can communicate directly if needed, and the message is not required to be resent via the user's browser.

The invention can be implemented in such a way that components required for a federated environment can be integrated with existing systems. 2B shows an example of implementing these components as a front-end to an existing system. Existing components in the federated domain may be considered as a back-end processing component 230 or legacy application that includes an authentication service runtime (ASR) server 232 in a manner similar to that shown in FIG. 2C. The ASR server 232 is responsible for authenticating the user when the domain controls access to the application server 234, which may be considered to create, retrieve, support, or process the protected resource 235. The domain continues to register the user for access to the application server 234 using the legacy user registration application 236. Information necessary to authenticate a registered user is stored in the legacy user registry 238.

After joining the federated environment, the domain can continue to operate without the intervention of federated components. In other words, a domain is configured so that users can continue to access a particular application server or other protected resource directly without going through a contact server or other component that implements another touch server function, in which way users who access the system are typically authenticated. You will experience flow and general access. However, this does not allow a user who directly accesses a legacy system to establish a federated session known as a point of contact server in the domain.

The legacy functionality of the domain is, with the federated user lifecycle management server / service 246, a trust proxy server 244 (or, briefly, a trust) that interacts with the contact server 242 and the Security Token Service (STS) 245. It may be integrated into a federated environment via federated shear processing 240, including proxy 244 or trust service 244, all of which are described in detail later with respect to FIG. 2C. The federation configuration application 247 allows the administrative user to configure federated front end components so that federated front end components interact with legacy back end components via the federated interface 248.

A given enterprise's legacy or existing authentication service may use various known authentication methods or tokens, such as username / password or smart card token based information. However, in a preferred embodiment, the functionality of the legacy authentication service can be used in a federated environment through the use of contact servers. Even if a user who accesses the system in this manner experiences a general authentication flow or general access, the user can directly access the legacy authentication server without going through the point-of-contact server, and the user who directly accesses the legacy authentication system is in a preferred embodiment. Therefore, federated authentication assertions cannot be generated as evidence of identity. One of the roles of the federation front end is to convert the federation authentication token received at the point of contact server into a format understood by the legacy authentication service. Therefore, a user who accesses the federated environment through the contact server does not necessarily need to reauthenticate to the legacy authentication service. Preferably, the user may be authenticated to the legacy authentication service by a combination of contact server or trust proxy so that the user appears to be involved in the authentication dialog.

Union Architecture -Contact servers, trust proxies, and trust brokers

Referring now to FIG. 2C, FIG. 2C is a block diagram illustrating a federated architecture in accordance with an implementation of the present invention. The federated environment includes federated companies or similar entities that provide various services for users. A user through an application on the client may attempt to access resources from various entities, such as enterprise 250. The point of contact server at each federated enterprise, such as point-of-contact server 252 at enterprise 250, is the user entry point to the federated environment. Because the contact server handles many of the federation requirements, the contact server minimizes conflicts with existing non-federated architectures, such as existing components in legacy systems. The contact server provides session management and protocol conversion and initiates authentication and / or attribute assertion conversion if possible. For example, the point-of-contact server may convert an HTTP or HTTPS message to SOAP or vice versa. As described in more detail below, the point-of-contact server can also be used to invoke a trust proxy to convert an assertion received from an issuing party, eg, a SAML token, into a Kerberos token that can be understood by the receiving party.

A trust proxy (such as a trust proxy server or trust service), such as trust proxy (TP) 254 of enterprise 250, establishes and maintains a trust relationship between two entities in the federation. Trust proxies generally have the ability to process an authentication token format that has been converted from a format used by the issuing party (via a security token service, which will be described in detail below) to a format understood by the receiving party.

The use of a point-of-contact server and trust proxy minimizes the conflict in implementing a federated architecture on a set of existing non-federated systems. Therefore, the federated architecture of the preferred embodiment requires the implementation of one or more contact servers and one or more trust proxies per federated entity, whether the entity is an enterprise, domain or other logical or physical entity. The federated architecture of the preferred embodiment does not necessarily require a change of objection to an existing set of non-federated systems. Preferably, there is a single trust proxy for a given federated entity, even if there are multiple trust proxies available or there are multiple trust proxies for the various smaller entities within the federated entity, eg, individual additions within the enterprise. As a single trust proxy manages trust relationships within multiple federations, a given entity may belong to more than one federation, although this scenario does not necessarily require multiple trust proxies.

One of the roles of the trust proxy is to determine the token type required by the other domain and / or the trust proxy within that domain. The trust proxy is responsible for the ability and responsibility to handle the conversion of the authentication token format from the format used by the issuing party to a format that can be understood by the receiving party. Trust proxy 254 is also responsible for attribute conversions or any user identity conversions that have occurred for enterprise 250. In addition, trust proxies may support the implementation of aliases as representatives of user identities that uniquely identify the user without providing any additional information about the user's real world identity. In addition, the trust proxy may issue the authorization and / or session certificate used by the contact server. However, the trust proxy can invoke a trust broker for assistance as described below. Identity transitions may be required to map user identities and attributes known to the issuing party to something meaningful to the receiving party. This switch can be invoked by a trust proxy in the receiving domain or a trust proxy in the issuing domain or both.

Trust proxy 254 includes (or interacts with an internalized component) shown as a security token service (STS) component 255, which provides a token conversion and authentication service. Invoke runtime (ASR) 256 to validate and generate the token. The security token service provides the token issuance and validity services required by the trust proxy, which may include identity transitions. Thus, the security token service includes an interface to an existing authentication service runtime or merges the authentication service runtime into the service itself. Rather than being internalized in the trust proxy, the security token service component may also be implemented as a standalone component to be invoked by the trust proxy, for example, or internalized in a transaction server, for example as part of an application server.

For example, the STS component may receive a request to issue a Cerberus token. As part of the authentication information of the user for whom the token is generated, the request may include a binary token that includes the username and password. The STS component, for example, validates the username and password against the LDAP runtime (general authentication) and invokes the Kerberos Key Distribution Center (KDC) to generate Kerberos tickets for the user. This token is returned to the trust proxy used within the enterprise, but this use may include externalization of the token for delivery to another domain in the federation.

In a manner similar to that described with reference to FIG. 1D, a user may want to access resources from multiple companies within a federated environment, such as enterprise 250 and enterprise 260. In a manner similar to that described above for enterprise 250, enterprise 260 includes contact server 262, trust proxy 264, security token service 265, and authentication service runtime 266. Although a user may initiate a separate transaction with each enterprise directly, the user may initiate a transaction with a corporation 250 that has cascaded connections through the federated environment. Even if the user is not aware of this need when the user initiates a transaction, the enterprise 250 may require cooperation with a number of other companies in a federated environment, such as the enterprise 260, to complete a particular transaction. Enterprise 260 is included as a downstream domain, and the present invention allows enterprise 250 to grant federated assertions to enterprise 260 as needed for a user's transaction, according to a preferred embodiment.

It may be the case that the trust proxy does not know how to interpret the authentication token received by the associated contact server and / or how to switch the given user identity and attributes. In this case, the trust proxy may choose to invoke functionality in a trust broker component such as trust broker 268. Trust brokers maintain relationships with individual trust proxies to provide transitive trust between trust proxies. Using a trust broker allows each entity in a federated environment, such as enterprise 250 and 260, to establish a trust relationship with the trust broker, rather than establishing multiple individual trust relationships with each domain in the federated environment. For example, if enterprise 260 is included as a downstream domain for a transaction initiated by a user of enterprise 250, trust proxy 254 of enterprise 250 may, if necessary, trust proxy of enterprise 260 ( It can be assured that 264 can understand the assertion from trust proxy 254 by invoking the assistance at trust broker 260. Although FIG. 2C illustrates a federated environment with a single trust broker, the federated environment may include multiple trust brokers.

2C shows the contact server 252, trust proxy 254, security token service component 255, and authentication service runtime 256 as separate entities, these components need not necessarily be implemented on separate devices. For example, the functionality of these individual components can be combined into a single application or implemented as an application on a single physical device. In addition, although FIG. 2C shows a single point of contact server, a single trust proxy and a single security token server for an enterprise, other configurations may include multiple point of contact servers, multiple trust proxies, and multiple security token servers for each enterprise. Point-of-contact servers, trust proxies, security token services, and other federated entities may be implemented in various forms, such as software applications, objects, modules, software libraries, and the like.

The trust proxy / STS can accept and validate a federated authentication token format that includes many different certificates and authentication tokens generated by third parties, including traditional credentials such as username password combinations and Kerberos tickets. The trust proxy / STS may allow acceptance of an authentication token as proof of authentication. The authentication token is generated by the issuing party and used to indicate that the user has already been authenticated to that issuing party. The issuing party generates an authentication token as a means of asserting the user's authenticated identity. The trust proxy / STS may also process attribute tokens or tokens used to secure communication sessions or conversations, such as tokens used to manage session information in a manner similar to SSL session identifiers.

The security token service invokes the authentication service runtime as needed. The authentication service runtime supports an authentication service that can authenticate a user. The authentication service serves as a certification authority that provides an indication of successful or failed authentication attempts through an authentication response. Trust Proxy / STS can internalize the scenario that there is a new Web service that does not need to interact with authentication services, such as an existing legacy infrastructure. Otherwise, the STS component will invoke an external authentication service for validating the authentication token. For example, an STS component can "unpack" a binary token containing a username / password and use an LDAP service to access the user registry to validate the certificate granted.

패스티켓으로 전환할 수 있다. When used by other components, such as an application server, the STS component can be used to generate the tokens required for single-sign-on to the legacy authentication system. Therefore, the STS component can be used for internal purposes, i.e. for internal and external purposes, i.e. for the conversion of tokens between companies in the federation. As an example for internal purposes, the web application server can interface to the mainframe through the IBM Customer Information Control System (CICS) transaction gateway, which provides access and enterprise-level online transactions for mission-critical applications. A family of application servers and connectors that provide management. The web application server invokes the STS component to issue a Kerberos ticket (used internally by the web application server) to the IBM RACF requested by the CICS transaction gateway.

You can convert to a pass ticket.

The entity shown in FIG. 2C may be described using the terms introduced above, eg, "Issuing Party", "Depending Party" or "Identity Provider" and "Service Provider". As part of establishing and managing a trust relationship, an identity provider's trust proxy can determine what token types are required and accepted by the service provider's trust proxy. Therefore, the trust proxy uses this information when invoking the token service from the security token service. If an identity provider's trust proxy is required to generate an authentication assertion for the service provider, the trust proxy determines the required token type and requests the appropriate token from the security token service.

When a service proxy's trust proxy receives an authentication assertion from an identity provider, the trust proxy knows the type of assertion that needs to be used internally within the service provider and the type of expected assertion. Therefore, the service proxy's trust proxy requires the security token service to generate the required internal use token based on the token in the received authentication assertion.

The trust proxy and trust broker have the ability to convert assertions received from the identity provider into a format that can be understood by the service provider. The trust broker has the ability to interpret the assertion format (or format) for each of the trust proxies that have a direct trust relationship, allowing the trust broker to provide assertion transitions between the identity provider and the service provider. This switch can be requested by either party through its local trust proxy. Therefore, the identity proxy's trust proxy may require the conversion of the assertion before being sent to the service provider. Similarly, the trust proxy of the service provider may require the switching of assertions received from the identity provider.

Assertion transitions include user identity transitions, authentication assertion transitions, attribute assertion transitions, or other types of assertion transitions. Repeating this point, assertion switching is handled by trust components in the federation, namely, trust proxies and trust brokers. The trust proxy may perform a local switch at the identity provider or service provider or the trust proxy may invoke the assistance from the trust broker.

Assuming that the identity provider and service provider already have a separate trust relationship with the trust broker, the trust broker dynamically creates, i.e., brokers, a new trust relationship between the issuing party and the dependent party as needed. After the initial trust relationship mediation operation provided by the trust broker, the identity provider and service provider may manage the relationship directly so that the trust broker does not need to be invoked for future switch requests. The conversion of the authentication token can occur at three possible places: the trust proxy of the identity provider, the trust proxy of the service provider, and the trust broker. Preferably, the trust proxy of the identity provider generates an authentication assertion that can be understood by the trust broker and sends it to the service provider. The service provider requires converting this token from the trust broker into a format that can be recognized by the service provider. Token conversion can occur before, after or before or after the transmission of the authentication assertion.

Union Architecture  Trust relationships within

Within the federated environment implemented in accordance with the preferred embodiment of the present invention, there are two types of "trust domains" that should be managed, namely corporate trust domains and federated trust domains. The difference between these two types of trust domains is based, in part, on the technology used to establish trusts and business agreements that govern trust relationships with the trust domains. An enterprise trust domain contains components managed by an enterprise, and all components in the trust domain trust each other. In general, no business agreement is required to establish trust within the enterprise. The reason for this is that deployed technologies are unique within an enterprise, for example, by requiring mutually authenticated SSL sessions between components, or by placing components within a single data center tightly controlled so that physical control and proximity represent unconditional trust. This is because it creates a trust. Referring to FIG. 2B, the legacy application and backend processing system may represent an enterprise trust domain, within which components may communicate on a secure internal network.

A federated trust domain is one that traverses corporate boundaries from one perspective, and a federated trust domain can represent a trust relationship between different corporate trust domains. Federated trust domains are established through trust proxies that cross enterprise boundaries between federated partners. Trust relationships include any kind of bootstrap process for which an initial trust has been established between trust proxies. Part of the bootstrap process may include establishing a shared secret key and rules that define expectations and / or allowable token types and identifier transitions. In general, this bootstrap process can be implemented out-of-band, which also includes the establishment of a business agreement that governs the involvement of companies in the federation and the responsibilities associated with it. do.

There are a number of possible mechanisms for establishing trust in a federated business model. In the federation model, the basic concept of trust between federated participants is required for business reasons to provide a level of assurance that the assertions (including token and attribute information) passed between participants are valid. If there is no trust relationship, the service provider cannot trust the assertion received from the identity provider and the assertion cannot be used by the service provider to determine how to interpret any information received from the identity provider.

For example, a large company may want to link thousands of global customers and that company can use conventional solutions. As a first example, the company may require customers from around the world to establish mutual trust using digital attestations from commercial attestation authorities. Commercial attestation authorities can ensure that the company's servers trust the trust servers located in each of its global customers. As a second example, the company may implement a third trust using Cerberus, and the company and world customers may implement a trusted third Cerberus domain service that implements a shared secret based trust. As a third example, the company may establish a personal scheme with a personal secure message token that is mutually trusted by servers of global customers.

If the company wants to manage trust relationships with a small number of global customers, any one of these approaches may be acceptable, but there are hundreds or thousands of potential federated partners, which cannot be managed. For example, if the company forces a smaller partner to implement a personal scheme, the company will not be able to add more requirements to the larger partner.

In a preferred embodiment, the enterprise will employ a trust relationship that is established and managed through a trust proxy and possibly a trust broker. The advantage of the federated architecture of the preferred embodiment is that it does not add additional requirements beyond the enterprise's current infrastructure and its potential federated partners.

However, the preferred embodiment does not relieve the enterprise and its potential federated partners from the preparatory work required to establish the business and accountability agreements necessary for participation in the federation. In addition, the participant cannot ignore the technical bootstrap of the trust relationship. The preferred embodiment allows for bootstrap flexibility, for example, where the first federated partner may issue a Kerberos ticket with certain information, while the second federated partner may issue a SAML authentication assertion with the predetermined information. Can be.

In a preferred embodiment, the trust relationship may include a trust proxy service (or interact with the security token service) that validates and converts tokens received from the identity provider based on a pre-established relationship between the two trust proxies. Managed by In a situation where the federation cannot establish a trust relationship (and token conversion) with another federation, the trust broker is invoked, but the federation needs to establish a relationship with the trust broker.

Referring now to FIG. 2D, FIG. 2D is a block diagram illustrating an exemplary set of trust relationships between a federated domain using a trust proxy and a trust broker in a preferred embodiment of the present invention. Although a trust broker is introduced in FIG. 2C, FIG. 2D illustrates the importance of a transition trust relationship within the federation architecture of the preferred embodiment.

Federated domains 271-273 each include trust proxies 274-276. Trust proxy 274 has a direct trust relationship 277 with trust proxy 275. The trust broker 280 has a direct trust relationship 278 with the trust proxy 275, and the trust broker 280 has a direct trust relationship 279 with the trust proxy 276. The trust broker 280 is used to establish a trust relationship based on the fulfilling trust with other federation partners on behalf of the federation participants. The principle of a transition trust allows trust proxy 275 and trust proxy 276 to have a trust relationship 281 brokered through trust broker 280. The trust proxy 275 or 276 does not need to know how to switch or validate the assertion of the other, and the trust broker can be invoked to turn the assertion into something that is valid, reliable, and understood by the other trust proxy.

Business agreements that specify contractual obligations and responsibilities for trust relationships between federated companies can be expressed in XML through the use of the Electronic Business Using XML (ebXML) standard. For example, a direct trust relationship can be represented as an ebXML document and each federated domain that shares a direct trust relationship can have a copy of the contract represented as an ebXML document. The operational characteristics of the various entities in the federation can be specified in the ebXML organization and published in the ebXML registry, for example, any enterprise that wishes to participate in a particular federation to operate a trust proxy or trust broker is required for all trust proxies or trusts in the federation. You must follow the published requirements specified by the specific federation for the broker. The security token service can parse ebXML for details on how tokens from other domains are converted. Other standards and mechanisms may be employed by the present invention that specify details about how trust relationships within the federation are implemented.

Union Architecture  undergarment Assertion  Processing

As noted above, the user's experience in the federation is managed in part by the user or the assertion for the user passed through the domain. The assertion provides information about the user's authentication status, attribute information, and other information. Using an authentication assertion can eliminate the need for the user to reauthenticate at all sites visited by the user. Within the federated environment, there are two models for getting assertions from the issuing domain to the dependent domain: the push model and the pull model. In the push model, the user's assertion goes to the user's request for the dependent domain. In the pull model, the user's request is received in the dependent domain without any required information and the dependent domain requires associated or requested assertions from the issuing domain.

In the model of using an assertion in a federated environment, the description of the present invention refers to a series of figures describing, in a preferred embodiment, a series of processes for creating and using an assertion in the federated environment of the preferred embodiment. FIG. 3A illustrates a generalized process at an issuing domain or issuing party to create an assertion in a federated environment, and FIG. 3B illustrates a generalized process at a relying domain or dependency party that "breaks" an assertion. 3C and 3D illustrate the generalized process shown in FIG. 3A in more detail by representing two variants of the push model in which an assertion is issued in the issuing domain and sent to the dependent domain at the user's request. FIG. 3E is a flow diagram illustrating a pull model in which the dependent domain requires any requested assertion for the user from the issuing domain while attempting to satisfy a resource request received by the dependent domain from the requesting user.

Referring now to FIG. 3A, this flow diagram illustrates a generalized process in the issuing domain for creating assertions in a federated environment. The process begins when the point of contact server in the issuing domain is triggered for the assertion (step 302). The point-of-contact server receives a request for a particular assertion for a given user from the relying domain or interferes with the output request for a known relying domain requesting an assertion, this scenario will be described in detail later with reference to FIGS. 3C and 3D. . In response to the trigger for the assertion, the point-of-contact server in the issuing domain requests an assertion from the issuing domain's trust proxy (step 304), generating the assertion with the addition of trust information such as encryption / signing of the assertion / token (step 306). The trust proxy of the issuing domain can then request assistance from the trust broker to generate the requested assertion if necessary. After the assertion occurs, the trust proxy in the issuing domain returns the assertion to the point-of-contact server in the issuing domain (step 308) and introduces the assertion in the output downstream in an appropriate manner, for example, by inserting the assertion into the output HTTP or SOAP message. (Step 310), the process is completed.

3A illustrates the process of creating an assertion in the issuing domain without the use of a "local wallet." However, the present invention preferably allows for the inclusion of local wallet functionality. In general, local wallets are client-side code that can act as user attribute information or other information-safe datastores for utilizing transactions, and the client-side code can participate in push and / or pull models of assertion delivery. When the local wallet actively participates in the protocol, it implements a subset of the contact server functionality in terms of generating assertions and inserting them into the protocol flow. Using a local wallet does not allow the local wallet to implement trust-based interactions that occur between the contact server and the trust proxy. If additional trust relationships are required, the contact server must be invoked.

Referring now to FIG. 3B, this flow diagram illustrates a generalized process in a dependency domain that tears down an assertion. When the contact server of the dependent domain receives a message with an associated assertion (step 322), the process then begins to extract the assertion and sends the assertion to the trust proxy of the dependent domain (step 324). The trust proxy in the dependent domain extracts information from the assertion, including the token received from the issuing domain (step 326), and the trust proxy in the dependent domain invokes the security token service to trust information about the token, such as encryption and signatures, and After validating the token containing the information in the token, if appropriate, a local valid token is returned for the user (step 328).

As part of step 326, the trust proxy will determine the source of the assertion, that is, the issuing party. If the trust proxy can understand the trust assertion received from the issuing domain, the trust proxy will perform step 328 internally. If the trust proxy cannot understand / trust the assertion received from the issuing domain, the trust proxy can invoke the assistance from the trust broker. If the assertion cannot be validated, an appropriate error response can be generated.

Assuming the assertion is validated, the trust proxy of the dependent domain forms the required local information for the user (step 330). For example, the local information may include a certificate requested by a later legacy application. The trust proxy in the dependent domain returns the requested information to the contact server in the dependent domain and establishes a local session for the user (step 332).

After the contact server establishes a session for the user, the user appears as an authenticated user. The contact server uses this session information to manage any transaction between the user and the domain until a logout or timeout event is initiated. If the point-of-contact server has an authentication identity for the user, then the point-of-contact server can, if necessary, obtain authorization for the request based on the identity of this particular user and any authorization policy associated with that particular user. The point of contact server then sends a request of the user with any relevant information to the requested backend application or service (step 334) and terminates the process.

The data items passed between the point of contact server and the trust proxy and the format of these data items may vary. Rather than extract an assertion from a message and pass only the assertion to the trust proxy, the point-of-contact server can forward all messages to the trust proxy. For example, processing at the trust proxy may include steps such as validating a signature on a SOAP message that requires the entire SOAP envelope.

Referring now to FIG. 3C, this flow diagram illustrates a specific process for pushing an assertion from an issuing domain to a dependent domain in response to a user action in the issuing domain. When a user accesses a link from a web page or similar resource in the publishing domain to a dependent domain (step 342), the process is invoked to invoke any form of Common Gateway Interface (CGI) type process to form a specific assertion. . The ability of the issuing domain to recognize the need for assertion by the dependent domain means tight integration with existing legacy systems in which the federated infrastructure of the present invention is preferably implemented. It also includes a tight coupling between the issuing party and the relying party so that the issuing party does not need to invoke a trust proxy to form the required assertion, and this tight coupling is between any type of federated entities with a well established trust relationship. May be suitable in

Post-processing in the issuing domain may be invoked to form the required assertion (step 344) and may include invoking functionality at the local trust proxy. The user's request for the dependent domain, including the requested assertion, is formed (step 346), and the issuing domain forwards the assertion with the user's request for the dependent domain (step 348) and terminates the process. Once the dependency domain receives the request and its associated assertion, the dependency domain can validate the assertion in the manner shown in FIG. 3B.

Referring now to FIG. 3D, this flow diagram illustrates a particular process for pushing an assertion from an issuing domain to a dependent domain in response to an issuing domain that actively interferes with an output request for the dependent domain. The process begins when a user requests a protected resource in the dependent domain (step 352). The point-of-contact server, for example, filters the output messages for certain Uniform Resource Identifiers (URIs), certain types of messages, certain types of message content, or interferes with the output request in any other way (step 354). The point of contact server of the issuing domain requests issuance of the appropriate assertion from the trust proxy of the issuing domain (step 356), and the trust proxy of the issuing domain generates an assertion with an assistance from the trust broker if necessary (step 358). The issuing domain then forwards the user's request with the generated assertion to the dependent party (step 360) and terminates the process. Once the dependency domain receives the request and its associated assertion, the dependency domain can validate the assertion in the manner shown in FIG. 3B.

Referring now to FIG. 3E, this flow diagram illustrates a pull model in which the dependent domain requires any requested assertion for the user from the issuing domain while attempting to satisfy the resource request received by the dependent domain from the requesting user. The process begins when the dependent domain receives a user request for a protected resource (step 372). In contrast to the example shown in FIG. 3C or FIG. 3D, the example shown in FIG. 3E describes the process associated with the user's request received in the dependent domain in the absence of any requested assertion for the user. In this case, the issuing domain does not have the ability to intercept or process the user's request to insert the required assertion in the user's request. For example, a user can enter a URL and use bookmark criteria for the resource to ensure that output requests are not blocked by the point-of-contact server in the issuing domain. Therefore, the dependent domain requires an assertion from the issuing domain.

The dependent domain determines the user home domain, that is, the relevant publishing domain (step 374). In an HTTP-based implementation, a user may pre-establish a relationship with a dependent domain that generates a persistent cookie set by the dependent domain at the user's client device. The persistent cookie contains the identity of the user's home domain or identity provider, i.e., the associated publishing domain. In a SOAP-based implementation in which a user operates a web service client in any way, a web service in a dependent domain can advertise service requirements through a Web services Description Language (WSDL) that includes token requirements. This requires the user web service client / SOAP implementation to provide the required token type. If this requirement is not fulfilled, the web service technically returns an error. In any case, it can return an error code that causes the user's web service client to prompt for authentication information so that the request can be repeated with the appropriate token.

The point-of-contact server in the relying domain initiates an assertion request with the relying domain trust proxy (step 376) and requests an assertion for the user from the issuing domain trust proxy (step 378). If an embodiment employs HTTP-based communication, an assertion request from the dependent domain trust proxy to the issuing domain trust proxy can be sent by the dependent domain contact server to the point of contact server of the issuing domain via retransmission through the user browser application, and the assertion request Is passed to the issuing domain trust proxy.

If the embodiment employs a SOAP-based implementation, the dependency party can return an error code to the user web service client. This error code causes the user to be prompted for authentication information by the web service client. The web service client then generates the requested token. The user web service client can invoke the trust proxy directly when the dependent domain trust proxy is known to the Universal Description, Discovery, and Integration (UDDI) registry, and let the user web service client find the trust proxy. In general, this scenario is valid only for internal users, and trust proxies are known to private UDDI in the enterprise. The reason is that trust proxies are unknown to public UDDI on the federated accessible outside or on the Internet.

The issuing domain trust proxy issues the requested assertion (step 380) and returns in a manner similar to the manner in which the assertion request was received (step 382). After the dependent domain trust proxy receives the requested assertion (step 384), the dependent domain trust proxy extracts information from the assertion (step 386) and attempts to interpret and / or validate the assertion (step 388). If you need to switch assertions, you can invoke the assistance from the trust broker. If the assertion cannot be validated, an appropriate error response may occur. Assuming the assertion is validated, the dependent domain trust proxy forms local information in the appropriate format for use by the latter service that will attempt to understand the user's need for protected resources (step 390). For example, the local information may include a certificate requested by a later legacy application. The trust proxy of the dependent domain returns the requested information to the dependent domain contact server (step 392), and the dependent domain contact server establishes a local session for the user and, together with any relevant information, requests the requested backend application or Deliver to service (step 394) and terminate the process.

Union Architecture  Single-sign-on

Although the description of FIGS. 2A-2D focuses on the operational characteristics of an entity in a federated data processing environment in accordance with a preferred embodiment of the present invention, FIGS. 3A-3E focus on some of the processes that occur between the entities. . In contrast to these descriptions, FIG. 4 focuses on the goal of completing a transaction for a user while providing a single-sign-on experience for the user.

In other words, the following description focuses on the schematic aspects of the preferred embodiment of the present invention with respect to the manner in which a user can experience a single-sign-on experience within a user session, although the entities and processes described above have already been described. Discussed below. A session can be defined as a series of transactions from initial user authentication, i.e. from logon to logout. Within a session, user actions are managed in part by the privileges granted to the user during the session. Within a federation, the user expects a single-sign-on experience in which the user completes a single authentication operation, which is sufficient during the session regardless of the federation partner visited during that session.

During a user session, a user can visit many federated domains and use the web services provided by the domain. Domains can publish descriptions of services that can be provided using standard specifications such as UDDI and WSDL, and UDDI and WSDL use XML as a common data format. The user finds the services and service providers available through the application attached to the standard specification. SOAP provides a paradigm for communication requests and responses expressed in XML. Entities in a federated environment may employ these standards among others.

To facilitate the single-sign-on experience, web services supporting federated environments will also support the use of security tokens or authentication assertions generated by third parties to provide proof of user's authentication. This assertion will contain any kind of evidence of the user's successful authentication to the issuing party, along with an identifier for the user. Thus, a user can present a traditional certificate for one federated partner, eg, a username and password, and provide a SAML authentication assertion generated by an authentication / issue party for another federated partner.

Authentication in a web services environment is the act of verifying the required identity of a web services request so that an enterprise can restrict access to authenticated clients. Most users who request or invoke a web service are authenticated so that the need for authentication in the federated environment of the preferred embodiment is not different from the current requirements of the web service for user authentication. The federated environment also allows web services or other applications to request web services, which are also authenticated.

Authentication of a user who does not participate in a federation session is not conflicted by the federation architecture of the preferred embodiment. For example, existing users who authenticate with forms-based authentication mechanisms via HTTP / S to access non-federated resources in a particular domain are not affected by the introduction of support in the domain for federated environments. Authentication is partly handled by the point of contact server, which can invoke a separate trust proxy component. The use of a contact server minimizes conflicts on the infrastructure of existing domains. For example, the point-of-contact server may be configured to pass all non-federated requests to be handled by backend or legacy applications and systems in the domain.

The point-of-contact server can choose to invoke HTTP-based authentication methods such as basic authentication, forms-based authentication, or any other authentication method. The point-of-contact server also supports federated trust domains by recognizing assertions presented by the user as proof of authentication, such as SAML authentication assertions, and the assertions traverse between enterprise trust domains. The point-of-contact server may invoke a trust proxy that can invoke a security token service for validating a certificate / security token.

Authentication of a web service or other application involves the same process as authentication of a user. The request from the web service carries a security token containing an authentication assertion, which is validated by the trust proxy / security token service in the same way as the token presented by the user. Since the web service has discovered which authentication assertion / security token was required by the requested service as known to UDI, the request from the web service always carries this token.

Referring now to FIG. 4, FIG. 4 is a block diagram illustrating a federated environment that supports federated single-sign-on operation. User 400 wants to access a web service provided by an enterprise / domain 410 supporting a data processing system operating as a federated domain in a federated environment through a client device such as a browser and an appropriate client application. Domain 410 supports contact server 412 and trust proxy 414, likewise, domain 420 supports contact server 422 and trust proxy 424, and domain 430 supports contact server ( 432 and trust proxy 434. The trust proxy relies on the trust broker 450 for assistance as described above. Additional domains and trust proxies may participate in the federated environment. 4 illustrates a federated single-sign-on operation between domain 410 and domain 420, where a similar operation may occur between domain 410 and domain 430.

The user completes an authentication operation with respect to the domain 410, and this authentication operation is processed by the contact server 412. The authentication operation is triggered when the user requests access to any resource that requires an authentication identity, for example for personalization or access control purposes. The point-of-contact server 412 may validate the user presented certificate by invoking the legacy authentication service or by invoking the trust proxy 414. Domain 410 becomes the user identity provider or home domain for the duration of the user federation session.

After a certain time, the user initiates a transaction at a federated partner, such as enterprise 420, which supports the federated domain, to trigger a federated single-sign-on operation. For example, a user may initiate a working-copy transaction in domain 420 or cascade the user's original transaction into one or more additional transactions in another domain. As another example, a user may access a resource in domain 420 through contact server 412 by selecting a special link on a web page hosted within domain 410 or by requesting a portal page hosted within domain 410. It can invoke federated single-sign-on operation, but displays resources hosted in domain 420. The point of contact server 412 sends a request to the trust proxy 414 to generate a federated single-sign-on token for the user that is formatted to be understood and trusted by the domain 420. The trust proxy 414 returns this token to the contact server 412, which sends it to the contact server 422 in the domain. Domain 410 acts as a publishing party for the user in domain 420 which acts as a dependent party. The user's token is sent to the user request for domain 420, which token is transmitted using an HTTP retransmission through the user's browser or on behalf of the user identified in the token supplied by the trust proxy 414 (HTTP or Can be sent by invoking the request of the contact server 422).

The contact server 422 receives the request with the federated single-sign-on token and invokes the trust proxy 424. The trust proxy 424 receives the federated single-sign-on token, validates the token, and generates a locally valid token for the user, assuming that the token is valid and reliable. The trust proxy 424 returns the local valid token to the point of contact server 422, which establishes a session for the user in the domain 420. If necessary, the contact server 422 can initiate federated single-sign-on at another federated partner.

Validation of the token in domain 420 is handled by trust proxy 424 with assistance from the security token service if possible. Depending on the type of token presented by domain 410, the security token service may need to access a user registry in domain 420. For example, domain 420 may provide a binary security token that includes a username and password to be validated against a user registry in domain 420. Therefore, in this embodiment, the enterprise simply validates the security token from the federation partner. The trust relationship between domains 410 and 420 can understand and trust the security token presented by domain 410 on behalf of the user.

The federated single-sign-on requires determination of a local effective user identifier in the dependent domain based on the information contained in the security token as well as the validation of the security token presented in the dependent domain on behalf of the user. The result of one of the business agreements and direct trust relationships required to establish this relationship is that one or more parties, the issuing domain or the dependent domain, or both, know how to convert the information provided by the issuing domain from the dependent domain to a valid identifier. It is required to establish a relationship. In the brief example described above, the issuing domain, ie, domain 410, provides the dependent domain, ie, domain 420, with a user identifier valid in domain 420. In this scenario, the dependent domain does not need to invoke any identity mapping functionality. Trust proxy 424 in domain 420 will generate a security token for the user who will endorse this user. The types of tokens accepted, signatures required for tokens, and other requirements are all established in advance as part of a federated business agreement. Rules and algorithms governing identifier conversion are also established in advance as part of the federated business agreement. In the case of a direct trust relationship between two participants, an identifier switching algorithm may be established for two parties and not associated with any other party in the association.

However, the issuing domain does not always know how to map a user from a local identifier for domain 410 to a local identifier for domain 420. In any case, the dependent domain may know this mapping method, and in other cases, no party may know this transition method, in which case a third party trust broker needs to be invoked. In other words, in the case of a mediated trust relationship, the issuing and dependent domains do not have a direct trust relationship with each other. However, they will have a direct trust relationship with a trust broker such as trust broker 450. Identifier mapping rules and algorithms will be established as part of this relationship, and the trust broker uses this information to help convert the identifiers required for the brokered trust relationship.

The domain 420 receives the token issued by the domain 410 at the contact server 422, and the contact server 422 invokes the trust proxy 424 to validate the token and perform identity mapping. In this case, trust proxy 424 cannot map a user from a local identifier for domain 410 to a local identifier for domain 420, and trust proxy 424 invokes trust broker 450 to tokenize. Validate and perform identifier mapping. After obtaining a local identifier for the user, the trust proxy 424 may generate any local tokens required by the backend application in the domain 420, possibly via its security token service, for example, a Kerberos token It may be required to perform single-sign-on from this contact server to the application server. After obtaining the local valid token, the contact server may establish a local session for the user, if necessary. The contact server also handles rough authentication of the user request and sends the authenticated request to the appropriate application server in the domain 420.

The user's session ends upon logout or sign-off. When a user logs out of a session to the home domain, the home domain informs all dependent domains, that is, the domain that issued the security token, and invokes the user logout from that domain. If any of the dependent domains acts as the issuing domain for the same user, the domain will cascade the user logout request to all dependent domains. The trust proxy in each domain is responsible for informing user dependent logout requests to all dependent domains, and the trust proxy can invoke the trust broker as part of this process.

Federated User Lifecycle Management

Some of the descriptions of FIGS. 2A-4 describe the organization of components that can be used in a federated environment and others describe the process of supporting single-sign-on operations through the federated environment. Service providers or dependent domains in a federated environment do not necessarily manage user certificates and these dependent domains may affect a single single-sign-on token provided by a user identity provider or home domain. The foregoing description of FIGS. 2A-4 does not describe the explicit process by which federated user lifecycle management can be achieved in an advantageous manner in the federated domain of a federated partner.

Federated user lifecycle management functionality / service includes the ability to support or manage federated behavior for a given user's user profile or specific user account in multiple federated domains, in which case the function or behavior is a given federation for a user It is limited to sessions. In other words, the federated user lifecycle management function refers to an operation that allows management of federated operations through multiple federated partners only during the lifecycle of a single user session within the federated computing environment, if possible.

Each federated domain manages user accounts, user profiles, and any kind of user session for functionality in each federated domain. For example, a particular federated domain does not manage local user accounts or user profiles within a particular federated domain, but a federated domain manages local user sessions for federated transactions after successful completion of single-sign-on operations in the federated domain. As part of the federated user lifecycle management functionality supported by a particular federated domain, the federated domain participates in a single-sign-off operation that allows the federated domain to terminate local user sessions after the federated transaction ends, thereby improving security and Promote efficient use of resources.

In another example of the use of federated user lifecycle management functionality, a user is involved in an online transaction that requires participation of multiple federated domains. The federated domain locally manages user profiles to tailor the user experience with respect to the federated domain during federation sessions of users including the federated domain. As part of the federated user lifecycle management functionality supported by a particular federated domain, information in the federated domain's local user profile is seamless during a given federated transaction with information from another profile in another federated domain participating in the given federated transaction. Can be used in a manner. For example, information from a user's multiple local user profiles can be combined into any type of merge operation so that the user's information is visually presented to the user within a web page in such a way that the user does not know another source or source of the user's information. To be presented.

Federated user lifecycle management functionality may also include functionality for linking / unlinking accounts. A single user identifier is provided to the user through the federated user to allow single federated retrieval and single sign-on of attributes for the user as part of the fulfillment of the request in one federated partner. In addition, the federation partner may refer to the user anonymously by requesting additional attributes from the identity provider using a common single user identifier.

After describing other example operations that can be achieved using federated user lifecycle management functionality, the remaining figures below provide and support federated user lifecycle management functionality in accordance with the preferred embodiments of the present invention and in an advantageous manner. Explain how to do it.

5 is a block diagram illustrating some of the components in a federated domain that implement federated user lifecycle management functionality in accordance with an embodiment of the present invention. FIG. 5 illustrates elements in a single federated domain, such as a federated domain operated by enterprise 250 shown in FIG. 2C. Some of the elements shown in FIG. 5 are similar to or the same as the elements described above with reference to other figures such as FIG. 2B. That is, the contact server / service 502 is equivalent to the contact server 242, the application server 504, i.e., the resource control service is equivalent to the application server 234, and the protection or control resource 506 is the protected resource. Equivalent to resource 235 and federated user lifecycle management (FULM) application 508 is equivalent to federated user lifecycle management server 246. A firewall is not shown in FIG. 2B, but a firewall is shown in FIG. 5. Firewalls 510 and 512 form an external electronic demilitarized zone (DMZ) that protects the enterprise's computing environment from computing threats outside the enterprise's domain, for example, over the Internet.

The different aspects shown in FIGS. 5 and 2B are not incompatible or incompatible. In contrast to the example shown in FIG. 5, FIG. 2B does not represent a firewall and the contact server 242 resides within the federation front end 240. In addition, federated user lifecycle management server 246 is included within federated front end 240. In FIG. 5, the contact server 502 is shown residing in a DMZ between firewalls 510 and 520 forming an electronic or physical shear in the corporate domain. In addition, federated user lifecycle management application / service 508 resides electronically behind firewall 512. Different views consider the DMZ and other components of FIG. 5 to form a physical or electronic front end and a physical or electronic back end that may include the federated component, while the combined front end 240 and the rear end 230 of FIG. Can be adjusted by considering it as an organization.

Recurring the role of a contact entity / service, the contact entity provides session management for at least user interaction with federated functionality in the enterprise computing environment, and applications within the legacy backend of the enterprise computing environment may implement their own management functionality. Can be. Assuming an enterprise implements policy functionality for a federated computing environment, the contact entity can act as a policy enhancement point for the policy decision point of another federation partner. Further, assuming that implementation of federated functionality is allowed, the contact entity is responsible for initiating a direction authentication operation for the user in a scenario in which no single-sign-on operation is employed. The contact entity may be implemented in various forms, such as a reverse proxy server, web server plug-in, or any other way. Contact functionality can also be implemented within the application server itself, in which case the federated user lifecycle management service can be located within the DMZ.

More importantly, referring back to FIG. 5, the federated user lifecycle management application 508 also includes support for interfacing, interacting, and interacting with the federated user lifecycle management plug-in 514 not shown in FIG. 2. do. In the present invention, the federated protocol runtime plug-in is preferably a WS-federated passive client, a free alliance ID-FF single-sign-on (B / A, B / P, and LECP), register name identifier, federation end notification, and single log. Provides functionality for independently published or developed federated user lifecycle management standards or profiles of various types, such as out.

In an exemplary embodiment of the invention, different federated protocol sets may be accessed at different URIs. This approach allows federated user lifecycle management applications to simultaneously support multiple standards or specifications of federated user lifecycle management within a single application, such as the WS-Federated Web Services Specification versus the Free Alliance specification, supporting different federated protocols. Minimize configuration conflicts for the entire environment.

In particular, the appropriate federated user lifecycle management functionality is invoked by the point-of-contact server by resending and / or forwarding user requests to the federated user lifecycle management application. Referring back to FIG. 5, the contact server 502 receives the user request 520 and analyzes the user request to determine the type of request received, the type of request being received being the type of the request message received or described above. As indicated, this is indicated by determining the destination URI in the request message. The request for protected resources 522 is continuously forwarded to the application server 504, and the request for federated user lifecycle management functionality 524, e.g., a request to invoke a single-sign-off operation, is received. It is delivered to a federated user lifecycle management application 508 that invokes the appropriate federated user lifecycle management plug-in needed to fulfill the specified needs. As new federation protocols or new federation functions are defined, or existing ones are modified or improved, support may be added by plugging in new support modules or improved by modifying plug-ins already installed.

The exemplary implementation of the federated user lifecycle management application of FIG. 5 supports a number of simultaneous federated user lifecycle management functions while providing a flexible pluggability for the federated user lifecycle management application to support any existing infrastructure. Indicates that new functionality is added to the federated user lifecycle management application in the form of plug-ins when it is necessary not to require changes. For example, assuming that the present invention is implemented using a Java-based federated user lifecycle management application, support for new federated protocols, such as the newly published single-sign-on protocol, may be provided by the federated user lifecycle management application. It can be added by constructing a newly developed Java ^TM class in the Java ^TN CLASSPATH, and the new class supports the new standard with the protocol interface of the present invention according to the preferred embodiment.

The present invention preferably affects existing environments in which federated user lifecycle management solutions are integrated. Federated user lifecycle management applications can be easily modified to support new protocols / standards by evolving with minimal changes to the entire infrastructure. Any changes required to support the new federated user lifecycle management functionality are mostly exclusively located within the federated user lifecycle management application and require the configuration of a federated user lifecycle management application to understand the added functionality.

There may be minimal configuration changes, for example, from the point-of-flight server to other federated components, so that all infrastructure can invoke the new federated user lifecycle management functionality while continuing to support existing federated user lifecycle management functionality. However, the federated user lifecycle management application is functionally independent of the rest of the federated component in that the federated user lifecycle management application may require only minimal interaction with other federated components of the federated environment. For example, in an exemplary embodiment, federated user lifecycle management information, such as name identifier values according to a free federation profile, is externally accessible federated user, unlike a personal internal federated user lifecycle management datastore that does not have access to an external entity. If stored in a lifecycle management datastore, federated user lifecycle management functionality can be integrated with enterprise-based datastores, such as LDAP datastores.

Therefore, when implemented in accordance with a preferred embodiment of the present invention, existing environments require minimal changes to support federated user lifecycle management functionality. In addition, changes to federated user lifecycle management functionality, including the addition of new functionality, have minimal impact on existing federated environments. Therefore, when a new single-sign-on standard is released, support for this standard is easily added.

Traditional user authentication involves the interaction between an enterprise's computing environment and the end user, and the way a company chooses to implement this authentication exchange is a company's choice that does not impact any other company. However, if federated or cross-domain single-sign-on functionality is desired to be supported, there is a requirement for enterprise partners to interact with each other. This requirement cannot be performed scalar using private protocols. Adding support for standards-based federation protocols directly to the contact entity appears to be a powerful solution, but existing entities within the enterprise computing environment, the contact entity, must be modified and changed whenever one of the public federation protocols changes.

The present invention preferably provides more modular access by moving this functionality out of the contact entity. However, the contact entity must handle frequent changes to these public protocols, and this functionality being pluggable allows to maintain migrations or updates to these protocols.

Functional support for federated user lifecycle management

Conventional standards-based single-sign-on solutions, such as the Free Federation ID-FF Profile or WS-Federation Specification, provide some model for federated user lifecycle management. These specifications are publicly available and can be implemented by independent sellers and businesses. However, this conventional specification does not address how existing environments must be modified to include the functionality defined within the specification. This prior specification suggests that changes required to the infrastructure of an existing computing environment to incorporate certain functionality prohibit the adoption of these specifications. For example, all conventional personal single-sign-on solutions work this way.

In contrast, the present invention preferably provides a method and system for incorporating functionality to implement a federated specification such that minimal changes are required to the infrastructure of an existing computing environment as described above. This goal can also be applied to the integration of functionality to support federated user lifecycle management. 2B and 5 illustrate examples of logical organization of components used to implement one embodiment of the present invention for federated use lifecycle management functionality, while FIG. 6 illustrates a federated user lifecycle in accordance with one embodiment of the present invention. Represents a process that allows for administrative functionality.

In particular, FIG. 6 illustrates a process that allows federated user lifecycle management functionality to be implemented in a manner independent of how contact functionality is implemented within the federated domain. The contact functional entity corresponds to an entity capable of performing session management for a user / client. Session management includes creating a session based on any form of information, whether a previous successful direct authentication operation, a current successful direct authentication operation, and / or a successful single-sign-on operation. Session management may also include other actions on the session that may include optional authorization decisions and may include session termination, such as session expiration, deletion, inactivity timeout, and the like. The touch point server can continue to provide support for authentication operations that can handle direct request / response interactions with the user. The contact entity also acts as a policy enforcement point to allow authentication services as part of session management.

Federated user lifecycle management functionality provides single-sign-on services (along with federated operations). This is because these operations involve interaction with third parties, such as identity providers, and not end users, and federated user lifecycle management functionality relies on contact management for session management services. The federated user lifecycle management functionality requires or relies on the trust service provided by any other component as described in detail below. Trust services are implemented to be logically separated, including logically separated components or distributed components that coexist with federated user lifecycle management components, or trust services are implemented with federated user lifecycle management as part of a single application, such as an EAR file. Can be.

Although the preceding description has described a dedicated point of contact server supported in a domain, the process described with reference to FIG. 6 does not require a dedicated point of contact server. In the embodiment of the present invention shown in FIG. 6, the contact functionality may be implemented using any application or other entity that provides contact functionality, which may be a reverse proxy server, web server, web server plug-in, servlet filter. Or any other type of server or application. Contact functionality is referred to as a contact service or contact entity to distinguish contact functionality described below with respect to the exemplary process for implementing subsequent embodiments for the contact server described above.

6 illustrates single-sign-on operation within a federated computing environment, but similar processes may be implemented for other types of federated operations, eg, single-sign-off operations, in accordance with other embodiments of the present invention. .

Referring to FIG. 6, a data flow diagram illustrates a process for performing single-sign-on using federated user lifecycle management functionality in accordance with an embodiment of the present invention. FIG. 6 shows a pseudo UML diagram of the interaction and data flow between a service provider and an identity provider supporting federated functionality in accordance with a preferred embodiment of the present invention, in particular for federated user lifecycle management functionality provided. In general, the process shown in FIG. 6 is initiated when a service provider's contact entity has received a request for a protected resource supported within the service provider's federated computing environment. Instead of invoking their authentication method, the service provider's contact entity may resend the request, send the request, or invoke the functionality to initiate a federated user lifecycle management application supported within the federated computing environment of the identity provider. Send the request. As described in detail later, the federated user lifecycle management application determines the proper way to authenticate a user and the proper way to return the information required by the contact entity to the contact entity to initiate a session for the user at the service provider and The service provider processes the remainder of the user's transaction as if he had completed the authentication operation directly with the service provider.

The process of FIG. 6 is initiated by receiving at the point of contact at the service provider an original request for a control resource from an unauthorized user (step 602). Although the received request is one of many downstream transactions that support more complex transactions, the original request can be considered as initiating a transaction for the user. In one embodiment, the service provider may determine that the original request is from an unauthorized user by detecting a request from an end user or end application that the service provider does not have a record of an ongoing session.

The contact entity issues a request to resend, send, or invoke the functionality to send the original request from the service provider to the federated user lifecycle management application (step 604). The contact entity may use any means of invoking federated user lifecycle management functionality that causes the federated user lifecycle management functionality to produce a response message that should be sent to the identity provider, in other words, the contact entity may be a complex single-sign Does not include functionality to provide / respond on messages. In the example shown in FIG. 6, the original request is redirected to the service provider's federated user lifecycle management application via the originating application, eg, a browser application being operated by the end user (step 606).

After receiving the request, the federated user lifecycle management application of the service provider determines the appropriate identity provider for the user by communicating with the end user application (step 608). This step is optional and if the identity provider is a federated partner of a service provider within a particular federated computing environment, then the service provider may already consist of information about the contact information or location of the contact entity of the identity provider, eg, a URL, Alternatively, the service provider may obtain the contact information or the location of the contact entity of the identity provider after performing a lookup operation to determine the identity of the particular identity provider used in the end user's transaction. In any case, since the service provider only knows about one identity provider, the service provider can know the identity of the identity provider used and thus does not include any choice. In other cases, the service provider may know the identity of the identity provider based on persistent information maintained at the user side, such as persistent HTTP cookies. In another case, the service provider may interact with the user at step 608 to allow the user to provide information to the service provider about the identity of the identity provider that the user wishes to employ in the current federated transaction. If the service provider has the identity provider's identity, the service provider can obtain the appropriate URI for the identity provider's single-sign-on functionality (or other federated functionality depending on the type of transaction or federation operation currently completed) from the appropriate datastore. have. The present invention is preferably compatible with other methods of performing step 608, where the free federation specification describes the interaction that a user retransmits to any other site from which cookies can be obtained (DNS cookies). Is performed in this manner because of the limitations on the operation for the user), without sending user interaction, for example, without the user providing information in an HTML form, and returned to federated user lifecycle management functionality.

The service provider's federated user lifecycle management application may request any appropriate information for successfully completing the identity provider's federated user lifecycle management function or operation (step 610), e.g., a single-sign-on operation. Generate and send a request to get. The request may be accomplished or implemented by a security token indicating that the identity provider can trust the communication from the service provider, and preferably, the trust between the service provider and the identity provider is provided by a signature and a cipher in the request message and secured. The token may be represented by a digital certificate accompanying the request. Since federated user lifecycle management operations can be performed in a variety of ways independent of the type of request provided to the service provider by the end application, the need for federated user lifecycle management operations is dependent upon the original needs from the end user application. It may be accompanied by information about.

A request for federated user lifecycle management function or operation is received and retransmitted via the end application to the identity provider of the identity provider using previously determined contact information for the identity entity of the identity provider. The present invention is preferably compatible with various methods of achieving step 612, for example, the free alliance specification allows for the type of retransmission according to the device, and the federated user lifecycle management function of the preferred embodiment of the present invention. Uses HTTP POST messages based on mobile devices to the Internet to exchange between HTTP retransmissions in response to an HTTP response with status value "302" and HTTP retransmissions in response to an HTTP response with status value "200" (OK). Can be.

After the contact entity of the identity provider receives a request for a federated user lifecycle management function or operation, the contact entity of the identity provider may perform an optional authentication operation on the end user's application or end user (step 614). If the identity provider does not have a valid session for the user, then an authentication operation is always required and without the authentication action, the identity provider cannot determine who the user is for single-sign-on purposes. Authentication may be required if there is a valid session for the user to ensure that the user is still active or to be able to prove a higher level certificate. The service provider may specify that a new authentication operation should not be performed by the identity provider to cause the single-sign-on operation to fail if there is no valid session for the user. The type of authentication operation may be performed automatically or changed to require input from a user, biometric or other type of authentication device, or other information source. For example, if a new authentication operation is required to maintain a high level of security that ensures that the end user is an authorized requestor for the identified control resource in the original request, the authentication operation may be required. In another scenario, an authentication operation may be required, but the contact entity of the identity provider accesses information indicating that the identity provider already has an active session for the end user, completing the subsequent authentication operation at step 614. Eliminate the need

The identity provider of the identity provider sends the received request for the federated user lifecycle management function or operation required by the federated user lifecycle management application of the service provider to the federated user lifecycle management application of the identity provider (step 616). After analyzing the request, the federated user lifecycle management application of the identity provider forms a response accompanied by end user specific information found by the federated user lifecycle management application of the service provider (step 618). For example, the identity provider may support a database containing confidential identity information or other attribute information for end users not stored within the federated computing environment. As noted above, since the federated user lifecycle management operation may be performed in a variety of ways independent of the type of request provided to the service provider by the end user application, the received request for the federated user lifecycle management operation may be It is accompanied by information about the original request from the application. Likewise, the response from the identity provider's federated user lifecycle management application may be tailored in any manner to the originally identified and controlled resource.

The federated user lifecycle management application of the identity provider sends a response to the end user application using, for example, an HTTP POST / Redirect message (step 620) and resends the message to the federated user lifecycle management application of the service provider (step 622). The identity provider may return a pointer or similar type of indirect reference data item indicating information expected by the service provider, in which case the service provider performs a back-channel request to the identity provider for use by the service provider. It is necessary to retrieve the information using the received pointer (known as artifact) by retrieving the user specific information.

If the received message does not contain an error code or indicates that the federated user lifecycle management application of the identity provider cannot successfully complete the requested federated user lifecycle management function or operation, the federated user lifecycle management application of the service provider Extract the requested information from the received response and form a response to the contact entity of the service provider (step 624). The federated user lifecycle management application of the service provider sends / returns the response generated for the contact entity of the service provider in any manner (step 626).

The federated user lifecycle management application can be implemented as a Java ^TM application as an EAR file installed beyond a firewall in the domain. The nature of the response returned to the contact entity may be configured as part of the installation and configuration of the federated user lifecycle management application, so the federated user lifecycle management application is not independent of the form of the contact entity. Specifically, the federated user lifecycle management application does not depend on the characteristics of the contact entity other than the identification or location information, ie how the transaction control is returned and the content of the information required when the transaction control is returned. This approach allows any federated user lifecycle management function, such as single-sign-on operation, single-sign-off operation, account link, etc., to be disassociated from the session management function provided by the contact entity. Minimize the impact on the existing infrastructure of the computing environment.

Assuming that the service provider's contact entity has received a successful response from the service provider's federated user lifecycle management application, the service provider's contact entity may handle the original request from the end user application, including the establishment of a user session. Proceed (step 628), perform a selective access or authorization control operation, send a request to access the control resource to a subsequent application server that controls or provides access to the control resource (step 630), and ends the process. .

In the summary of the example shown in FIG. 6, the end user was not authenticated to the service provider when the original request was received at the service provider's contact entity. Rather than performing the authentication operation directly under the control of the service provider, the service provider causes the identity provider to complete the federated single-sign-on operation. The contact entity of the service provider waits for an indication / message that the federated single-sign-on operation has successfully completed through the federated user lifecycle management application of the service provider and the identity provider that are partners in the federated computing environment. After the contact entity of the service provider receives an indication / message that the federated single-sign-on operation has completed successfully, the original request is further processed.

The present invention preferably affects existing environments in which federated user lifecycle management solutions are integrated. Support for federated user lifecycle management applications can be implemented as J2EE / C # applications based on existing environments. The federated user lifecycle management application is invoked by the contact entity in response to a request from the end user. This request may be as simple as the request for protected resources by an unauthorized user as described with reference to FIG. 5 or may be an explicit request for federated user lifecycle management functionality. The federated user lifecycle management application is independent in that it does not require interaction with other parts of the computing environment, and upon successful completion of the required protocol, control returns to the contact entity where the user's request was originally received. Therefore, existing environments require minimal changes to support federated user lifecycle management functionality. For example, if the federated user lifecycle management functionality to be invoked is a single-sign-on request, this may be a response to a request for a protected resource by an unauthenticated user, and the federated user lifecycle management single-sign-on Functionality is invoked instead of the normal authentication process. In a preferred embodiment of the invention, instead of the legacy login process, a simple configuration change is required that allows the user to be resent to the federated user lifecycle management application.

Trust for federated user lifecycle management Infrastructure  support

As noted above, conventional solutions that provide federated user lifecycle management functionality scale to allow loosely coupled environments that remove existing partners from computing environments or bring new partners online without changing the environment on both sides. It is not. The loosely coupled nature possible by a federated user lifecycle management solution relates to the end user's ability to control from a computing environment in a partner environment to control resources and the correspondence between federated partners. This loosely coupled characteristic generally does not apply to trust relationships between federated partners or parties. Therefore, there is a trade-off, and the loosely coupled nature is achieved by maintaining a tightly coupled nature between federation partners or companies with respect to the trust relationship. This tightly coupled trust relationship defines the functionality available to end users in the federated environment and also defines the computing mechanism used to trust and secure communications within the federated environment.

The present invention preferably recognizes that the tightly coupled trust characteristics of the trust relationship between two partners / party may be represented by trust related or security related information. In particular, the present invention preferably implements a trust service that includes functionality to manage identity transitions that define cryptographic keys, security tokens, and trust relationships.

There are differences between the types of cryptographic trusts employed by the preferred embodiment of the present invention for trusts in transport layers with SSL certificates, and when operating trusts in protocols / applications, authentication to the identity reached by the business / legal agreement This requires an additional "combination" of the required identity in the document. Thus, without sufficient additional coupling needed for this type of functionality, it is not sufficient to affect existing SSL / transport layer trust relationships.

The combination of key, token, and identity transitions may be chosen to represent a trust relationship for the following reasons. In a given trust relationship, a set of cryptographic keys is used to sign and encrypt messages between partners. Knowledge of the keys used in transactions between partners is established before any transaction, allowing one partner to sign / encrypt a message and the other partner to verify / decrypt that message. In addition, one of the elements of the message that can be signed / encrypted is the security token used to assert the identity or role of the end user. The structure of this security token is also established before any transaction between the partners to ensure that both parties understand the contents of the security token, which guarantees that the third party trust broker's assistance can act as an arbitration between the partners. May be the result. In addition, if the security token is the required identity, a set of roles and / or attributes that can be converted from the data format is asserted by the identity provider for the data format used by the service provider, and this transition is required in the security token. Achievement is based on a predefined identity transition according to the specified agreement attribute.

Thus, the present invention preferably provides support indicative of the tightly coupled nature of the trust relationship between two partners as a set of information items, preferably a set of security-related information, in particular {encryption key, security token and identity transition}, in other words In a preferred embodiment of the present invention, this set represents a trust relationship. The present invention preferably relates to a method and system that allows for the separation of trust relationships (and management of trust relationships) and the functionality required to provide a federated user lifecycle management functionality solution. In particular, defining trust relationships comprising sets of cryptographic keys, security tokens, and identity transitions, and combining sets given to more than one set of federated partners in a manner independent of the definition of functionality available to these federated partners is described in more detail below. Provide an adjustable approach to federated management.

7 is a block diagram illustrating the organization of logical components that separate credit relationship management from federated user lifecycle management. The federated user lifecycle management application 702 is similar to the federated user lifecycle management application 508 shown in FIG. 5. The federated user lifecycle management application 702 includes support for other additional federated functionality that may be implemented, such as single-sign-on, single-sign-off, account linking / breaking, and / or identity provider determination. . All of this functionality in some way affects the trust relationship between partners. If the federated user lifecycle management application 702 requests a security token, for example to refer to an end user / application in a federated environment, this information is requested via the trust service request / message 706 from the trust service 704. In addition, various types of interfaces may be implemented between federated user lifecycle management applications and trust management. In addition, the trust service can interact with other components in the federated domain, including contact servers. Trust relationship management functionality 708 is simply a logical boundary that separates the functional modules involved in supporting the management of trust relationships for a given federated partner.

Trust service 704 is an exemplary embodiment of a trust proxy / service similar to the aforementioned trust proxy / service, such as trust proxy / service 244 shown in FIG. 2B or trust proxy / service 254 shown in FIG. 2C. to be. However, trust service 704 represents one embodiment of the present invention, in which the trust proxy / service has been extended to include functionality to manage trust relationships in a particular manner. Trust relationship management of the present invention preferably includes functionality for cryptographic key management, security token management, and identity switching management. Thus, trust service 704 generates the appropriate security token, including the sign / encryption required for the token, and the proper identification of the end user / application in which the federation request is made.

Trust service 704 may be considered as broker access to various independent security-related or trust-related services. Independent services, including trust services, may be implemented in a common device or server or in a common application, and in other ways, each service may be implemented as a separate server application. Key management service 710 manages cryptographic keys and / or digital certificates required to convey information in the context of a trust relationship. The security token service 712 manages independent token instances used for security-related or secure communication between partners, and the security token plug-in 714 is independently for various types of security token standards or specifications independently published or developed. Provide functionality The identity service 716 (or identity / attribute service 716) may be secured by including a location attribute that must add a local response to the service provider's contact server based on the token received from the identity provider and a location attribute that must be added to the token. Manages the identity and / or attributes contained in the token.

Separating federated user lifecycle management functionality from trust relationship management functionality means that management of two different types of functionality can be separated. This means that if the information about the trust relationship changes, for example the cryptographic key is replaced for security purposes, the change required does not affect federated user lifecycle management donation. In addition, since trust relationship management of partners is not limited to federated user lifecycle management functionality, it can be used by different partners for the same functionality. In addition, the separation of trust relationship management means that if support for single-sign-off operations is added to a given relationship that previously supported single-sign-on operations, the trust relationship is maintained when new functionality is added to an existing trust relationship. It can be. Finally, separation of trust management means that trust relationships and their management can be reused within other contexts, such as web service security management or web service oriented architectures. Thus, the present invention is not limited to browser-based passive client architectures.

Import  Establish federation through configuration files

8A-8D summarize the concept of a preferred embodiment of the present invention in order to provide a context for the subsequent description of one embodiment of the present invention and the conceptual description of a federated relationship, wherein the preferred embodiment of the present invention described above is electronic communication. Use to facilitate the establishment of federation relationships between business partners. 8A-8D are block diagrams illustrating the compartments provided by a preferred embodiment of the present invention. In particular, FIGS. 8A-8D show a different set of functionality to create efficiency in implementing a federated environment that can handle multiple federated specifications simultaneously in combination with minimal changes to existing computing environments that interact with federated functionality. It represents an embodiment of the present invention is divided. The description of FIGS. 8A-8D refers to similar elements with common reference numerals.

8A is a block diagram illustrating the high abstraction of logical functionality of a federated computing environment. As outlined above, enterprises and potential federated partners must complete some preliminary work before joining a federated computing environment. An advantage of the federated architecture of the present invention in accordance with the preferred embodiment is that, in a given enterprise domain 800, the present invention may be applied to the existing computing environment functionality 804 of the enterprise and its federated partners to interact with the federated infrastructure functionality 806. Minimal infrastructure functional change 802 is required. This feature has been described in detail above with reference to FIG. 2B.

Referring now to FIG. 8B, FIG. 8B is a block diagram illustrating a high abstraction of the logical functionality of a federated computing environment illustrating how a preferred embodiment of the present invention provides separation of federated functionality and contact functionality from trust relationship management functionality. As discussed above, within the federated infrastructure functionality 806 of the preferred embodiment of the present invention, the combination 808 of contact donation and soft operation functionality is separated from the trust relationship management functionality 812 so that users within the federation may be able to utilize the present invention. According to various embodiments, the protection functionality 812 is accessed through the existing application server 814 through federation functionality. The separation of the contact functionality from the trust relationship management functionality and its benefits have been described above in detail with reference to the federated infrastructure components shown in FIGS. 2C and 4 and the functional process shown in FIGS. 3A-3E.

The description of the federation function of the previous figures, for example FIG. 4, further distinguishes between the many types of federation functions and operations that can be achieved between federation partners, and in particular single-sign-on operation, ie federated authentication. Regarding the operation, the contact server is described as performing the contact operation in conjunction with federation functions and operations such as, for example, processing the security assertion and processing of the security token with the help of a trust proxy / service. In other words, the description of the federation function in the previous figure does not distinguish between contact functionality and federation operation functionality, and the contact server performs a combination of functions, and some of the responsibility of the contact server is for the federated enterprise domain. Acting as a contact entity, the rest of the responsibility of the contact server is to perform any federated operations and functions while relying on a trust proxy / service to handle trust / security operations. However, the description of the preferred embodiment of the present invention after FIG. 4 provides in more detail the manner in which embodiments of the present invention may implement differences between contact functionality and other federated operation functionality as described with reference to FIG. 8C.

8C is a block diagram illustrating a high abstraction of the logical functionality of a federated computing environment illustrating how a preferred embodiment of the present invention provides for separation of federated operational functionality from contact functionality. As discussed above, within the federation infrastructure functionality 806, the trust relationship management functionality 810 is separate from the other functionality provided within the federation infrastructure of the preferred embodiment of the present invention. Further, another functional separation can be made between other functions such that contact functionality 816 can be separated from federated operation functionality 818. The separation of the contact functionality from the federated operational functionality and its benefits have been described above in detail with respect to the federated infrastructure component shown in FIG. 5 and the functional process shown in FIG. 6, and the federated user lifecycle management application 508 of FIG. 6, FULM application) shows one form of federated operation performance.

Thus, the present invention preferably facilitates differentiation or modularization of other functionalities. In one embodiment of the present invention, the combination of contact functionality and federated operation functionality is separated from trust relationship management functionality. In another embodiment of the present invention, in addition to the continuous division of trust relationship management functionality, the contact functionality is separated from the federated operation functionality, one form of which is federated user lifecycle management functionality. Differences in the separation of trust relationship management functionality and federated user lifecycle management functionality have been described above with reference to FIG. 7. Given the distinction, FIG. 8D shows another embodiment of the present invention with another difference shown.

Referring now to FIG. 8D, FIG. 8D illustrates a high abstraction of the logical functionality of a federated computing environment, illustrating how a preferred embodiment of the present invention provides for separation of federated operational functionality into federated user lifecycle management functionality and federated relationship management functionality. It is a block diagram showing. As described above with reference to FIG. 8C, the contact functionality 816 may be shown as separate from the coalescing operation functionality 818. In addition, as described with reference to FIGS. 5 and 6, the contact entity may operate independently from the federation operation functionality in the domain with minimal configuration changes to recognize input requests for federation operations as compared to the request for accessing protected resources. Can be. Therefore, this capability is reflected in FIG. 8D by indicating that the contact functionality 820 has been separated from the federated infrastructure functionality 806.

As described above with reference to FIG. 8B, the combination 808 of contact functionality and federated operation functionality may be separated from the trust relationship management functionality 810 within the federated infrastructure functionality 806 in embodiments of the present invention. After the federated user lifecycle management function has been described with reference to FIGS. 5 and 6, the description of FIG. 7 described how the trust relationship management function continues to be implemented separately from the federated user lifecycle management function. In addition, the description of FIG. 7 described the same functionality that may be used for different federation partners in a modular fashion.

In other words, trust relationship management functions interact with federated infrastructure functions but can be implemented to be independent of these functions. Therefore, this capability is reflected in FIG. 8D by indicating that trust relationship management functionality 822 is separate from federated infrastructure functionality 806. The importance of this difference is explained in detail later.

8D also illustrates the difference in the combined operation functionality of the present invention in accordance with the preferred embodiment. Federated operational functionality, such as federated operational functionality 818, includes an operation or function that enables transactions or interactions between federated partners in a federated computing environment. Federated operational functionality differs from federated infrastructure functionality 806, which includes an action or function that combines with an existing enterprise function, for example, to allow federated partners to implement federated operational functionality.

The federated user lifecycle management application 508 of FIG. 5 and the federated user lifecycle management function represented by the FULM application of FIG. 6 are just one form of federated operational functionality. As noted above, the federated user lifecycle management functionality includes the ability to support or manage federated operations for a given user's user profile or specific user account in multiple federated domains, in which case the function or operation is a given user. Limited to federated sessions for. In other words, federated user lifecycle management functionality refers to the functionality that allows management of federated operations through multiple federated partners only during the lifecycle of a single user session in a federated computing environment.

8D reflects that the federated operational functionality of the preferred embodiment of the present invention may include a number of forms. In conjunction with federated user lifecycle management functionality 824 as one form of federated operation functionality, one embodiment of the present invention may also implement federated relationship functionality 826, as described in detail below, and between federated partners. The difference between a trust relationship and a coalition relationship between federation partners is described in detail later.

Referring now to FIGS. 9A-9B, FIGS. 9A-9B are Venn diagrams illustrating how a federated relationship includes a trust relationship with respect to the selection of the federated function. Federation allows the exposure of business processes between business partners. The exposure of a company's business process is not performed without consideration of many factors. For example, companies consider exposing business processes to trusted partners. Therefore, the present invention preferably recognizes the need for an enterprise to limit the exposure of business processes only to trusted federated partners, in that different business partners have different levels of trust.

However, even within the same federated computing environment, different sets of federated partners may have different requirements for interacting with each other. Therefore, the present invention preferably recognizes the need for an enterprise to limit the exposure of business processes to other federated partners in different ways.

Thus, in the present invention, the federation function preferably includes an electronic operation or function that supports electronic transactions between trusted federation partners. Since there is a trust level between federated partners prior to exposure of business processes, a trust relationship must exist between federated partners before the federated relationship is involved. In other words, the federation function involves the selection of an electronic transaction that is later associated with a trust relationship. This logic is reflected in the Venn diagram of FIGS. 9A, 9B and 9C.

Referring to FIG. 9A, a federation relationship 902 between two federation partners includes a relationship between the trust relationship 904 of the two federation partners and the selection of a set of federation operations / functions 906 to be implemented by the two federation partners. When comparing the schematic of FIG. 9A with the manner in which an embodiment of the present invention can organize federated infrastructure functions and trust relationship management functions within an enterprise computing environment, the benefits of implementing a federated computing environment are described in detail below. It becomes apparent as

9B and 9C, two federation partners have multiple federations. The first federated relationship between the two federated partners (FIG. 9B) includes a relationship between the first trusted relationship 914 of the two federated partners and the first selection of federated operations / functions 916 to be implemented by the two federated partners. In addition, a second federation relationship (FIG. 9C) 922 between the two federated partners is between the second trust relationship 924 of the two federated partners and the second selection of federated actions / functions 926 to be implemented by the two federated partners. Include relevance. In this embodiment, multiple trust relationships between two federated partners are used within multiple federated relationships. Many trust relationships have similar characteristics, but have different implementation data, such as other cryptographic keys or other digital certificates of similar size, such that, for example, different federation operations may be performed by different digital certificates.

However, the other two choices of functions 916 and 926 may mean that different federation operations may be performed on trust relationships with different strengths by employing trust relationships with other properties. Different strength trust relationships may be based on various criteria, for example, different cryptographic algorithms or different cryptographic key sizes. For example, single-sign-on operations may be performed using weaker trust relationships and other federation operations such as user preparation may be performed using stronger trust relationships.

For example, a pair of federated partners may interact with many other federated partners to support the first commercial project, and the commercial project may require the use of a first trust relationship with specific characteristics through various negotiated business agreements. At the same time, these federated partners interact with other sets of federated partners to support the second commercial project, which may require the use of a second trust relationship that has different characteristics from the first trust relationship, all of which Are governed by other business agreements. Therefore, in this scenario, different commercial projects may require different federation relationships, including different trust relationships.

Referring now to FIG. 10, FIG. 10 is a data flow diagram illustrating a series of operations performed by a pair of business partners for interaction within a federated computing environment, in accordance with a preferred embodiment of the present invention. An enterprise, such as partner 1002 and its potential federated partner, such as partner 1004, must establish a federation before attempting to interact within the federated computing environment. As mentioned above, federation relationships are based on trust relationships, which represent the trusts of federated partners in business and legal agreements. Thus, if performed under the support of a specific trust relationship that allows partners to grant policy governing the acceptable actions for the type of trust relationship required, the partners may be given some form of their interaction, e.g., some sort of responsibility. Determine if it is related to an action. Therefore, as shown by interaction data flow 1006, an enterprise and its potential federated partners must establish a trust relationship before attempting to interact within the federation. If the federation associates the selection of the federation function with the trust relationship, then the federation function must be configured at each partner, shown in configuration operations 1008 and 1010, after which the federation relationship is driven by interaction data flow 1012. It may be formed as shown. After a federated relationship is established, business partners can interact in a federated manner by engaging in a federated transaction as indicated by interaction data flow 1014.

If an enterprise wants to have the proper support to successfully complete a federated transaction, the configuration of the federation function needs to be performed at any time before the start of the federated transaction. For example, federation functionality may be implemented before a trust relationship is established. While configuring federation relationships may facilitate the selection of federation functions, configuration of federation functions may be performed after the federation is established. In addition, according to the present invention, the federation function may be changed after the association is established in order to enhance the federation function without necessarily requiring a change in the previously established association relationship.

Referring now to FIG. 11, FIG. 11 is a block diagram illustrating the interaction between business partners for establishing a trust relationship in preparation for establishing a federated relationship in accordance with a preferred embodiment of the present invention. As mentioned above, a trust relationship includes any kind of bootstrap process in which an initial trust is established between business partners. Portions of this bootstrap may include rules defining shared secret keys and expectations and / or token types and identity transitions allowed. This bootstrap process can be implemented out-of-band as the process may involve the establishment of a business agreement that governs the federation's participation in the enterprise and the legal responsibilities associated with that participation.

The purpose of the bootstrap process is to provide a business partner, i.e., a business association, with the business partner's trust information, which is more than a combination of identity to a cryptographic key as part of the creation of a digital certificate for the business partner, and the creation of a certificate. Is handled by a certification authority that asserts the business partner's identity. This federated trust bootstrap asserts that the partner's identity is limited to a pre-negotiated business agreement, legal agreement, or similar type of combination, as required by digital certificates.

The present invention preferably makes the form of the trust relationship flexible. For example, federation partners can interact using different types of security tokens. As described above with reference to FIG. 7, an embodiment of the present invention provides a trust service for managing a trust relationship between a given enterprise and its business partners while separating the function of managing trust relationships from the functions for federated user lifecycle management. Can be merged. However, the description of FIG. 7 does not provide another explanation of how the trust relationship is established.

FIG. 11 illustrates how a trust service 704 as shown in FIG. 7 provides functional support in the computing environment of the federated partner 1102 to establish a trust relationship with the federated partner 1104. The trust relationship management console application 1106 within the computing environment 1102 relies on the trust service 704 to provide similar configuration applications and information within the computing environment of the federation partner 1104, such as the federation partner 1104's computing environment. Can be exchanged. As mentioned above, a trust relationship between two partners is implemented within a preferred embodiment of the present invention as a set of information items that includes a set of security related information, for example {encryption key, security token and identity transition}. Thus, trust service 704 may exchange information about the expected token format 1108, cryptographic key 1110, and identity transition 1112, and then trust relationship management console application 1106 or trust service. 704 is stored in trust relationship database 1114. Each trust relationship represented in trust relationship database 1114 may have additional information for describing or implementing a trust relationship.

Referring now to FIG. 12, FIG. 12 is a block diagram illustrating a configuration of a computing environment for including federation functionality. As described above with reference to FIG. 10, the configuration of the federation function needs to be performed at any time before the start of the federated transaction. As described above with reference to FIG. 5, the federated user lifecycle management application 508 includes support for interacting, interacting with, or interfacing with the federated user lifecycle management plug-in 514 shown in FIG. 12.

In one embodiment of the invention, the federated protocol runtime plug-in provides functionality for various types of federated user lifecycle management standards or profiles independently published or developed. Referring to FIG. 12, a system management user in an enterprise computing environment employs a runtime environment management console application 1202 to manage the FULM application 508 and the federated user lifecycle management plug-in 514. For example, an administrator can configure the plug-in 514 in a particular directory on a particular server using the graphical user interface provided by the runtime environment management console application 1202. If new federated behavior is supported, the new plug-in is deployed by the administrator by storing the new plug-in in the appropriate directory, and an updated version of the new plug-in is managed by a third-party vendor, a centralized federated database, or any other. Can be retrieved by location. Configuration files and / or properties files contain runtime parameters for plug-ins 514, such as URIs used during federated transactions, which can be created, changed, and deleted by administrators through runtime environment management console application 1202. .

Referring now to FIG. 13A, FIG. 13A is a block diagram illustrating a federated relationship management console application that may be used by a system management user to establish a federated relationship within an enterprise computing environment in accordance with an embodiment of the present invention. As mentioned above, the federation includes the selection of federation functions that must be agreed between the partners, for example, both partners may agree to affect single-sign-on functionality. However, in order to implement this functionality, both parties need to be aware of the partner-specific information for the selected function, such as a URI for sending a single-sign-on request / response message. The information pertaining to a partner collected by one federation partner from another federation partner depends on the federation function defined or selected for a specific federation relationship between federation partners. Information based on this partner needs to be exchanged between partners.

Thus, since the information required from each federation partner may vary, a single configuration type file or template file may not be distributed to all federation partners by the first federation partner. According to the defined federation, the information required by the runtime to execute federated transactions is partner specification. If the manager of the first partner does not tailor this configuration form or template for each federation partner based on the configured capabilities of the particular federation, then the other partner may or may not need a specific federation, within the configuration form or template. It is required to provide all the information that may be required by the.

The present invention preferably takes the approach in which a federation specific XML configuration file is dynamically generated and exported to the federation partner during federation, where the federation partner provides the configuration information according to the requested partner and returns it to the requestor. . After the completed file is received from the partner, the requesting partner can import specific configuration information and associate it with the appropriate federation, as detailed later.

Referring to FIG. 13A, an administrative user employs a federated relationship management console application 1300 to establish a federated relationship. Since each federated relationship includes a trust relationship, the federated relationship management console application 1300 retrieves information about the established trust relationship from the trust relationship database 1302. The trust relationship database 1302 includes an entry for each trust relationship established between the enterprise and its trusted business partners as described above with reference to FIG. 11, and the trust relationship database 1302 of FIG. 13A is shown in FIG. Is similar to the trust relationship database 1114. The databases, configuration files, data structures, and the like described herein may be implemented as a general datastore or many other types of datastores such that any datastore can be implemented as a database, file, data structure. In the example shown in FIG. 13A, trust relationship database 1302 includes a trust relationship called "Trust-XY" represented by trust relationship database entry 1304. As described above, each trust relationship includes a set of information, and the trust relationship database entry 1304 includes a set 1306 that includes cryptographic key information 1308, token format information 1310, and identity switching information 1312. ). Each trust relationship may also be contacted to perform operations on information, such as the identity of the partner participating in the trust relationship, trust relationship, according to any additional partner for implementing the expressed trust relationship. Information about the identity or location of the information or other similar type of information.

The federation also includes partner-specific information about the federation functions supported within the federation, so the federation management console application 1300 may also be already configured within the enterprise computing environment or within the enterprise domain or computing environment. Retrieve information according to the federation function for the federation function to be configured. For example, assuming that an enterprise computing environment is implemented in accordance with an embodiment of the present invention similar to that described above with reference to FIG. 5, federated relationship management console application 1300 scans a directory containing files and FULM By reading the configuration and / or properties file 1314 associated with the application and / or its associated plug, or any other manner, it is possible to retrieve information about the FULM application and / or its associated plug-in from various information sources. In one embodiment, after gathering this information, federation relationship management console application 1300 is registry 1316, which is a compilation of information about federation functions supported within the corporate domain or computing environment and available to the corporate domain or computing environment. Can be formed. In the example shown in FIG. 13A, registry 1316 includes an entry 1318 for the type of federation function available, which registry entry 1318 also represents a number of metadata parameters required by a given federation function. Associated with a number of fields 1320, the metadata represents configuration data according to the partner needed by the federation partner to manage or invoke a given federation function during an instance of the federation transaction employing the federation function. In one embodiment, the registry 1316 is a temporary datastore or data structure that is dynamically created each time the federated relationship management console application 1300 is used by an administrative user. In another embodiment, the registry 1316 is a corporate enterprise. Managed by any other configuration utility in the domain or computing environment, such as runtime environment management console application 1202 shown in FIG.

In any case, information about metadata parameters coupled to the federation function is determined when a software module implementing the federation function is generated. In other words, these metadata parameters are according to the federation function, and the metadata parameters are combined with a software module that implements the federation function in any way. Therefore, the identity of the metadata parameter 1320 associated with the federation function should preferably involve a software module that implements the federation function as metadata parameters according to the function in the configuration and / or properties file 1314. This configuration and / or properties file 1314 is deployed or configured within the enterprise computing environment when a software module is deployed, for example when a FULM application and / or its plug-in is deployed. Alternatively, the number and nature of metadata parameters 1320 can be retrieved from any other data source, such as a common centralized federated database. In another example, the number and nature of the metadata parameters 1320 may be derived from an electronic file describing the specification of the federation protocol, where the specification file may be used to describe the implementation of the federation function for the federation function attached to a particular federation protocol. A standard set of metadata parameters may be described to contain data, requiring an interface or data exchange that is expected to be implemented by any software module for the federation protocol. In any case, the number and nature of the metadata parameters 1320 are available for retrieval by the federation relationship console application 1300.

The federated relationship management console application 1300 retrieves information about trust relationships and federation functions while assisting administrative users to establish federated relationships. These search relationships are represented by entries in the federation relationship database 1322. In the example shown in FIG. 13A, federation database entry 1324 represents a federated relationship named "Fed--XY--ProjectX", in which an identifier for the federated relationship is indicative of the purpose of the federated relationship. It provides an indication of a federation partner working simultaneously in a federation together, eg partner "X" and partner "Y". If a federation partner acts for many different purposes and each purpose has its own requirements, then a pair of federation partners may have multiple federation relationships as described with reference to FIGS. 9A and 9B.

In the example shown in FIG. 13A, trust relationship database entry 1304 includes a trust relationship set 1328 that includes an encryption key 1330, token format information 1332, and identity / attribute conversion information 1334. It is copied into federation relationship database entry 1324 as trust relationship data 1326. Alternatively, federation database entry 1324 simply trusts database entry 1304 in trust relationship database 1302 so that trust relationship database entry 1304 is modified without requiring updating of federation database entry 1324. You can store the reference or pointer with). Individual data items containing elements of trust relationships such as cryptographic keys and certificates may also be included by reference to increase the efficiency of managing these data items. Federation relationship database entry 1324 also related metadata information for federation operations / functions, such as functions 1336 and 1338, and implementation requirements to be supported by the federation relationship represented by federation database entry 1324. Information about 1340 and 1342, respectively. Alternatively, federation database entry 1324 may store a reference or pointer to a suitable location, such as configuration and / or properties file 1314, from which information about supported federation functions / operations may be retrieved. have.

At a future point in time, federation database entry 1324 will be used to initiate a federation transaction that will use the federation function indicated in federation database entry 1324, i.e., functions 1336 and 1338. However, in order to initiate or complete a federated transaction, the information according to the partner is indicated by the federation function through metadata information requiring information according to the partner according to the information 1340 and 1342 combined with the functions 1336 and 1338. Should be used for the instance being created. For example, the information according to the partner may include one or more URIs indicating the target destination of the request message sent to the federated partner to request a federated transaction with a particular federated partner.

In one embodiment of the present invention, while the administrative user forms or establishes a federated relationship using the federated relationship management console application 1300 or similar management software tool, the federated relationship management console application 1300 obtains information according to a partner and The information is to be stored in federation database entry 1324 as data items according to the partner, for example data items 1344 and 1346. To this end, the federation relationship management console application 1300 dynamically generates a federation establishment template file 1348, which may be an XML format file or any other type of file. The template 1348 is, as indicated in the trust relationship data 1326, a trusted partner, eg, partner ", by which the administrative user is to establish a federated relationship by the original partner, eg, partner" X. " Exported to Y ". By modifying the template file 1348 and including the information to provide the trusted partner with information according to the requested partner, the federation relationship management console application 1300 of the requesting partner may change the template file ( Import 1348, extract the provided information, and store the information in federation database entry 1324.

The configuration information according to the partner also needs to be transmitted from the above-described administrative user's computing environment, i. The target federation partner may need information from the perspective of the cooperative / target federation partner according to a given partner about the originating partner making up the federation, for example the cooperative / target federation partner may The federated partner can use the federation function to initiate federated transactions in combination with the configuration data according to the partner in the vast direction towards the domain of the partner "X", for example, the federated partner who has already initiated the formation. Similar metadata information such as URI of the contact server may be required. Therefore, template file 1348 may also include information according to the administrative user, i.e., the partner for the domain of partner "X". Alternatively, the two files can be transferred to the file that is accompanied by the information according to the originating partner, that is, the partner for partner "X" or to a subsequent file, so that the two files can be used to transfer the information according to the partner between the partners. have. While administrative users form a federation, information pertaining to partners sent from originating / source partners to collaborative / target partners is entered by the administrative user through federation management console application 1300 or all or part of the data is federated. It may be obtained from a configuration database managed by the management console application 1300.

The information according to the partners exchanged between federated partners in the manner described above may not be symmetrical. In other words, federation partners can assume very different roles and engage in federated transactions, which may require different types of information to be provided to each federated partner. For example, an administrative user can operate an enterprise acting as an identity provider. A federated relationship may support a subset of the functions specified by the Free Alliance Free ID-FF specification. In this scenario, the federation function may include a browser / artificial single-sign-on, an identity provider initiated HTTP retransmission based register name identifier, and a service provider initiated SOAP / HTTP federation termination notification. In particular, in the federation function, the type of information according to the partner provided by the identity provider to the service provider may be different from the type of information according to the partner provided by the service provider to the identity provider. If the information per partner depends on the federated partner's assumed role for a federated relationship, the administrative user is not allowed to enter the federated relationship management console application 1300 unless the role is preconfigured or stored in the configuration file or the federation management database. Inform the role of the administrative user to be played by the enterprise. The administrative user may inform the federated relationship management console application by selecting or entering the appropriate data options in the GUI provided by the federated relationship management console application as shown in FIG. 13B.

Referring now to FIG. 13B, FIG. 13B is a diagram illustrating a graphical user interface window within a federated relationship management application used by an administrative user to establish a federated relationship between federated partners in accordance with a preferred embodiment of the present invention. Dialog window 1350 is a drop-down menu 1352 that allows a user to select a trust relationship based on a federation created by the federation relationship console application, such as the federation relationship console application 1300 shown in FIG. 13A. Includes. Alternatively, if desired, for a particular federation, the user may press the dialog button or select a menu item to dynamically create a new trust relationship, for example, by trust relationship management console application 1106 shown in FIG. Functionality within a federated relationship management console application or any other application. The establishment of trust relationship involves using existing information about the management user's enterprise such as existing private key, digital certificate, token, and identity mapping information, and the token information is configured not to be changed by each partner. Thus, even if the token information is not configured, the administrative user can, if available, configure the rest of the trust relationship using known information about trusted partners, such as public keys, digital certificates, identity mapping information, and the like.

Drop-down menu 1354 allows the user to select a federation function to be supported within the created federation. The text entry field 1356 can be used to enter a name for the federated relationship that is created. Button 1358 continues the establishment of a federation by closing the dialog window and generating an entry in the appropriate datastore in a manner similar to that shown in FIG. 13A, and button 1360 closes the dialog window and cancels the creation of the association. . For example, if an administrative user selects button 1358, the console application can be a partner between two partners that will participate in the federation by exporting and importing a federation establishment template file according to the partner described above and described in more detail below. Disclosing the configuration information according to.

13C and 13D are block diagrams illustrating the data flow initiated by a federated relationship management console application for obtaining data according to a partner to establish a federated relationship within an enterprise computing environment in accordance with a preferred embodiment of the present invention. As described above with reference to FIG. 13A, federation relationship management console application 1300 dynamically generates federation establishment template file 1348. For example, federation management console application 1300 may generate template 1348 after instructing the user to perform the application via dialog window 1350 shown in FIG. 13B. The contents of the template 1348 are dynamically determined for the federation relationships in which the federation management console application 1300 attempts to obtain data according to the partner. Referring to FIG. 13C, the federation relationship console application 1300 generates a template 1348 based on the federation relationship represented by the federation database entry 1324. In a manner similar to FIG. 13A, federation database entry 1324 is used to implement information about federation operations / functions supported by the federation represented by federation database entry 1324, eg, combined functionality. A function 1336 for the necessary parameters and combined metadata information 1340. When federation management console application 1300 generates template 1348, the application extracts metadata information 1340 and names in template 1348 for the indicated metadata parameter entries required from federation database entry 1324. Create a field or element 1354 as a -value pair. If the template 1348 is an XML-based file, the name-value pairs can be included as tag elements in the file. At this point, the template 1348 does not yet contain data according to any partner, and at any subsequent point in time, the template 1348 is sent to the collaboration / target federation partner and any Get data based on the partners needed to execute federated transactions in the future.

Referring to FIG. 13D, the template 1348 includes a name-value pair 1356 changed after the collaboration / target federation partner returns the template 1348, and the collaboration / target federation partner is an automatic processing but cooperation / target. Interact with the administrative user through the federated partner's graphical user interface application to parse the template 1348, extract the request for the name-value pair, and obtain the required value. Subsequently, at the originating / source federation partner, federation relationship management console application 1300 extracts the returned name-value pair and sends it to the cooperative / target federation partner as data items 1358-1362 in federation database entry 1324. Store information according to the partner provided by Data items 1358-1362 are subsequently used to complete a federated transaction with a federated partner at a future point in time. Even in this case, the partner-specific configuration information for the originating / source federated partner is sent from the template 1348 to the federated partner so that the federated partner can participate in the federated transaction or initiate a similar federated transaction in a massive direction. Make sure you have the information. In this way, a single file is sent even if it is changed before returning.

Alternatively, the configuration information according to the originating / source federated partner, i.e., the partner of the two partners initiating the formation of the federated partner, may be sent in two messages or files simultaneously with the transmission of the first file or at another point in time. And the second file sends the information according to the partner for the originating / source federation partner to the cooperative / target federation partner and is not returned. For example, a first file may be sent from a collaboration / target federation partner to an federated partner as an "empty" file that requires the inclusion of information according to the partner, and then the first file is information per partner for the federated partner. Returned by changing to include. In contrast, the second file is sent to the federation partner as a "full" file that provides information according to the partner from the originating / source federation partner to the cooperative / target federation partner.

Referring now to FIG. 14, FIG. 14 illustrates a process in which a federation is established in an automated manner through the use of an export / import file exchanged between federated partners interacting through a federation in accordance with one embodiment of the present invention. The flow chart is shown. The process is initiated when an administrative user with a given corporate computing environment, eg, partner "X", receives a notification to establish a federation with a trusted business partner, eg, partner "Y" (step 1402). Although the notification may be received in an out-of-band manner, the notification may be made manually, such as by mail or telephone, but preferably any manner or email within a management console application, such as the federated relationship management console application shown in FIG. 13A. Is received electronically via. In general, the federation often knows a power sponsor, which is a federation partner that acts as an originating / source partner to form information about the federation.

If the administrative user has not already done so, the administrative user invokes the federated management console application (step 1404). Alternatively, this functionality may be initiated and / or performed via a workflow-type action initiated by an application in the computing environment of the originating / source federation partner. Thus, the process shown in FIG. 14 may be fully automated based on policy decisions incorporated into the infrastructure of the computing environment, preferably using functions configured to implement the WS policy specification, for example.

The process illustrated in FIG. 14 is described from the perspective of originating / source federation partner, federation partner "X", and the process steps described with reference to FIG. 14 occur in the computing environment of the cooperative / target federation partner, federation partner "X". And similar actions may occur at federated partner “Y” in response to receiving information from federated partner “X” as described in detail below.

The administrative user initiates the formation or formation of a new federation within the federation management console application of federated partner "X" (step 1406), and the user starts a new federation, for example, "Fed--XY--PROJECTX". Either enter a name or identifier for (step 1408), or be automatically generated based on a set of information, such as a partner for creating a federation or the like.

If the act of configuring / forming a federation is initiated automatically through a workflow process, the received request message or similar initiation event may include an indication of the federation function supported within the requested federation, and, alternatively, In addition, the user may select an appropriate federation function in the federation relationship management console application as shown in FIG. 13B or the received request message may be automatically processed to determine the requested federation function.

The user selects, configures, or forms a trust relationship upon which the federation relationship is based, as shown in FIG. 13B (step 1412). If only a single trust relationship exists between the partners, the trust relationship can be automatically selected, and if an existing trust relationship is not suitable for the selected federation function, the federation relationship console application allows the user to configure or form a new trust relationship. May be urged to do so.

As will be described in detail below, a trust relationship between two business partners may be configured or formed simultaneously with the formation or formation of a federated relationship between the two business partners. Therefore, the information constituting the trust relationship can be transferred between the business partners during the period in which the information constituting the federated relationship is transmitted.

In contrast, the federation partner making up the federation can already have a trust relationship. This trust relationship may be organized for other purposes than for cooperation within the federation. This trust relationship can be established through a simple exchange of information, and in another way, the trust relationship can be established using other software applications within each computing environment but outside of federation considerations. For example, a federated partner may exchange public key / digital certificates and other trust related information that they wish to use for any transaction between them, which information may be via any other type of software or in any other way. It can be exchanged through a simple transfer of electronic information.

In addition, existing trust relationships may already be established for the purpose of interacting within the federation. In other words, if a pair of business partners can collaborate through multiple concurrent federations, then a trust relationship may already be established for a pre-established federation.

In any case, there may be one or more existing trust relationships between two business partners who wish to form or form a new federation, whether or not there is an existing federation between the two partners. If there is more than one existing trust relationship, the trust-related information of the trust relationship can be logically packaged as a single named trust relationship that can be presented within the federated relationship management console application, and if so, the administrative user can define an existing defined user within the graphical user interface. You can simply choose a trust relationship.

Alternatively, trust related information for one or more existing trust relationships may be presented to the administrative user as a separate data item of trust related information in the graphical user interface. In this scenario, the user can construct or form a new trust relationship by selecting data items to be employed within the new trust relationship. For example, a single digital certificate may be employed within multiple trust relationships, because different trust related information with multiple trust relationships may be different. Thus, as the same digital certificate is employed in each, multiple trust relationships become unique.

Alternatively, the partner may not have an existing trust relationship. In this scenario, the administrative user enters or selects the partner's "self" information, that is, trust information for the originating / source partner, which may be information based on the partner, such as a digital certificate, but with various trust related protocols. It can include desirable properties for trust relationships that can be represented by simple non-partner-specific values that can be specified within the specification. For example, an administrative user can select from a number of symmetric cryptographic key pairs retrieved by a federation establishment console application from a keystore in the partner's computing environment. In addition, the user may select various trust relationship feature parameters through checkboxes, radio buttons, menus, etc. within the graphical user, where these trust relationship feature parameters represent different processing options for trust related information.

If a trust relationship requires interaction between partners, then the choice of trust-related information by the partner, along with the choice of various trust-related features, may direct trust-related information from the collaboration / target partner to the partner requested by the originating / source partner. have. In other words, the information exchanged between partners must correspond in any way. Thus, the selection of the administrative user includes trust related information according to the originating / source partner's partner in the template.configuration file / files exported to the collaboration / target partner. The choice of administrative user also includes the information request element in the template / configuration file / files exported by the originating / source partner to the collaboration / target partner. In any case, the federation function may not require any trust support, so there is no need to select a trust relationship. Since a federated relationship is defined as including a trust relationship, in this scenario, the federated relationship may be described as including a null trust relationship.

Preferably, the trust relationship and / or trust relationship information may be selected or selected after the federation function is selected, since a given function may be more appropriately combined with a given trust relationship, i.e., with a given option selection, for trust related processing. Is entered. For example, a particular token type may have requirements regarding encryption or signatures that must be performed for instances of the token type.

After creation of the federation is initiated at federation partner "X", a federation establishment template file is dynamically generated (step 1414). The template file is constructed according to the data that needs to be collected from the federation partner, as described above with reference to FIG. 13C. The template file is then sent to federation partner "Y" (step 1416), and federation partner "Y" changes the received template file to include information according to the partner and returns the changed template file to federation partner "X". do. After the modified template file has been received (step 1418), the information according to the requested partner is extracted (step 1420) and stored in federation partner "X" during the subsequent federation transaction (step 1422) and the process ends.

The template file (or within the second file) may contain information according to the partner for partner "X" sent to partner "Y", and the template file with information for federated partner "X" may be a federated partner "Y". When sent to ", this information is imported into the computing environment of federated partner" Y "to configure federation on federated partner" Y "and to prevent the administrative user of partner" Y "from manually configuring information about federated relationships. The import of information for federated partner "X" in the computing environment of federated partner "Y" may be performed automatically.

In another embodiment, instead of selecting a pre-created trust relationship, the trust relationship while a federation relationship is formed using the functionality in the trust relationship management console application shown in FIG. 11 in conjunction with the federation relationship management console application shown in FIG. 13A. Can also be formed. Alternatively, the federation management console application may include the ability to obtain trust information from an appropriate data store, such as a keystore, or to enter trust information from an administrative user. In this case, the administrative user enters or selects information by entering or selecting a plurality of private keys or a plurality of certificates to form a trust relationship on which the federation relationship is based. The enterprise of the administrative user, eg, partner "X", can add this trust information, eg, public key certificate, to a template file or accompanying file sent to the federated partner. Similarly, the modified template file received from the federation partner may have information according to the partner for establishing a trust relationship in addition to the information according to the partner for establishing a federated relationship. Trust relationship information may also be extracted from the file received with the federation relationship information, and the extracted trust relationship information may be combined with the configuration information for the federated relationship in any manner. The administrative user can obtain all or the remainder of the trust relationship information and / or federation relationship information from one or more other sources and then enter this information through the federation relationship console application to configure the desired trust relationship or desired federation relationship.

Therefore, the trust relationship is formed in two phases. In the first phase, the administrative user has all the trust information for the federated partner "X" that will be used to protect the information by a cryptographic and / or digital signature that will be sent to the federated partner "Y" and / or other federated partners, for example. , Collect the private key. If federated partner "X" has only one set of cryptographic keys, there is no choice of trust relationship for administrative users at federated partner "X", but when the federated user configures the federated relationship to form a new trust relationship, You may have the option of adding a key.

In the second phase, all trust information for the federation partner "Y" to be used to validate or verify the information received from the federation partner "Y", for example public key and / or digital certificate, is collected. If federated partner "X" already stores information about federated partner "Y", the administrative user can use the information, and the administrative user is presented with a list, such as a secret key, while configuring the trust relationship through the administrative console application. Can be presented. If federated partner "X" does not store information for federated partner "Y", the administrative user of partner "X" may choose to add trust information, such as new keys, at runtime using the administrative console application. Alternatively, as described above, an administrative user of federated partner "X" may choose to import trust information for federated partner "Y" via a configuration file according to the partner, and thereafter, The appropriate application can automatically update the trust information for federated partner "Y" on the datastore of federated partner "X" to establish a trust relationship between the two federated partners.

conclusion

The advantages of the present invention are apparent in view of the detailed description of the invention provided above.

The present invention preferably affects existing environments in which federated user lifecycle management solutions are integrated. The federated user lifecycle management functional component is invoked by the contact functional component in response to a request from an end user. The federated user lifecycle management functional component is independent in that it does not require any interaction with other parts of the computing environment. If the requested protocol completes successfully, control returns to the contact functional component from which the user's request was originally received. Therefore, existing environments require minimal changes to support federated user lifecycle management functions. For example, if the federated user lifecycle management function to be invoked is a single-sign-on request, it can respond to requests for protected resources by unauthorized users, where federated user lifecycle management single-sign- On functionality is invoked instead of the normal authentication process. In the present invention, it is desirable to require a simple configuration change that allows the user to be redirected to the federated user lifecycle functional component instead of the legacy login process.

By making minimal changes to the entire infrastructure, federated user lifecycle management applications can be easily changed to support new protocols / standards. Any changes required to support the new federated user lifecycle management functionality are deployed exclusively within the federated user lifecycle management application, which requires configuring the federated user lifecycle management application to understand the added functionality.

You can minimize the configuration changes of other federated components on the point-of-contact server so that the entire infrastructure can invoke the new federated user lifecycle management capabilities while continuing to support existing federated user lifecycle management capabilities. However, the federated user lifecycle management application is functionally independent of the rest of the federated component in that the federated user lifecycle management function does not require interaction with other federated components of the federated environment.

Therefore, existing environments require minimal changes to support federated user lifecycle management functionality when implemented in accordance with preferred embodiments of the present invention. In addition, changes to federated user lifecycle management capabilities, including the addition of new features, cause minimal conflicts in existing federated environments. Thus, when a new single-sign-on standard is published, support for this standard is easily added. Among the advantages of the present invention, trust proxies allow existing security services in a given domain to establish trust relationships with other domains without using the same trust establishment techniques or signing the same trust root. Therefore, the federation architecture of the present invention preferably provides for loose coupling of entities. Federation allows users to traverse other sites within a given federation in a single-sign-on manner.

Although the present invention has been described in the context of a fully functional data processing system, the process of the present invention may be modified in various forms and forms of instructions of a computer readable medium, regardless of the particular type of signal bearing medium actually used to perform the dispersion. It will be apparent to those skilled in the art that they can be dispersed in form. Examples of computer readable media include media such as EPROM, ROM, tape, paper, floppy disk, hard disk, RAM and CD-ROM, and transmission media such as digital and analog communication links.

summary

A method and system are disclosed for interacting with a federated service provider within a federated environment to initiate federated operation. The contact component providing session management capabilities of the first service provider receives a request from a client. The request is sent to the federated user lifecycle management functional component of the first service provider using retransmission through the client, the first service provider interacting with the touchpoint component of the second service provider to interact with the federated user lifecycle of the second service provider. Initiating a management function, the second service provider participates in the assistance of the federated user lifecycle management functional component of the second service provider. In response to the completion of the federated user lifecycle management function, the point-of-contact server of the first service provider may receive a response from the federated user lifecycle management functional component of the first service provider and the original request may be further processed.

A method and system are disclosed in which federated domains interact within a federated environment. Domains in a federation may initiate federation operations for users of other federated domains. The point-of-contact server in the domain relies on a trust proxy in the domain to manage the trust relationship between the domain and the 15 federales. The point of contact server receives the input request directed to the domain and interacts with the first application server and the second application server, where the first application server responds to the request for access to the control resource and the second application server 20 ) Responds to a request for access to a federated user lifecycle management function implemented using one or more plug-in modules that interact with a second application server.

The method is generally considered to be a self-sustaining sequence of steps leading to a desired result. These steps require physical treatment of physical quantities. Typically, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and processed. For common use reasons, it is sometimes convenient to refer to signals such as bits, values, parameters, items, elements, objects, symbols, characters, terms, numbers, and the like. However, all terms and similar terms are convenient labels that are combined with and applied to the appropriate physical amounts.

The description of the present invention is for illustrative purposes and is not intended to be limited to the disclosed embodiments. Many modifications and variations are apparent to those skilled in the art. In order to implement various embodiments having various modifications suitable for different uses, the embodiments are intended to explain the principles and practical application of the present invention and to make the present invention understood by those skilled in the art.

Claims (70)

A method for providing federated functionality within a data processing system, the method comprising: Receiving a first request from a client at a point-of-contact functional component of a first service provider, the contact functional component configured for the clients of the first service provider; Performing session management for the first service provider, the first service provider being associated with a plurality of service providers in a federated computing environment; In response to determining that subsequent processing of the first request requires invocation of a federated user lifecycle management function, federated user lifecycle management of the first service provider from the contact functional component of the first service provider. Sending a second request to the functional component, the second request including information derived from the first request; Sending a third request from the federated user lifecycle management functional component of the first service provider to a contact functional component of a second service provider that is an identity provider of a plurality of service providers in the federated computing environment; Receiving a response from the federated user lifecycle management functional component of the second service provider at the federated user lifecycle management functional component of the first service provider; And Causing the contact functionality component of the first service provider to complete processing of the first request. Method for providing federation functionality comprising a. The first service provider of claim 1, wherein in response to the federated user lifecycle management functional component of the first service provider receiving the response, the first service provider from the federated user lifecycle management functional component of the first service provider. Receiving information at the contact functionality component of the method of providing federated functionality. 3. The method of claim 2, further comprising performing processing of the information at the contact functional component in accordance with the first response to establish a user session. 2. The federated functionality of claim 1 wherein the second request is through the redirection through the client through the contact functionality component of the first service provider from the federated user lifecycle management functionality component of the first service provider. How to Provide. 2. The method of claim 1, further comprising building a session for the client in the contact functionality component. An apparatus for providing federated functionality within a data processing system, the apparatus comprising: Apparatus for providing federated functionality with respective means for carrying out each step of the method according to claim 1. A computer-readable recording medium comprising a program for computer-implementing each step of a method according to any one of claims 1 to 5. A data processing system, A management application having an associated interface for configuring one or more pluggable modules into federated user lifecycle management functionality having a federated computing environment, each pluggable module being used in one or more of the associated transactions associated with them. The management application having a set of runtime parameters; A point-of-contact server that receives incoming requests directed to a domain associated with a plurality of domains in the federated computing environment; A first application server interfacing with the point of contact server comprising means for responding to a request for access to a controlled resource; And Means for responding to a request for access to a federated user lifecycle management function, the second application server interfacing with the point of contact server, wherein the means for responding to a request for access to the federated user lifecycle management function comprises: a plug; The second application server, invoking one of the possible modules and associated runtime parameters to provide federated user lifecycle management functionality during federation processing. Data processing system comprising a. The method of claim 8, Means for analyzing a received request message; Means for invoking the first application server to process a request received by the contact server requesting access to a controlled resource; And Means for invoking the second application server to process a request received by the point-of-contact server requesting access to a federated user lifecycle management function. Data processing system comprising a. The method of claim 8, further comprising a trust proxy, The trust proxy generates a security assertion sent from the domain and validates a security assertion received at the domain. delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete

Images