Method and system for proof-of-possession operations associated with authentication assertions in a heterogeneous federated environment

Operation method and system for proof of possession related to verification statement in heterogeneous consortium environment

Technical field

The present invention relates to an improved data processing system, in particular to a multi-computer data transmission method and equipment. More specifically, the present invention aims at a networked computer system.

Background technique

Enterprises generally hope to provide authorized users with secure access to protected resources in a user-friendly manner in various networks, including the Internet. Although providing a secure authentication mechanism reduces the risk of unauthorized access to protected resources, the same authentication mechanism can become an obstacle to the interaction between users and protected resources. Users usually need the ability to jump from interacting with one application to interacting with another application, regardless of the authentication barriers that protect each specific system that supports these applications.

As users become more mature, they expect computer systems to coordinate their operations, thereby reducing the burden on users. These expectations also apply to the verification process. The user can assume that once he or she has been verified by a certain computer system, the verification should be valid throughout the users work session, or at least for a specific period of time, regardless of the various computer structures that are almost invisible to the user boundary. Companies often try to achieve these expectations in terms of the operational characteristics of the systems they deploy, not only to appease users, but also to increase user efficiency, regardless of whether user efficiency is related to employee productivity or customer satisfaction.

More specifically, in terms of current computing environments where many applications have web-based user interfaces that can be accessed through public browsers, users expect to be more user-friendly, with fewer or fewer obstacles, in order to move from a web-based The application is transferred to another web application. In this case, users gradually expect to have the ability to jump from interacting with an application in one Internet domain to interacting with another application in another domain without considering the verification barriers to protect each specific domain. However, even if many systems provide secure authentication through easy-to-use web-based interfaces, users still have to carefully handle multiple authentication processes that prevent users from accessing across a set of domains. Having the user go through multiple verification processes within a specified time will significantly affect the user's efficiency.

Various techniques have been used to reduce the authentication burden on users and computer system administrators. These technologies are generally called "single sign-on" (SSO) processes because they have a common purpose: after a user completes a registration operation, that is, is verified, the user is not subsequently required to perform another verification operation. Therefore, the purpose is to only require the user to complete the verification process once in a specific user session.

When implemented within a designated enterprise, this single sign-on solution is successful. However, as more companies participate in the e-commerce market or other collaborative efforts connected via the Internet, obstacles caused by multiple verification processes or systems are becoming more common. Previous single registration solutions between enterprises were limited to homogeneous environments in which there were predetermined commercial agreements between participating enterprises. These commercial agreements are partly used to establish trust, and to restrict and define how to transfer information in a secure manner between enterprises. These commercial agreements also include technical agreements on how to transform or map user identities from one enterprise to another, and how to transfer information used to guarantee users between participating enterprises.

In other words, the previous single sign-on solution allowed to trust the verification statement (and the user's identity provided in the statement) generated by different companies based on pre-arranged or pre-set agreements. Each distinct business knows how to generate and explain verification statements that can be understood by other businesses that have exchanged similar agreements, such as businesses in the e-commerce market. These homogeneous environments are closely integrated because there are certain relationships known to the enterprise that are used to map user identities between these systems. This close integration is possible due to the commercial agreement used to establish a single registration environment. Although using these previous single-registration solutions, participating companies can cooperate in homogeneous environments, but considering the need or desire to interconnect multiple homogeneous environments, these environments are restrictive, such as interconnected e-commerce markets.

Although a single sign-on solution can provide users in participating companies with easy-to-use advantages, through technologies that are also applicable to other systems, malicious users will try to abuse resources in this environment. For example, through a so-called man-in-the-middle attack, single registration information can be intercepted. In addition, a client computer used by a legitimate user for a single sign-on operation can be abused by a malicious user after the legitimate user leaves the client computer.

Therefore, it should be advantageous to have a method and system in which a company can provide users with a single sign-on experience in the absence of a predetermined business and technology conversion agreement between participating companies. It is particularly advantageous to reduce the security risk from malicious users who try to abuse a single sign-on session.

Summary of the invention

A method, device, system, and computer program product are provided in which federated domains interact in a federated environment. Domains in the commonwealth can initiate joint single sign-on operations for users in other joint domains. The point of contact server in the domain relies on the trust proxy in the domain to manage the trust relationship between the domain and the consortium. As needed, the trust agent interprets claims from other federated domains. The trust agent may have a trust relationship with one or more trust intermediaries, and the trust agent may rely on the trust intermediary to help interpret the statement. In order to improve security, the domain may also require users to re-certify their identity through a proof-of-possession challenge performed after the user initiates a single sign-on operation.

Description of the drawings

The new features peculiar to the invention are stated in the appended claims. With reference to the accompanying drawings and referring to the following detailed description, you will better understand the invention itself, other purposes and its advantages: Figure 1A depicts a typical network of data processing systems, each of which can implement the present invention; Figure 1B describes A typical computer structure that can be used in a data processing system in which the present invention can be implemented; FIG. 1C is a data flow illustrating a typical verification process that can be used when a client attempts to access a protected resource of a server Figure; Figure 1D is a network diagram illustrating a typical Web environment in which the present invention can be implemented; Figure 1E is a block diagram illustrating a typical online transaction that requires multiple verification operations to the user; Figure 2A is a diagram illustrating the user relative to the first For a transaction initiated by a consortium, a block diagram of terms in the consortium environment. In response, the first consortium invokes operations on downstream entities in the consortium environment; FIG. 2B illustrates an example of a designated domain according to an embodiment of the present invention. A comprehensive block diagram of the existing system and some consortium system structural components of the present invention; Fig. 2C is an implementation according to the present invention, illustrating a block diagram of the consortium system structure; Fig. 2D is according to the present invention, illustrating the use of trust agents and A block diagram of a set of exemplary trust relationships between the federated domains of the trust intermediary; Figure 3A is a flowchart illustrating the general process of generating a statement in the consortium environment located in the issuing domain; Figure 3B is a diagram illustrating the general process of generating a statement in the trust domain, Tear off down) a flow chart of the general process of a statement; Figure 3C is a flowchart illustrating the specific process of pushing a statement from the publishing domain to the trust region in response to user operations in the publishing domain; Figure 3D is a flowchart illustrating the response to the publishing domains active interception of the trust The output request of the domain, the flow chart of the specific process of pushing the statement from the publishing domain to the trust domain; Figure 3E is a diagram illustrating that while trying to satisfy the resource request received by the trust domain from the requesting user, the trust domain requests information from the publishing domain. Figure 4 is a block diagram illustrating a consortium environment that supports joint single sign-on operations; Figure 5 is a flow chart describing the use of direct communication between trust agents located in the issuing domain and the trust domain. The call flow diagram of the proof of possession challenge verified by the issuing party; Figure 6 depicts the call flow diagram of the proof of possession challenge verified by the relying party using the direct communication between the trust agents located in the publishing domain and the trust domain;

Figure 7 is a call flow diagram describing the proof of possession challenge verified by the issuing party, during which the trust agents located in the issuing domain and the trust domain communicate through a trust intermediary; Figure 8 is the call flow diagram describing the proof of possession challenge verified by the relying party, in which the trust agent is located in the publishing domain. The trust agents of the domain and the trust domain communicate through a trust intermediary.

detailed description

Generally speaking, devices that can be constructed or related to the present invention include various data processing technologies. Thus, as a background, before describing the present invention in more detail, a typical organization of hardware and software components within a distributed data processing system is explained.

Referring now to the drawings, Figure 1 depicts a typical network of data processing systems, each of which can implement the present invention. The distributed data processing system 100 includes a network 101, and the network 101 is a medium that can be used to provide communication links between various devices and computers connected together in the distributed data processing system 100. The network 101 may include permanent connections such as wired or optical cables, or temporary connections generated through telephone or wireless communication. In the described example, the server 102 and the server 103 are connected to the network 101 along with the storage unit 104. In addition, clients 105-107 are also connected to the network 101. The clients 105-107 and the servers 102-103 may be represented by various computing devices, such as mainframes, personal computers, personal digital assistants (PDAs), and so on. The distributed data processing system 100 may include additional servers, clients, routers, other devices, and peer-to-peer structures not shown.

In the described example, the distributed data processing system 100 may include the Internet with the network 101, which represents the use of various protocols, such as LDAP (Lightweight Direct Access Protocol), TCP/IP (Transmission Control Protocol/Internet Protocol), HTTP ( Hypertext Transfer Protocol), a global collection of networks and gateways that communicate with each other. Of course, the distributed data processing system 100 may also include many different types of networks, such as an intranet, a local area network (LAN), or a wide area network (WAN). For example, the server 102 directly supports the client 109 and the network 110, and the network 110 includes a wireless communication link. The telephone 111 supporting the network is connected to the network 110 through the wireless link 112, and the PDA 113 is connected to the network 110 through the wireless link 114. The telephone 110 and the PDA 113 can also use appropriate technologies, such as BluetoothTM wireless technology, to directly transmit data between them through the wireless link 115, creating a so-called personal area network or personal ad-hoc network. In the same way, the PDA 113 can transmit data to the PDA 107 via the wireless communication link 116.

The present invention can also be implemented in various hardware platforms and software environments. FIG. 1A is used as an example of different types of computing environments, and is not a limitation to the structure of the present invention.

Referring now to FIG. 1B, FIG. 1B depicts a typical computer structure in which the data processing system of the present invention can be implemented as shown in FIG. 1A. The data processing system 120 includes one or more central processing units (CPU) 122 connected to an internal system bus 123, which interconnects a random access memory (RAM) 124, a read-only memory 126, and an input/output adapter 128, The input/output adapter 128 supports various I/O devices, such as a printer 130, a disk unit 132, or other devices not shown, such as an audio output system. The system bus 123 is also connected to a communication adapter 134 that provides access to the communication link 136. The user interface adapter 148 is connected to various user devices, such as a keyboard 140 and a mouse 142, or other devices not shown, such as a touch screen, a stylus, a microphone, and the like. The display adapter 144 connects the system bus 123 and the display device 146.

Those of ordinary skill in the art will recognize that the hardware of FIG. 1B may vary according to system implementation. For example, the system may have one or more processors, such as an Intel(R) Pentium(R) processor and a digital signal processor (DSP), and one or more volatile and non-volatile memories. In addition to the hardware described in FIG. 1B, or instead of the hardware described in FIG. 1B, other peripherals may be used. The described examples are not meant to limit the structure of the present invention.

In addition to being able to be implemented on various hardware platforms, the present invention can also be implemented in various software environments. A typical operating system can be used to control the execution of programs in each data processing system. For example, one device may run the Unix(R) operating system, while another device may include a simple Java(R) runtime environment. A typical computer platform may include a browser, which is well known for accessing hypertext files in various formats, such as graphics files, word processing files, Extensible Markup Language (XML), Hypertext Markup Language (HTML), handheld The application software of the document type device markup language (HDML), wireless markup language (WML), and various other formats and types. It should also be noted that the distributed data processing system shown in FIG. 1A is expected to be fully capable of supporting various peer-to-peer subnets and peer-to-peer services.

Referring now to Figure 1C, the data flow diagram illustrates a typical authentication process that can be used when a client attempts to access a protected resource located on the server. As shown in the figure, a user located at the client workstation 150 attempts to access the protected resource located on the server 151 through a computer network through the user's Web browser executing on the client workstation. Protected resources are identified by a uniform resource locator (URL), or more generally, a uniform resource identifier (URI), that can only be accessed by authenticated and approved users. The computer network may be the Internet, an intranet, or other networks, as shown in FIG. 1A or FIG. 1B, and the server may be a Web Application Server (WAS), a server application, a Servlet process, and so on.

When a user requests a protected resource, such as a Web page in the domain "ibm.com" (step 152), the process is started. The web browser (or related application or applet) generates an HTTP request message, and the HTTP request message is sent to the web server of the resident domain "ibm.com" (step 153). The server determines that it does not have a current session with the client (step 154), so the server sends a certain type of verification challenge to the client, asking the user to perform the verification process (step 155). The verification query can be in various formats, such as Hypertext Markup Language (HTML). The user then provides the requested or requested information (step 156), such as a user identifier and related password, or the client can automatically return certain information.

The verification response information is sent to the server (step 157). At this time, the server verifies the user or client by retrieving the previously submitted registration information and matching the provided verification information with the saved information of the user (step 158). Assuming that the authentication is successful, an active session is established for the authenticated user or client.

The server then retrieves the requested Web page and sends an HTTP response message to the client (step 159). At this time, by clicking on the hypertext link, the user can request another page in "ibm.com" in the browser (step 160), and the browser sends another HTTP request to the server (step 161). At this time, the server recognizes that the user has an active session (step 162), and the server sends the requested Web page back to the client in another HTTP response message (step 163). Although Figure 1C depicts a typical existing process, it should be noted that other alternative session state management techniques can be described, such as the use of cookies to identify users with current sessions, which may include the same use of cookies as those used to provide verification evidence. Cookies.

Referring now to Figure 1D, the network diagram illustrates a typical Web environment in which the present invention can 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 in the DNS domain 173 or the web application server 174 in the DNS domain 175.

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

In this example, when the client 171 makes a request for a protected resource located in the domain 173, the web application server 172 determines that it does not have an active session with the client 171, and it requests the authentication server 176 to perform the appropriate actions for the client 171. Verify operation. The verification server 176 transmits the result of the verification operation to the web application server 172. If the user (or the browser 170 or the client 171 on behalf of the user) is successfully authenticated, the web application server 172 establishes a session with the client 171 and returns the requested protected resource. Generally speaking, once the user is authenticated by the authentication server, a cookie can be determined and stored in the browser's cookie cache. FIG. 1D is just an example of a way in which processing resources of a domain can be shared among multiple servers, especially in order to perform verification operations.

In a similar manner, after the client 171 sends a request for the protected resources of the domain 175, the authentication server 177 performs the proper authentication operation on the client 171, after which the web application server 174 establishes a session with the client 171, and Returns the requested protected resource. Thus, FIG. 1D illustrates that the client 171 may have multiple concurrent sessions in different domains, but in order to establish these concurrent sessions, multiple verification operations need to be completed.

Referring now to FIG. 1E, a block diagram depicts an example of a typical online transaction that requires multiple verification operations from the user. Referring again to Figure 1C and Figure 1D, before gaining access to the controlled resource, the user is required to complete a verification operation, as shown in Figure 1C. Although not shown in FIG. 1C, the authentication management program may be deployed on the server 151 to retrieve and use user information required to authenticate the user. As shown in FIG. 1D, the user may have multiple current sessions in different domains 173 and 175, although not shown in FIG. 1D, instead of or in addition to the authentication server, each domain may employ an authentication management program. In a similar manner, Figure 1E also describes a set of domains, each of which can support a certain type of verification management program. Figure 1E illustrates some of the problems that users may encounter when accessing multiple domains that require verification operations for each domain.

The user 190 may register with the ISP domain 191, and the domain 191 may support the verification management program 192 for verifying the user in order to complete the transaction with the domain 191. The ISP domain 191 may be an Internet service provider (ISP) that provides Internet connection services, e-mail services, and possibly other e-commerce services. On the other hand, the ISP domain 191 may be an Internet portal frequently accessed by the user 190.

Similarly, domains 193, 195, and 197 represent typical web service providers. The government domain 193 supports verifying users in order to complete various government-related transactions verification management procedures 194. The banking domain 195 supports a verification management program 196 for verifying users in order to complete transactions with online banks. The e-commerce domain 197 supports verifying users in order to complete the verification management program 198 for online purchases.

As mentioned earlier, when a user attempts to transfer from one domain to another within the Internet or World Wide Web by accessing resources located in different domains, the user will experience multiple user verification requests or requirements. Requirements can significantly slow down the user's process of crossing a set of domains. Using the environment of Figure 1E as an example, the user 190 may be involved in a complex online transaction with the e-commerce domain 197, where the user attempts to purchase online services limited to users who are at least 18 years old and have a legal drivers license, a valid credit card, and a U.S. bank account . The online transaction may involve domains 191, 193, 195, and 197.

Generally speaking, users do not maintain their identity in every domain participating in a particular online transaction. In this example, the user 190 may have registered his or her identity with the user's ISP, but in order to complete the online transaction, the user needs to verify with the domains 193, 195, and 197. If each domain does not maintain the user's identity, then the user's online transaction will fail. Even if the user can be verified by each domain, there is no guarantee that different domains can transfer information between them in order to complete the user's transaction. For the user 190 shown in FIG. 1E, there is no permission for the user 190 to authenticate to the first web site, such as ISP 191, and then transmit authentication tokens to other web service providers, such as domains 193, 195, and 197, in order to achieve Existing environment for single sign-on.

Under the previous brief description of the current technology, the description of the remaining drawings relates to a joint computer environment in which the present invention can work. However, before discussing the present invention in more detail, some terminology will be introduced.

The term "entity" or "participant" generally refers to an organization, individual, or system that works on behalf of an organization, individual, or another system. The term "domain" implies other characteristics in the network environment, but the terms "entity", "participant" and "domain" can be used interchangeably. For example, the term "domain" may refer to a DNS (Domain Name System) domain, or, more generally, a data processing system that includes various devices and applications that behave as logical units of external entities.

The terms "request" and "response" should be understood to include data formatting suitable for the information transfer involved in a specific operation, such as messages, communication protocol information or other related information. Protected resources are resources for which access is controlled or restricted (applications, target programs, documents, pages, files, executable codes or other computing resources, communication resources, etc.).

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

A statement provides indirect evidence of an action. A statement may provide indirect evidence of identity, verification, attributes, authorization decisions, or other information and/or operations. The verification statement provides indirect evidence of verification by an entity that is not a verification service party but obeys the verification service party.

A security statement markup language (SAML) statement is an example of a statement format that can be used within the present invention. SAML is issued by the Organization for the Advancement of Structured Information Standards (OASIS), which is a non-profit global association. In "Assertions and Protocol for the OASIS SecurityAssertion Markup Language(SAML)", Committee SAML is described in Specification 01, 05/31/2002 as follows: Security Assertion Markup Language (SAML) is an XML structure for exchanging security information. The security information is expressed in the form of a statement on the subject, which is an entity (person or computer) with an identity in a certain security domain. A typical example of a subject is a person identified by his or her email address in a particular Internet DNS domain. The statement can convey information related to the verification behavior performed by the theme, the attributes of the theme, and the verification decision whether the theme is allowed to access certain resources. The statement can be expressed as an XML structure and has a nested structure, so that a single statement can contain several different internal statements about authentication, authorization, and attributes. Note that the statement containing the verification statement only describes the verification behavior that occurred previously. The statement is issued by the SAML management agency, that is, the verification management agency, the attribute management agency, and the policy decision point. SAML defines a protocol by which the client can request a statement from the SAML management organization and get a response from the SAML management organization. This protocol composed of XML request and response message formats can be bound to many different underlying communication and transport protocols; SAML currently defines a binding to SOAP over HTTP. SAML management agencies can use various information sources, such as external policy repositories and statements received as input in requests to generate their responses. Thus, although the client always consumes claims, the SAM management agency is both the producer and consumer of the claims.

The SAML specification stipulates that a statement is an information package that provides one or more statements made by the publisher. SAML allows publishers to generate three different claims statements: verification, in which a specified subject is verified by a specific means at a specific time; authorization, in which a request to allow a specified subject to access a specified resource is approved or denied; and attributes, in which a specified subject and provided Properties are linked. As described further below, various declaration formats can be converted to other declaration formats when needed.

Authentication is the process of confirming a set of credentials provided by a user or on behalf of the user. By verifying something that the user knows, something the user has or the user is someone, that is, some physical characteristics of the user, the verification is completed. Something that the user knows may include a shared secret, such as the user's password, or verification of something that only a specific user knows, such as the user's encryption key, to complete the verification of something the user knows. Something the user owns can include smart cards or hardware tokens. Some physical characteristics about the user may include biometric inputs, such as fingerprints or retinal diagrams.

Authentication credentials are a set of challenge/response information used in various authentication protocols. For example, the combination of user name and password is the most common form of authentication credential. Other forms of verification credentials can include various forms of challenge/response information, public key infrastructure (PKI) certificates, smart cards, biometrics, and so on. The verification certificate is different from the verification statement: the verification certificate is presented by the user as part of the verification protocol sequence with the help of the verification server or service, and the verification statement is a statement about the successful provision and confirmation of the user's verification certificate. Transfer between entities.

Distinguishing the existing single sign-on solution As described above, the existing single sign-on solution is limited to the same kind of environment in which there are predetermined commercial agreements between participating companies. These commercial agreements establish trust and define the secure transfer of information between enterprises. These commercial agreements also include technical agreements on how to transform or map user identities from one enterprise to another, and how to transfer information used to guarantee users between participating enterprises.

In other words, the previous single sign-on solution allowed to trust the verification statement (and the user's identity provided in the statement) generated by different companies based on a pre-arranged or pre-set agreement. Each distinct business knows how to generate and explain verification statements that can be understood by other businesses that have exchanged similar agreements, such as businesses in the e-commerce market. These homogeneous environments are closely integrated because there are certain relationships known to the enterprise that are used to map user identities between these systems. This close integration is possible due to the commercial agreement used to establish a single registration environment.

In the context of the World Wide Web, the consortium model of the present invention gradually expects to have the ability to jump from interacting with applications in one Internet domain to interacting with another domain with little consideration of the information barrier between specific domains. 1. The ability of application interaction. Users do not want the frustration of having to verify to multiple domains for a single transaction. In other words, users expect that organizations should collaborate, but users usually expect domains to respect their privacy. In addition, users would rather restrict the domains where private information is permanently stored. These user expectations exist in the rapidly evolving heterogeneous environment in which many companies and organizations are releasing competitive verification technologies.

Contrary to the existing system, the present invention provides a consortium model to allow enterprises to provide users with a single registration experience in the absence of specific and predetermined business and technical agreements between specific enterprises. In other words, the present invention supports joint heterogeneous environments. As an example of the purpose of the present invention, referring again to FIG. 1E, the user 190 is able to authenticate to the domain 191 and then cause the domain 191 to provide an appropriate statement to each downstream domain involved in the transaction. These downstream domains need to be able to understand and trust verification claims and/or other types of claims, even if there is no predetermined claim format between the domain 191 and these other downstream domains. In addition to the identification statement, the downstream domain needs to be able to convert the identity contained in the statement into an identity representing the user 190 in a specific domain, even if there is no predetermined identity mapping relationship.

The present invention targets the consortium environment. Generally, an enterprise has its own user registry and maintains a relationship with its own set of users. Each enterprise generally has its own means of authenticating these users. However, the consortium scheme of the present invention allows enterprises to collaborate collectively, so that through the participation of enterprises in the consortium, users in one enterprise can influence the relationship with a group of enterprises. Users can be permitted to access resources located in any consortium enterprise, as if the user has a direct relationship with each enterprise. There is no need for users to register with every company they care about, and no need for users to constantly identify and verify themselves. Thus, in a consortium environment, the verification scheme creates conditions for a single sign-on experience in a rapidly developing heterogeneous environment in information technology.

In the present invention, a consortium is a group of different entities, such as enterprises, organizations, associations, etc., that cooperate to provide users with a single registration and easy-to-use experience. In the present invention, the consortium environment is different from the typical single-registration environment, because the two companies do not have to have a direct, predetermined relationship that defines how to transmit and which information related to the user is transmitted. In a consortium environment, entities provide services that deal with verifying users, accepting verification statements provided by other entities, such as verification tokens, and providing a form of guaranteed user identity to users who are known in the local entity. Conversion.

The consortium reduces the burden on service providers. The service provider can rely on its trust relationship with the consortium as a whole; the service provider does not need to manage authentication information such as user password information, because it can rely on the authentication completed by the user's authentication domain.

The present invention also relates to a federated identity management system, which establishes a basis for loosely-combined authentication, user registration, user profile management and/or authorization services across security domains. Federated identity management allows services residing in different domains to safely collaborate and cooperate, even if there are differences in the underlying security mechanisms and operating system platforms of these different domains. Once users determine their participation in the consortium, then the single sign-on experience is determined.

The main domain, issuer, and relying party are described in more detail below, and the present invention provides significant user benefits. The present invention allows a user to be authenticated in a first entity, which is referred to as the user's main domain or verification main domain in the following. The first entity can act as the issuer and issue a verification statement about the user for use at the second entity. Without the need to explicitly verify with the second entity, by providing a verification statement issued by the first entity, the user can access protected resources located on a different second entity (referred to as a relying party). The information transmitted from the issuing party to the relying party takes the form of a statement, which can contain different types of information in the form of a statement. For example, the statement may be a statement about the verified identity of the user, or may be a statement about user attribute information associated with a specific user.

Now referring to FIG. 2A, the block diagram describes the terminology of the consortium environment with respect to the transaction initiated by the user with respect to the first consortium. In response, the first consortium invokes operations on downstream entities in the consortium environment. Figure 2A shows that for a specified joint operation, the terminology will vary according to the perspective of the entities in the joint. The user 202 initiates a transaction by requesting a protected resource of the enterprise 204. If the user 202 has been authenticated by the enterprise 204, then for the joint session, the enterprise 204 is the user's primary domain. Assuming that the transaction requires a certain type of operation of the enterprise 206, and the enterprise 204 transmits a statement to the enterprise 206, the enterprise 204 is the issuing domain of the specific operation, and the enterprise 206 is the trust domain of the operation. Assuming that the transaction requires other operations, and the enterprise 206 transmits a statement to the enterprise 208, the enterprise 206 is the issuing domain of the requested operation, and the enterprise 208 is the trust domain of the operation.

In the consortium environment of the present invention, the domain where the user is authenticated is called the user's (verification) primary domain. The primary domain maintains authentication credentials. The main domain can be the user's employer, the user's ISP or some other service provider. There may be multiple companies that can fully use the user's home domain in the consortium environment, because there may be multiple companies that have the ability to generate and confirm the user's authentication credentials.

From a verification point of view, the issuing party of the verification statement is generally the user's verification primary domain. The user's main domain may or may not keep the user's personal information or profile information. Therefore, from the perspective of attributes related to personally identifiable information, personalized information, or other user attributes, the issuer of the attribute statement may or may not be the user's main verification domain. In order to avoid any confusion, different terms can be used for the attribute main domain and the verification main domain, but the term "main domain" below can be interpreted as referring to the verification main domain.

However, within the scope of a specified joint session, there is usually one and only one domain that serves as the user's primary domain. Once the user has confirmed himself to the domain, all other domains or enterprises in the consortium are considered as relying parties for the duration of the session.

It is assumed that the present invention provides a joint structure that can be added to the existing system while minimizing the impact on the existing non-joint structure. Since the main domain can also participate in the joint environment, it will not change the user Verification of the main domain. In other words, even if the main domain is incorporated into the consortium environment implemented according to the present invention, the user will have the same end user experience when the user's main domain performs a verification operation. However, it should be noted that not all users of a designated enterprise must participate in the consortium environment.

In addition, since the main domain can also participate in the consortium environment, user registration, such as the establishment of a user account, will not be changed. The user establishes an account in a certain domain through a registration process that has nothing to do with the consortium environment. In other words, the establishment of a user account in the main domain does not include account information valid in the consortium, such as the determination of identity conversion information. If there is a single federated domain that can verify users, that is, the domain to which there is and only one user registered in the federation, then this domain will always act as the user's primary domain and guide the movement of users in the entire federation environment.

If the user has multiple possible primary domains in the consortium environment, the user can enter the consortium through more than one entry point. In other words, users can have accounts in multiple domains, and these domains do not have to have information about other domains, nor do they have to have information about the user's identity in other domains.

When the domain where the user is authenticated is called the primary domain, the issuing domain is a consortium entity that issues claims for use by another domain, that is, the trusted domain. The publishing domain is generally (but not necessary) the user's primary domain. Thus, it is usually the case that the issuer has authenticated the user through a typical authentication protocol, as described above. However, the issuer may previously act as a relying party so that it receives claims from different issuers. In other words, since user-initiated transactions can pass through a series of companies in the consortium environment, the receiver can then act as the issuer of downstream transactions. In general, any domain that has the ability to issue verification statements on behalf of users can serve as a publishing domain.

A trusted domain is a domain that receives claims from the issuer. The trusted domain can accept, trust and understand the third party on behalf of the user, that is, the statement issued by the domain. The task of the relying party is generally to use the appropriate verification agency to interpret the verification statement. In addition, the relying party may be able to authenticate a specific user, that is, acting as the user's primary domain, but the relying party may not be able to authenticate the specific user with conventional methods. Thus, the relying party relies on the authentication statement provided by the user to provide the user with a single sign-on experience, rather than prompting the user's domain or enterprise regarding the user's authentication credentials as part of an interactive session with the user.

Consortium system structure-the joint front end of the old system Referring now to FIG. 2B, a block diagram depicts the combination of an existing system of a designated domain and some consortium system structural components of the present invention according to an embodiment of the present invention. The consortium environment includes federated entities that provide various services to users. The user 212 interacts with the client device 214, and the client device 214 can support the browser application 216 and various other client applications 218. User 212 is distinct from client device 214, browser 216, or any other software that acts as an interface between the user and other devices and services. In some cases, the following description can distinguish between a user acting in a client application and a client application acting on behalf of the user. However, generally speaking, the requester is an intermediary who can be assumed to act on behalf of the user, such as client applications, browsers, SOPA clients, and so on.

The browser application 216 may be a typical browser including many modules, such as an HTTP communication component 220 and a markup language (ML) interpreter. The browser application may also support plug-ins that may or may not require a virtual machine runtime environment, such as a web service client program 224, and/or downloadable support programs. The web service client 224 may use Simple Object Access Protocol (SOAP), which is a lightweight protocol that defines the exchange of structured and typed information in a decentralized distributed environment. SOAP is an XML-based protocol consisting of three parts: an envelope that defines a framework that describes the content in a message and how to process the content; a set of encoding rules that express an instance of the data type defined by the application; and a representative remote The procedure call and response agreement. The user 212 can use the browser application 216 to access web-based services, but the user 212 can also access web services through other web service client applications on the client device 214. Some examples of the present invention shown in the following figures use the user's browser to exchange information between entities in the consortium environment using HTTP redirection. However, it should be noted that the present invention can also be implemented through various communication protocols, and the present invention is not meant to be limited to HTTP-based communication. For example, when needed, entities in the consortium environment can communicate directly; messages do not need to be redirected through the user's browser.

The present invention can be implemented in a way that the components required by the consortium environment are combined with the existing system. Figure 2B depicts an embodiment of implementing these components as the front end of an existing system. The existing components of the federated domain can be regarded as old applications or back-end processing components 230, which include an authentication service runtime (ASR) server 232 similar to that shown in FIG. 2C. When the domain controls access to the application server 234, the ASR server 232 is responsible for authenticating users, and access to the application 234 can be considered as generating, retrieving, or otherwise processing protected resources. The domain can continue to use the old user registration application 236 to register users for access to the application server 234. The information required to authenticate the registered user is stored in the old user registry 238.

After joining the consortium environment, the domain can continue to operate without interference from the consortium components. In other words, the domain can be configured to enable users to continue to directly access specific application servers or protected resources without having to go through the point of contact server or other components that implement the functionality of the point of contact server; access the system in this way Of users will go through a typical verification process and a typical visit. However, in this process, users who directly access the old system cannot establish a joint session known to the domain's point of contact server.

By using the joint front-end processing 240, the original functions of the domain can be incorporated into the consortium environment. The joint front-end processing 240 includes the point of contact server 242 and the trust proxy server 244 (or more simply, the trust proxy 244), and the trust proxy 244 itself A security token service (STS) 245 is included, all of which will be explained in more detail below with reference to FIG. 2C. The federation configuration application 246 allows management users to configure federated front-end components, thereby allowing them to interact with the original back-end components through the federated interface unit 248.

The original or existing authentication service located in the designated enterprise can use various well-known authentication methods or tokens, such as user name/password or smart card token information. However, as far as the present invention is concerned, through the use of the point of contact server, the functionality of the original verification service can be used in the consortium environment. Users can continue to directly access the original authentication server without going through the point of contact server. However, users who access the system in this way will experience typical authentication procedures and typical visits; users who directly access the original authentication system will not be able to Invention, a joint verification statement as proof of identity. One of the tasks of the joint front-end is to convert the joint verification token received at the point of contact server into a format understood by the original verification service. Therefore, it is unnecessary to require users who access the consortium environment through the point of contact server to re-authenticate to the original authentication service. Preferably, the combination of the point of contact server and the trust agent can be used to authenticate the user to the original authentication service, so that it appears that the user is participating in the authentication session.

Consortium system structure-contact point server, trust agent and trust intermediary (broker) Now referring to FIG. 2C, according to the implementation of the present invention, a block diagram describes the consortium system structure. The consortium environment includes conglomerates or similar entities that provide various services to users. Through the application on the client device, the user can try to access resources located in different entities, such as the enterprise 250. The point of contact server located in each joint enterprise, for example, the point of contact (POC) server 252 located in the enterprise 250 is the entry point for the user to enter the joint environment. The point of contact server minimizes the impact on the existing components within the existing non-community system structure, because the point of contact server handles many consortium requirements. The point of contact server provides session management, protocol conversion, and may also initiate verification statement conversion. For example, the point of contact server can convert HTTP or HTTPS messages into SOAP, and vice versa. As described in more detail below, the point of contact server can also be used to call a trust proxy to convert the verification statement. For example, the SAML token received from the issuer can be converted into a Kerberos token that the receiver understands.

A trust proxy or trust proxy server, such as a trust proxy (TP) 254 located in the enterprise 250, establishes and maintains a trust relationship between two entities in the consortium. The trust agent generally has the ability to convert the authentication token format from the format used by the issuer to the format understood by the receiver (through the security token service described in more detail below).

At the same time, the use of point-of-contact servers and trust agents minimizes the impact of the realization of the consortium system structure on the existing set of non-combined systems. Therefore, the consortium system structure of the present invention requires each federated entity to implement at least one point of contact server and at least one trust agent, regardless of whether the entity is an enterprise, a domain, or other logical or physical entities. However, the consortium system structure of the present invention does not require any changes to the existing set of non-consortium systems. Preferably, there is a single trust agent for the designated joint entity, but for usability purposes, there may be multiple trust agents, or for each smaller entity in the joint entity, such as an independent subsidiary in a company, there may be Multiple trusted agents. The specified entity may belong to more than one consortium, but in this case, multiple trust agents are not necessary, because a single trust agent can manage the trust relationships in multiple consortiums.

One task of the trust agent is to determine the type of token required by another domain and/or trust agents in that domain. The trust agent has the ability to process the verification token format conversion from the format used by the issuer to the format understood by the receiver. The trust agent 254 is also responsible for any user identity conversion or attribute conversion that occurs with respect to the enterprise 250. However, the trust agent can request help from the trust intermediary, as described below. In order to transform the user identities and attributes known by the issuer into user identities and attributes that are meaningful to the receiver, identity conversion is required. This conversion can be invoked by a trust agent located in the issuing domain or by a trust agent located in the receiving domain.

The trust agent 254 may include an internalized component, denoted as a security token service (STS) component 255, which provides token conversion, and calls an authentication service runtime (ASR) 256 to confirm and generate tokens. The security token service provides the token instance and the confirmation service required by the trust agent. Therefore, the security token service includes an interface relative to the running time of the existing authentication service, or it incorporates the running time of the authentication service into its own service. Instead of being part of the trust agent, the security token service component can also be implemented as an independent component called by the trust agent, or it can be part of the transaction server, for example as part of the application server.

For example, the STS component can receive a request for an unreasonable Kerberos token. As part of the authentication information of the user for whom the token will be generated, the request may include a binary token, which contains the user's name and password. The STS component will confirm the user's name and password according to, for example, the LDAP runtime (typical authentication), and call the Kerberos KDC (Key Distribution Center) to generate the user's Kerberos ticket. The token is returned to the trust agent for use within the enterprise; however, such use may include the materialization of the token for transmission to another domain in the consortium.

In a manner similar to that described with reference to FIG. 1D, the user may wish to access the resources of multiple enterprises, such as enterprise 250 and enterprise 260, located in a complex environment. In a similar manner as described above with respect to the enterprise 250, the enterprise 260 includes a point of contact server 262, a trust agent 264, a security token service 265, and a verification service runtime 266. Although the user can directly initiate a separate transaction with each enterprise, the user can initiate a transaction with the enterprise 250, which is connected in series through the consortium environment. The enterprise 250 needs to collaborate with multiple other enterprises in the consortium environment, such as the enterprise 260, in order to complete a specific transaction, even if the user does not know the necessity when the user initiates the transaction. The enterprise 260 becomes a downstream domain, and the present invention allows the enterprise 250 to provide the enterprise 260 with a joint statement (if required) in order to continue the user's transaction.

It may also be that the trust agent does not know how to interpret the verification token received by the relevant point of contact server and/or how to transform the identity and attributes of the specified user. In this case, the trust agent must choose to call the function of the trust intermediary component, such as the trust intermediary 268. The trust intermediary maintains a relationship with each trust agent, so as to provide transferable trust between the trust agents. Using a trust intermediary allows each entity in the consortium environment, such as enterprises 250 and 260, to establish a trust relationship with the trust intermediary, instead of establishing multiple individual trust relationships with each domain in the consortium environment. For example, when the enterprise 260 becomes the downstream domain of a transaction initiated by the user in the enterprise 250, the trust agent 254 located in the enterprise 250 can ensure that by requesting the help of the trust intermediary 268 (if needed), the trust agent 264 located in the enterprise 260 can understand from Trust agent 254's statement. Although FIG. 2C depicts a consortium environment with a single trust intermediary, a consortium environment may have multiple trust intermediaries.

It should be noted that although FIG. 2C depicts the point of contact server 252, the trust agent 254, the security token service component 255, and the authentication service runtime 256 as different entities, it is not necessary to implement these components on separate devices. For example, the functions of these independent components can be implemented as applications located on a single physical device, or combined in a single application. In addition, Figure 2C depicts a single point of contact server, a single trust agent, and a single security token server for an enterprise, but an alternative structure may include multiple point of contact servers, multiple trust agents, and multiple Security token server. The point of contact server, trust agent, security token service, and other joint entities can be realized in different forms, such as software applications, target programs, modules, software libraries, etc.

Trust agents/STS can accept and confirm many different authentication credentials, including traditional credentials such as user name and password combinations and Kerberos tickets, and joint verification token formats, including those generated by third parties. The trusted agent/STS allows the verification token to be accepted elsewhere in the form of verification evidence. The verification token is generated by the issuer and is used to indicate that the user has been authenticated to the issuer. The issuer generates a verification token as a means of proclaiming the verified user's identity.

The security token service calls the running time of the verification service as needed. Authentication service runtime supports authentication services that can authenticate users. The verification service acts as a verification agency that indicates the success or failure of verification attempts by means of verification responses. The trust agent/STS can make the authentication service a part of itself, for example, where there is a new installation of a web service that does not need to interact with the existing original infrastructure. In addition, the STS component will call an external verification service to confirm the verification token. For example, the STS component can "open" the binary token containing the user's name/password, and then use the LDAP service to access the user registry to confirm the submitted credentials.

When used by another component such as an application server, the STS component can be used to generate the token required for single registration with the original verification system. Therefore, the STS component can be used for internal token conversion, that is, token conversion within an enterprise, and for external token conversion, that is, token conversion between enterprises in a consortium. As an example of internal token conversion, the web application server can communicate with the host through the IBM CICS (Customer Information Control System) transaction gateway; CICS is a set of applications that provides enterprise-level online transaction management and connectivity for mission-critical applications Program server and connector. The web application server can call the STS component to convert the Kerberos ticket (used internally by the web application server) into the IBM RACF(R) pass required by the CICS transaction gateway.

The terms introduced above, such as "issuer" and "relying party" can be used to describe the entity shown in Figure 2C. As part of determining and maintaining the trust relationship, the issuing party's trust agent can determine which tokens the relying party's trust agent needs/accepts. Thus, when the token service is invoked from the security token service, the trust agent uses this information. When the trust agent of the publishing domain is required to generate a verification statement for the relying party, the trust agent determines the required token type and requests the appropriate token from the security token service.

When the trust agent of the trusting domain receives the verification statement from the issuing party, the trust agent knows what kind of declaration is expected and what kind of declaration is required for internal use in the trusting domain. The trust agent of the trust domain then requests the security token service to generate the required internal application token based on the token in the received verification statement.

Both the trust agent and the trust intermediary have the ability to convert the statement received from the issuing party into a format understood by the relying party. The trust intermediary has the ability to interpret the declaration format for each trust agent with which it has a direct trust relationship, thereby allowing the trust intermediary to provide declaration conversion between the issuer and the relying party. Any party can request this conversion through its local trusted agent. Thus, the issuing party's trusted agent can request the conversion of the statement before sending the statement to the relying party. Likewise, the trust agent of the relying party can request the conversion of the claims received from the issuing party.

The declaration conversion includes user identity conversion, verification declaration conversion, attribute declaration conversion, or other forms of declaration conversion. As mentioned earlier, the declaration conversion is handled by the trust components in the consortium, namely, trust agents and trust intermediaries. The trust agent can complete the conversion in the publishing domain or locally in the trust domain, or the trust agent can request help from the trust intermediary.

Assuming that the publisher and the relying party already have a separate trust relationship with the trust intermediary, then if necessary, the trust intermediary can be dynamically generated, that is, to broker a new trust relationship between the publisher and the relying party. After the initial trust relationship provided by the trust intermediary facilitates the operation, the issuing party and the relying party can directly maintain the relationship, so that the trust intermediary does not need to be invoked for future conversion requirements. It should be noted that the conversion of verification tokens can occur in three possible locations: the issuing party's trust agent, the relying party's trust agent, and the trust intermediary. Preferably, the trust agent of the issuing party generates a verification statement that the trust intermediary understands for sending to the relying party. The relying party then requests that this token from the trusted intermediary be converted into a format that the relying party can recognize. The token conversion can occur before the transmission, after the transmission, or before and after the transmission of the verification statement.

The trust relationship in the consortium system structure In the consortium environment implemented according to the present invention, there are two types of "trust domains" that must be managed: the enterprise trust domain and the consortium trust domain. The different parts between these two trust domains are based on the commercial agreements that manage the trust relationship with the trust domain and the technology used to establish trust. The enterprise trust domain contains those components managed by the enterprise; all components in the trust domain trust each other. Generally speaking, there is no commercial agreement required to establish trust within the enterprise, because the technology used generates the inherent trust within the enterprise through SSL sessions that require mutual authentication between components. Referring to Figure 2B, the original application and back-end processing system can represent the enterprise trust domain.

Consortium trust domains are those trust domains that cross enterprise boundaries; from a certain point of view, consortium trust domains can represent the trust relationship between completely different enterprise trust domains. Establish a consortium trust domain through trust agents that cross enterprise boundaries. The joint trust relationship may involve a certain kind of bootstrapping process, by means of which the initial trust is established between trust agents. Part of this bootstrapping process may include the determination of shared secret keys and the definition of expected and/or permitted token types and identifier conversion rules. Generally speaking, this kind of bootstrapping process is implemented out-of-band, because the process also includes the determination of the business agreement that manages the enterprise's participation in the consortium and the responsibilities related to such participation.

There are many mechanisms for establishing trust in the federated enterprise model. In the consortium model, for business reasons, the basic concept of trust between consortium participants is required in order to provide an effective guarantee level for the statements (including tokens and attribute information) transmitted between the participants. If there is no trust relationship, then the trusted domain cannot rely on claims received from the issuing domain; these claims cannot be used by the trusted domain to determine how to interpret any information received from the issuing party.

For example, if a large company wants to connect thousands of global customers, the company can use existing solutions. As a first example, the company can require global customers to use digital certificates from commercial certificate authorities to establish mutual trust. The commercial certification authority enables the company's servers to trust the servers located in various global customers. As a second example, the company can use Kerberos to achieve third-party trust; the company and its global customers can implement trusted third-party Kerberos domain services, which implement trust based on shared secrets. As a third example, the company can use a proprietary secure message token to establish a dedicated solution, and the servers of its customers worldwide trust the proprietary secure message token.

If a company needs to manage a trust relationship with a small number of global customers, then any of these methods is acceptable, but if there are hundreds or thousands of potential joint partners, it becomes difficult to manage. For example, although a company can force its smaller partners to implement dedicated methods, it is unlikely that the company will be able to impose many requirements on its larger partners.

With the present invention, enterprises will adopt trust relationships established and maintained through trust agents and possibly trust intermediaries. One advantage of the consortium system structure of the present invention is that it does not impose additional requirements beyond the current basic structure of the enterprise and its potential joint partners.

However, the present invention does not exempt enterprises and their potential joint partners from the preparatory work required to determine the business and liability agreements required to participate in the joint venture. In addition, participants cannot ignore the technical bootstrapping of trust relationships. The present invention allows this bootstrapping to be flexible. For example, the first syndication partner can issue a Kerberos ticket with certain information, and the second syndication partner can issue a SAML verification statement with certain information.

In the present invention, the trust relationship is managed by a consortium trust agent, and the consortium trust agent may include a security token service that confirms and converts the token received from the issuer according to the predetermined relationship between the two trust agents. In the case that a joint enterprise cannot establish a trust relationship (and token conversion) with another joint enterprise, a trust intermediary can be called. However, the conglomerate must still establish a relationship with a trusted intermediary.

Referring now to FIG. 2D, a block diagram depicts a set of exemplary trust relationships between federated domains using trust agents and trust intermediaries in accordance with the present invention. Although FIG. 2C introduces the trust intermediary, FIG. 2D illustrates the importance of the transitive trust relationship within the consortium system structure of the present invention.

Federation domains 271-273 contain trust agents 274-276, respectively. The trust agent 274 and the trust agent 275 have a direct trust relationship 277. The trust agent 280 and the trust agent 275 have a direct trust relationship 278, and the trust agent 280 and the trust agent 276 have a direct trust relationship 279. The trust intermediary 280 is used to represent a consortium participant and determine the trust relationship based on the transitive trust with other consortium partners. The principle of transitive trust allows the trust agent 275 and the trust agent 276 to have a facilitated trust relationship 281 through the trust intermediary 280. Neither trust agents 275 nor 276 need to know how to convert or confirm the other party's statement; the trust intermediary can be called to convert the statement into a valid, trusted, and clear statement at the other trusted agent.

By using the ebXML (Electronic Commerce Using XML) standard, XML can be used to express the trust relationship between conglomerates and stipulate contractual obligations and responsibilities of business agreements. For example, an ebXML document can be used to express a direct trust relationship; each federation domain that shares a direct trust relationship has a copy of the contract expressed as an ebXML document. The operational characteristics of each entity in the consortium can be specified in the ebXML orchestration design, and the operational characteristics can be published in the ebXML registry; any enterprise wishing to participate in a specific consortium, such as operating a trust agent or a trust intermediary, needs to comply with the specific consortium regarding the union The disclosure requirements stipulated by all trust agents or trust intermediaries in the body. The security token service can parse these ebXML documents with respect to operational details in a way that converts tokens from other domains. It should be noted, however, that the present invention may also adopt other standards and mechanisms to specify details related to the manner in which the trust relationship within the consortium is realized.

The declaration processing in the consortium system structure is as described above, the user experience in the consortium is controlled by the user-related declarations transmitted between domains. The statement provides information related to the user's verification status, attribute information, and other information. The use of a verification statement saves the user from having to re-verify at each site the user visits. In the consortium environment, there are two modes of obtaining a statement from the publisher to the relying party: push mode and drag mode. In the push mode, the user's statement and the user's request are sent to the publisher together. In the drag-and-drop mode, the relying party that does not have any message receives the user's request, and the relying party then requests related or required statements from the issuing party.

Knowing these modes of using claims in a consortium environment, the description of the invention now turns to a set of drawings describing a set of processes for generating and using claims in the consortium environment of the present invention. Figure 3A describes the general process of generating a statement in the consortium environment in the publishing domain, while Figure 3B describes the "tear-off" statement in the trust region, that is, by extracting and analyzing the information of the statement, the statement is restored to its original state. The general process of essential information. Figure 3C and Figure 3D describe two variants of the push mode, showing a more specific process of the general process shown in Figure 3A. In the push mode, a statement is generated in the publishing domain, and then the statement and the users request are sent to Trust region. Figure 3E depicts the drag mode, in which the trust domain requests any required claims about the user from the publishing domain, while attempting to satisfy the resource request received by the trust domain from the requesting user.

Now referring to Figure 3A, the flowchart describes the general process of generating a statement in the consortium environment in the publishing domain. When a point of contact server of the publishing domain is triggered about a certain announcement (step 302), the process starts. The point of contact server may receive a specific claim request for a specified user from a dependent domain, or it may intercept an output request of a known trusted domain that needs to be declared; these situations are described in more detail below with reference to FIGS. 3C and 3D, respectively. In response to a certain statement being triggered, the point of contact server of the publishing domain requests a statement from the trust agent of the publishing domain (step 304), and the trust agent of the publishing domain generates the statement (step 306); if necessary, the trust agent of the publishing domain can Ask the trusted intermediary for help to produce the required claims. After generating the statement, the trust agent of the issuing domain then returns the statement to the point of contact server of the issuing domain (step 308), and the point of contact server can then inject the statement into the output data stream in an appropriate manner (step 308). 310), for example, by inserting the statement into the output HTTP or SOAP message to complete the process.

Figure 3A describes the process of generating a statement in the publishing domain without using a "local wallet". However, the present invention allows the inclusion of local wallet functionality. Generally speaking, the local wallet is a client-side code that can serve as a confidential database of user attribute information or other information in order to simplify transactions; the client-side code can also participate in the push and/or drag mode of declaration transmission. When the local wallet actively participates in the protocol, it implements the point-of-contact server functionality regarding a subset of functions for generating and inserting statements into the protocol stream. Using the local wallet is not convenient for the local wallet to realize the trust-based interaction between the point of contact server and the trust agent. In cases where other trust relationships are required, the point of contact server must be called.

Now referring to Figure 3B, the flow chart describes the general process in the trust domain in order to tear down the statement. When the point of contact server of the trusted domain receives a message with a related claim (step 322), it starts the process, after which it extracts the claim and transmits it to the trust agent of the trusted domain (step 324). The trust agent of the trust domain extracts information from the statement, including the token received from the issuing domain (step 326); the trust agent of the trust domain will call the security token service to confirm the token, and if necessary, the users local valid token .

As part of step 326, the trust agent will determine the source of the claim, which is the issuer. If the trust agent can understand the trust statement received from the issuing domain, then the trust agent will proceed to step 328 internally. If the trust agent cannot understand/trust the claims received from the publishing domain, then the trust agent will ask the trust agent for help. If the statement cannot be confirmed, then an appropriate error response will be generated.

Assuming that the claim is confirmed, the trust agent of the trust domain determines the local information required by the user (step 330). For example, the local information may include authentication credentials required by the original back-end application. The trust agent of the trusted domain returns the required information to the point of contact server of the trusted domain (step 332), and the point of contact server can establish a local session of the user.

After the point of contact server establishes the user's session, the user appears as an authenticated user. The point of contact server can use the session information to continue to manage any transactions the user has with the domain until an exit or timeout event is initiated. Assuming that the point of contact server already has the authenticated identity of the user, then if necessary, the point of contact server can obtain authorization for the request based on the identity of the specific user and any authorization policies related to the specific user. The point of contact server then transmits the user's request and any related information to the requested back-end application or service (step 334), thereby completing the process.

It should be noted that the data items transmitted between the point of contact server and the trust agent and the format of these data items may vary. The point of contact server may forward the entire message to the trust agent, instead of extracting the statement from the message, and only forward the statement to the trust agent. For example, the processing at the trust agent may include steps similar to the signature verification of the SOAP message, which requires the entire SOAP envelope.

Now referring to Figure 3C, the flowchart describes the specific process of pushing the statement from the issuing domain to the trust domain in response to user operations in the issuing domain. When the user accesses the link of the trusted domain from a certain Web page or similar resource in the publishing domain (step 342), the process is started, thereby calling a certain form of CGI (Common Gateway Interface) to process and establish a specific statement. The ability of issuing domains to identify trust domains needs to be declared means close integration with the existing old system on which the consortium infrastructure of the present invention is implemented. It also means close integration between the issuing party and the relying party, so that the issuing party does not have to call a trust agent to establish the required statement; among certain types of joint entities with well-established trust relationships, this close integration is suitable.

Invoke the back-end processing located in the publishing domain to establish the required claims (step 344), which may include invoking functions located in the local trust agent. Subsequently, it is determined that the user's request for the trusted domain includes the required statement (step 346), and the issuing domain transmits the statement together with the user's request to the trusted domain (step 348), thereby completing the process. When the trusted domain receives the request and its related claims, the trusted domain can confirm the claims in the manner shown in FIG. 3B.

Now referring to Figure 3D, the flowchart describes the specific process of responding to the publishing domain to actively intercept the output request about the trust region, and pushing the statement from the publishing domain to the trust region. When the user requests a protected resource in the trusted domain (step 352), the process starts. The point of contact server filters the output messages through predetermined uniform resource identifiers (URI), certain types of messages, certain types of message content, or in other ways, and intercepts the output requests (step 354). The point of contact server of the publishing domain then requests the trust agent of the publishing domain to generate an appropriate statement (step 356). If necessary, the trust agent of the publishing domain generates the statement with the help from the trust intermediary (step 358). The publishing domain then transmits the user's request and the generated statement to the relying party (step 360), thereby completing the process. When the trusted domain receives the request and its related claims, the trusted domain confirms the claims in the manner shown in FIG. 3B.

Referring now to FIG. 3E, the flow chart describes the drag mode in which the trust domain requests any required claims about the user from the issuing domain while trying to satisfy the resource request received by the trust domain from the requesting user. When the trusted domain receives a user request for a protected resource (step 372), the process starts. In contrast to the example shown in FIG. 3C or FIG. 3D, the example shown in FIG. 3E describes the processing related to the user request received in the trusted domain in the absence of any required statements about the user. In this case, the publishing domain does not have the ability to intercept or process the user's request in order to insert the required statement into the user's request. For example, the user may have entered a uniform resource locator (URL) or used a bookmark index of the resource in such a way that the output request is not intercepted by the point of contact server of the publishing domain. Thus, the trusting domain requests a declaration from the issuing domain.

The trusted domain then determines the user's primary domain (step 374), that is, the relevant publishing domain. In an HTTP-based implementation, the user may have a predetermined relationship with the trust domain that causes the permanent cookie to be set by the trust domain located on the user's client device. The permanent cookie can contain the user's primary domain, which is the identity of the publishing domain. In the SOAP implementation in which the user manipulates the web service client program in a certain way, the web service in the trust domain has notified service requirements, including token requirements, through WSDL (Web Service Description Language). This will then require the user's web service client/SOPA implementation to provide the required token type. If this requirement is not met, then technically, the web service will return an error. In some cases, it can return an error code that allows the user to be prompted for the authentication information, so that the request for the appropriate token can be repeated.

The contact point server of the trusted domain initiates a declaration request by using the trust agent of the trust domain (step 376), and the trust agent of the trust domain requests a declaration about the user from the trust agent of the issuing domain (step 378). If the embodiment adopts HTTP-based communication, through the user's browser application, with the help of redirection, the contact server of the trust domain can transmit the declaration request from the trust agent of the trust domain to the trust agent of the publishing domain to the contact point of the publishing domain. Server, the point of contact server of the publishing domain forwards the claim request to the trust agent of the publishing domain.

If the embodiment adopts a SOAP-based implementation, the trust domain can return an error code to the user's web service client program. This error code allows the user's web service client program to prompt the user about the verification information. The web service client program then generates the requested token. The user's web service client program can directly call the trust agent, as long as the trust agent of the trust domain is notified in UDDI (Unified Description, Discovery, and Synthesis), allowing the user's web service client program to find the trust agent. Generally speaking, this situation is only valid for internal users. Trust agents are advertised in the private UDDI within the enterprise, because it is impossible to advertise trust agents on the Internet or in public UDDI that can be accessed outside the consortium.

The trust agent of the publishing domain generates the requested statement in a mirror manner to the manner of receiving the statement request (step 380), and then returns the requested statement (step 382). After the trust agent of the trusting domain receives the requested statement (step 384), the trust agent of the trusting domain extracts information from the statement (step 386), and attempts to interpret and/or confirm the statement (step 388); if necessary, the trust agent You can request help from a trusted intermediary to convert the claim. If the statement cannot be confirmed, then an appropriate error response will be generated. Assuming that the claim is confirmed, the trust agent of the trust domain determines the local information in the appropriate format required for use by the back-end service attempting to satisfy the user's request for the protected resource (step 390). For example, the local information may include authentication credentials required by the original back-end application. The trust agent of the trusted domain returns the required information to the point of contact server of the trusted domain (step 392). The point of contact server then establishes the user's local session and forwards the user's request and any related information to the requested post. End application or service (step 394), thereby completing the process.

Single Registration in the Consortium System Structure The description of FIGS. 2A-2D focuses on the operational characteristics of entities in the joint data processing environment according to the present invention, while the description of FIGS. 3A-3E focuses on some processes that occur between these entities. Contrary to these descriptions, the description of Figure 4 focuses on the goal of completing user transactions while providing users with a single sign-on experience.

In other words, the following description discusses the entities and processes discussed above, but the following description is more focused on the way in which the user can have a single sign-on experience within the user's session, an overview of the present invention. A session can be defined as a set of transactions from (including) initial user authentication, that is, login to logout. Within the session, the user's operations are partly controlled by the privileges approved to the user for the session. Within the consortium, users want to have a single sign-on experience, in which users complete a single verification operation, and within the duration of their session, the verification operation meets the needs, while the Consortium partners have nothing to do.

During the user's session, the user can visit multiple federated domains in order to use the web services provided by these domains. Domains can use standard specifications such as UDDI and WSDL to publish the description of the services they provide. Both UDDI and WSDL use XML as a common data format. Users find available services and service providers through applications that also comply with these standards and specifications. SOAP provides an example of delivering requests and responses expressed in XML. Entities within the consortium environment can adopt these standards and many others.

In order to simplify the single sign-on experience, web services that support the consortium environment also support the use of verification statements or security tokens generated by third parties to provide user verification evidence. This statement also contains certain types of evidence that the user has successfully authenticated to the issuer and the user's identifier. Thus, the user can provide a consortium partner with traditional authentication credentials, such as user name and password, and then provide a different consortium partner with a SAM verification statement generated by the verifier/issuer.

Authentication in the web service environment is to verify the self-proclaimed identity of the web service request, so that the enterprise can restrict access to authorized clients. The user requesting or invoking the web service should be verified almost all the time, so the verification requirements in the consortium environment of the present invention are not any different from the existing requirements for the web service for user verification. The consortium environment also allows web services or other applications to request web services, and these web services should also be verified.

The verification of users who have not participated in the joint session is not affected by the structure of the joint system of the present invention. For example, through HTTP/S, a form verification mechanism is used for verification, so that existing users who access non-federated resources located in a specific domain will not be affected by the introduction of support for the consortium environment in that domain. The verification part is handled by the point of contact server, and the point of contact server now calls an independent trust agent component. The use of point-of-contact servers minimizes the impact on the infrastructure of the existing domain. For example, the point of contact server can be configured to pass all non-federated requests that will be handled by backends or legacy applications and systems located in the domain.

The point of contact server can choose to call HTTP-based authentication methods, such as basic authentication, formal authentication or some other authentication methods. By identifying the statement provided by the user in the form of verification evidence, such as the SAML verification statement, the point of contact server also supports a federated trust domain, where the statement goes beyond the enterprise trust domain. The point of contact server can call the trust agent, and the trust agent then calls its security token service to confirm the verification certificate/security token.

The authentication of web services or other applications includes the same process as user authentication. The request from the web service carries a security token. The security token contains a verification statement. The security token should be confirmed by the trust agent/security token service in the same way as the token provided by the user. The request from the web service should always carry this token, because the web service should have discovered what kind of authentication statement/security token is required by the requested service as announced in UDDI.

Referring now to Figure 4, a block diagram depicts a consortium environment that supports joint single sign-on operations. Through a client device and an appropriate client application, such as a browser, the user 400 wishes to access the web service provided by the enterprise/domain 410, and the enterprise/domain 410 supports a data processing system that acts as a federated domain within a federated environment. The domain 410 supports the point of contact server 412 and the trust agent 412; similarly, the domain 420 supports the point of contact server 422 and the trust agent 424, and the domain 430 supports the point of contact server 432 and the trust agent 434. The trust agent relies on the help of the trust intermediary 450, as described above. Other domains and trust agents can participate in the consortium environment. Figure 4 describes the joint single sign-on operation between the domain 410 and the domain 420; similar operations can occur between the domain 410 and the domain 430.

The user completes the verification operation with respect to the domain 410; the verification operation is processed by the point of contact server 412. When a user requests access to certain resources that require a verified identity for the purpose of access control or for personalization purposes, the verification operation is triggered. The point of contact server 412 may call the original verification service, or may call the trust agent 414 to confirm the verification credentials provided by the user. During the duration of the user's joint session, the domain 410 becomes the user's primary domain.

Later, the user initiates a transaction with a consortium partner, such as an enterprise 420 that also supports a consortium domain, thereby triggering a joint single sign-on operation. For example, the user may start a new transaction in the domain 420, or the user's initial transaction may be cascaded into one or more other transactions in other domains. As another example, the user can use the point of contact server 412, for example, by selecting a special link on a web page residing in the domain 410, or by requesting to reside in the domain 410, but displaying the resources residing in the domain 420 The entry page of, invokes the joint single sign-on operation with respect to the resources in the domain 420. The point of contact server 412 sends a request to the trust agent 414 to generate a joint single sign-on token that is formatted into a user that can be understood or trusted by the domain 420. The trust agent 414 returns the token to the point of contact server 412, and the point of contact server 412 sends the token to the point of contact server 422 in the domain. The domain 410 acts as an issuer for users in the domain 420, and the domain 420 is a fully relying party. The users token will be sent to the domain 420 together with the users request; the token can be sent through the users browser via HTTP redirection, or the token can be sent by representing the user identified in the token provided by the trust agent 414, ( The request to directly call the contact point server 422 via HTTP or SOAP-over-HTTP) sends the token.

The point of contact server 422 receives the request and the united single sign-on token, and calls the trust agent 424. The trust agent 424 receives the united single registration token, confirms the token, and assumes that the token is valid and credible, and generates the user's local valid token. The trust agent 424 returns the local valid token to the point of contact server 422, and the point of contact server 422 establishes a session with the user in the domain 422. If necessary, the point of contact server 422 can initiate a joint single sign-on with another consortium partner.

The token confirmation in the domain 420 is handled by the trust agent 424, possibly with help from the security token service. Depending on the type of token provided by the domain 410, the security token service may need to access the user registry located in the domain 420. For example, the domain 420 may provide a binary security token containing the user name and password to be confirmed according to the user registry of the domain 420. Thus, in this example, the company simply confirms the security token from the consortium partner. The trust relationship between the domains 410 and 420 ensures that the domain 420 can understand and trust the security token provided by the domain 410 on behalf of the user.

Joint single registration not only needs to confirm the security token provided to the trust domain on behalf of the user, but also needs to determine the local valid user identifier of the trust domain based on the information contained in the security token. A result of the direct trust relationship and the commercial agreement required to establish this relationship is that at least one party, the publishing domain or the trusting domain, or both, knows how to convert the information provided by the publishing domain into an identifier that is valid in the dependent domain. In the short example above, it is assumed that the publishing domain, that is, the domain 410, can provide the trusted domain, that is, the domain 420, with a user identifier that is valid in the domain 420. In this case, the trust region does not need to call any identity mapping function. The trust agent 424 located in the domain 420 will generate a security token that "guarantees" the user for the user. As part of the commercial agreement of the consortium, the types of tokens accepted, the signatures required for tokens, and other requirements are pre-determined. The rules and algorithms governing the conversion of identifiers are also predetermined as a commercial agreement of the consortium. As far as the direct trust relationship between the two participants is concerned, the identifier conversion algorithm has been determined for the two parties, and the identifier algorithm has nothing to do with any other parties in the consortium.

However, the publishing domain does not always know how to convert the user from the local identifier of the domain 410 to the local identifier of the domain 420. In some cases, it may be that the trust domain knows how to complete this transformation, while in other cases, both parties do not know how to complete this transformation. In this case, a third-party trust intermediary needs to be called. In other words, as far as the promoted trust relationship is concerned, the publishing domain and the trust domain do not have a direct trust relationship with each other. However, they have a direct trust relationship with a trust intermediary, such as trust intermediary 450. Identifier mapping rules and algorithms are determined as part of the relationship, and the trust intermediary will use this information to help facilitate the conversion of the identifiers required by the trust relationship.

The domain 420 receives the token issued by the domain 410 at the point of contact server 422, and the point of contact server 422 calls the trust agent to confirm the token and perform identity mapping. In this case, since the trust agent 424 cannot convert the user from the local identifier of the domain 410 to the local identifier of the domain 420, the trust agent 424 calls the trust agent 450, and the trust agent 450 confirms the token and performs the identifier mapping. After obtaining the users local identifier, the trust agent 424 (perhaps through its security token service) can generate any local tokens required by the back-end application of the domain 420, for example to simplify the transfer from the point of contact service to the application server. Single sign-on requires Kerberos token. After obtaining the local valid token, if necessary, the point of contact server can establish the user's local session. The point of contact server also handles coarse-grained authorization of the user request and forwards the approved request to the appropriate application server in the domain 420.

When the user exits or stops the activity, the user's session is terminated. When a user logs out of a session with his main domain, the main domain will notify all trusted domains, that is, those domains to which the main domain has issued security tokens, and request the user to log out in these domains. If any of these trusted domains serves as the publishing domain of the same user, they will follow a cascading manner to notify all of their trusted domains of the user's exit request. The trust agent of each domain is responsible for notifying all trust domains of the user's exit request. As part of this process, the trust agent can call the trust intermediary.

The Possession Proof Challenge in the Consortium System Structure Just like any other distributed data processing environment, the Consortium environment with a single registration operation is vulnerable to security breaches. For example, when a statement is transmitted across a consortium environment, a malicious user may realize a so-called spoofing attack.

As another example, a legal user can perform a verification operation with the main domain, and the main domain then acts as a publishing domain on behalf of a legal user who has a single operation to issue a verification statement. The legitimate user may leave the client device and think that after a period of time, the user's current session with the main domain will be terminated. However, the legitimate user has made the client device vulnerable to abuse by illegal parties, and the malicious user can use the client device before the legal users session expires. After that, since the main domain or some other publishing domains have not conducted verification discussions with legitimate users for a period of time, the publishing domain does not know that the client device is acting on behalf of a malicious user, rather than working legally.

In order to minimize the chance of such a situation and enhance the security in the complex environment, it is best to have an optional additional security level in the complex environment without changing the entire complex system structure. To this end, the issuing party or relying party can directly issue a proof of possession challenge to the user, thereby verifying the user's identity, ensuring that the user provides a statement on behalf of the user, and the party verifying the statement or some other type of statement appropriately and correctly represents the legitimate user. Essentially, proof of possession requires the user to prove that the user owns something that should only be legally owned by a user with a specific identity, such as a combination of user name/password, confidential words, hardware tokens such as smart cards, biometric identifiers, or other Some information-related knowledge. In addition to the verification credentials maintained in the user's home domain, these proof of possession credentials will be maintained by the user's home domain and/or trusted domains in the consortium. If user information is transferred from one domain to another via HTTP redirection, then each domain will maintain proof credentials. If the user information is transferred directly between domains (trust agent to trust agent) through SOAP instead of HTTP redirection, then the ownership certificate can be maintained by the user's primary domain.

The remaining figures show the different situations in which the feature of proof challenge is implemented within the consortium system structure discussed above. Figure 5-8 depicts a call flow or data flow diagram that represents the flow of information between entities in the consortium environment; after each entity responds to the received message, it performs some processing in response to the reception of the message. Although the example shows communication using HTTP redirection through the user's browser, the domain can also communicate directly when needed. Figure 5 depicts the proof-of-ownership challenge verified by the issuing party using the direct communication between the trust agents located in the issuing domain and the trusted domain. Figure 6 describes the use of direct communication between the trust agents located in the issuing domain and the trust domain to verify the proof of ownership challenge for the trust domain verification. Figure 7 depicts the proof of possession challenge verified by the issuer, during which the trust agents located in the issuing domain and the trust domain communicate through the trust intermediary. Figure 8 depicts the proof-of-ownership challenge for trust domain verification, during which the trust agents located in the issuing domain and the trust domain communicate through a trust intermediary.

Now referring to Figure 5, the call flow diagram describes the proof of possession challenge verified by the issuing party using the direct communication between the trust agents located in the issuing domain and the trusted domain. The contact point server of the publishing domain uses the user's browser (step 502) to send a statement to the contact point server of the trusted domain (step 504) using HTTP redirection to start the process. The point of contact server of the trusting domain forwards the statement to the trust agent of the trusting domain for confirmation (step 506).

At this point, the trust agent of the trust domain confirms the received statement, or more specifically, before performing any further operations on behalf of the user, determines that the proof of possession challenge should be completed by the user. The trust agent of the trust domain asks the trust agent of the issuer for the information that should be placed in the proof of possession challenge (step 508). In this way, the publishing domain determines the information provided to or requested from the user. In response to the request, the trust agent of the issuing domain returns the challenge information to the trust agent of the trust domain (step 510). The trust agent of the trust domain then establishes a proof of possession challenge and returns it to the contact point server of the trust domain (step 512) . The point of contact server of the trusted domain sends a proof of possession challenge to the user's browser (step 514), and the user's browser presents the challenge to the user (step 516). The inquiry information may take an appropriate format, for example, a web page that may include embedded support programs or scripts. The content of the inquiry information requires everything that should only be owned by the user, such as user name/password combinations, confidential words, hardware such as smart cards, biometric identifiers, and other related knowledge. In addition, the challenge information can be encrypted and/or digitally signed to protect the integrity of the challenge information.

After the user answers the challenge (step 518), the browser returns the user's response to the challenge to the contact point server of the trusted domain (step 520), and the contact point server of the trusted domain forwards the challenge response to the trust agent of the trusted domain (step 520). 522), the trust agent of the trusted domain forwards the challenge response to the trust agent of the publishing domain for confirmation (step 524). The publishing domain does not have to be the user's primary domain; it can be a domain that serves as a trusted domain (or more than one) of the publishing domain that is in fact the user's primary domain. Therefore, if the possession certification credential is maintained by the user's home domain, and the publishing domain is not the user's home domain, the publishing domain can then forward the request to the user's home domain.

In short, the trust agent of the issuing domain then confirms the challenge response, and then returns the answer to the trust agent of the trusting domain (step 526). In this case, the publishing domain is still the only participant in determining the validity of the user's response; in this way, all verification and possession certification credentials will be maintained by the user's primary domain, and the user's primary domain serves as the user's publishing domain. In addition, the challenge response can also be encrypted and/or digitally signed (possibly in conjunction with the branch program or script in the challenge information that is started to be transmitted) to protect the integrity of the challenge response.

Assuming that the user's challenge response has been successfully confirmed by the trust agent of the user's home domain or the proof-of-ownership confirmation trust agent in the issuing domain, the trust agent of the trusting domain then returns a statement confirmation response to the contact point server of the trusting domain (step 528). Although the user's response to the challenge has been successfully confirmed, the initially received statement does not necessarily guarantee that the operation can be confirmed. Assuming that the statement is successfully confirmed, a session is established in the trust domain (step 530), after which the process ends. Other processing can then be performed on the resource request related to the initially received statement. If the user's challenge response is invalid, then the trusted domain can decide to reject the initially received claim, even if it can be successfully confirmed. In this way, the consortium environment has a mechanism to determine whether the user related to the statement is a legitimate user related to the statement correctly.

Now referring to Figure 6, the call flow describes the use of direct communication between the trust agents located in the issuing domain and the trust domain to verify the proof of possession challenge for the trust domain verification. From the point of contact server of the publishing domain through the user's browser (step 602), the process is started by sending a statement to the point of contact server of the trusted domain (step 604) using HTTP redirection. The point of contact server of the trusting domain forwards the statement to the trust agent of the trusting domain for confirmation (step 606).

At this point, before confirming the received statement, or more specifically, before performing any further operations on behalf of the user, the trust agent of the trust domain determines that the proof of possession challenge should be completed by the user. The trust agent of the trust domain asks the trust agent of the issuer for the information that should be put in the possession certification challenge (step 608). In response to the request, the trust agent of the issuing domain returns the challenge information to the trust agent of the trusting domain (step 610), and the trust agent of the trusting domain then establishes a proof of possession challenge and returns it to the point of contact server of the trusting domain (step 612) . The point of contact server of the trusted domain sends a proof of possession challenge to the user's browser (step 614), and the browser presents the challenge to the user (step 616).

After the user answers the challenge (step 618), the browser returns the user's response to the challenge to the contact point server of the trusted domain (step 620), and the contact point server of the trusted domain forwards the challenge response to the trust agent of the trusted domain (step 622). ), the trust agent of the trust domain then confirms the challenge response. In this case, the trust region can determine the validity of the user's response through various mechanisms. For example, the publishing domain may have provided a correct challenge response to the trusted domain along with the challenge information; the challenge response information can be protected by encryption to prevent malicious users from being deceived.

Assuming that the trust agent of the trust domain has successfully confirmed the user's challenge response, the trust agent of the trust domain returns a statement confirmation response to the contact point server of the trust domain (step 624). Although the user's response to the challenge has been successfully confirmed, the initial received statement does not necessarily guarantee the confirmation operation. Assuming that the statement is successfully confirmed, a session is established in the trust domain (step 626), after which the process ends. Additional processing can then be performed on the resource request related to the initially received statement. If the user's challenge response is invalid, the trusted domain may decide to reject the initially received claim, even if the claim can be successfully confirmed.

Now referring to Figure 7, the call flow diagram describes the proof of possession challenge verified by the issuer, during which the trust agents located in the issuing domain and the trust domain communicate through the trust intermediary. From the point of contact server located in the publishing domain through the user's browser (step 702), use HTTP redirection to send a statement to the point of contact server located in the trusted domain (step 704) to start the process. The point of contact server of the trusting domain forwards the statement to the trust agent of the trusting domain for confirmation (step 706).

At this point, before confirming the received statement, and more specifically, before performing any further operations on behalf of the user, the trust agent of the trust domain determines that the user should complete the proof of possession challenge. In contrast to Figures 5 and 6, the trust agent of the trust domain invokes the trust intermediary, and the request should be put into the information in the possession certification challenge (step 708). The trust intermediary then asks the publisher's trust agent to possess certification challenge information (step 710). In this embodiment, the issuing party should normally be the user's primary domain. The advantage of this embodiment lies in the use of a trusted intermediary; this process avoids the "linking" that occurs when multiple publishing domains are traced back in the consortium until the publishing domain, that is, the primary domain, is reached.

In response to the request, the trust agent of the issuing domain returns the challenge information to the trust agent (step 712), and the trust agent then forwards the challenge information to the trust agent of the trust domain (step 714). The trust agent of the trusting domain establishes a proof of possession challenge and returns it to the point of contact server of the trusted domain (step 716). The point of contact server of the trusting domain sends the proof of possession challenge to the user's browser (step 718), and the browser sends it to the users browser (step 718). The user presents the challenge (step 720).

After the user answers the challenge (step 722), the browser returns the user's response to the challenge to the contact point server of the trusted domain (step 724), and the contact point server of the trusted domain forwards the challenge response to the trust agent of the trusted domain (step 724). Step 726), the trust agent of the trusted domain forwards the challenge response to the trust intermediary to help start the confirmation operation (step 728). The proxy agent forwards the challenge response to the trusted proxy of the publishing domain for confirmation (step 730). The trust agent of the issuing domain then confirms the challenge response and returns the answer to the trust agent (step 732), and the trust agent forwards the confirmation response to the trust agent of the trust domain (step 734). In a similar way to the situation shown with reference to Figure 5, the publishing domain is still the only participant in determining the validity of the user's response, but in this case, the trusting domain asks the trust intermediary for help.

Assuming that the trust agent of the publishing domain successfully confirms the user's challenge response, the trust agent of the trust domain returns a statement confirmation response to the contact point server of the trust domain (step 736). Although the user's response to the challenge has been successfully confirmed, the initial received statement does not necessarily guarantee the confirmation operation. Assuming that the statement is successfully confirmed, a session is established in the trust domain (step 738), after which the process ends. Additional processing can then be performed on the resource request related to the initially received statement. If the user's challenge response is invalid, the trusted domain may decide to reject the initially received claim, even if the claim can be successfully confirmed.

Now referring to Figure 8, the call flow diagram describes the proof of possession challenge for trust domain verification, during which the trust agents located in the issuing domain and the trust domain communicate through the trust intermediary. The process starts from the point of contact server located in the publishing domain through the user's browser (step 802), using HTTP redirection to send a statement to the point of contact server located in the trusted domain (step 804). The point of contact server of the trusting domain forwards the statement to the trust agent of the trusting domain for confirmation (step 806).

At this point, before confirming the received statement, and more specifically, before performing any further operations on behalf of the user, the trust agent of the trusted domain determines that the user should complete the proof of possession challenge. The trust agent of the trust domain calls the trust agent, and the request should be put into the information in the possession certification challenge (step 808), and the trust agent then requests the issuer's trust agent for the challenge information (step 810). In response to the request, the trust agent of the issuing domain returns the challenge information to the trust intermediary (step 812), the trust agent then forwards the challenge information to the trust agent of the trust domain (step 814), and the trust agent of the trust domain then establishes a proof of ownership challenge, And return it to the point of contact server of the trusted domain (step 816). The point of contact server of the trusted domain sends a proof of possession challenge to the user's browser (step 818), and the browser presents the challenge to the user (step 820).

After the user answers the challenge (step 822), the browser returns the user's response to the challenge to the contact point server of the trusted domain (step 824), and the contact point server of the trusted domain forwards the challenge response to the trust agent of the trusted domain (step 824). Step 826), the trust agent of the trusted domain then confirms the challenge response.

Assuming that the trust agent of the trust domain successfully confirms the user's challenge response, the trust agent of the trust domain then returns a statement confirmation response to the contact point server of the trust domain (step 828). Although the user's response to the challenge has been successfully confirmed, the initial received statement does not necessarily guarantee the confirmation operation. Assuming that the statement is successfully confirmed, a session is established in the trust domain (step 830), after which the process ends. Additional processing can then be performed on the resource request related to the initially received statement. If the user's challenge response is invalid, the trusted domain may decide to reject the initially received claim, even if the claim can be successfully confirmed.

In view of the detailed description of the present invention provided above, the advantages of the present invention should be obvious. The existing technical solutions organize the domain security service into a hierarchical structure, requiring the domain to have a strong trust relationship and internally compatible technologies. Other methods impose a uniform format on the verification statement, or are inconvenient for the transmission of the verification statement, and sometimes transmit the verified identity based on which the local statement is established.

Among the advantages of the present invention, the trust agent allows existing security services in a specified domain to establish trust relationships with other domains without having to subscribe to the same trust root source or use the same trust establishment technology. Thus, the consortium system structure of the present invention provides loose coupling of entities. The primary domain manages authentication, and each domain only manages the authentication of its own registered users. Each domain is free to accept, reject or modify any other domain's statements about user identity and attributes. The trusted domain relies on the identity and attribute declaration of the publishing domain (in the final analysis, the primary domain), and each domain can implement any verification protocol, without modifying the application in the specified domain, it can realize the previously unsupported protocol so that the specified domain can participate in the federation. body. A consortium does not require a special trust model; a group of entities can form a consortium that abides by the trust model established by the participating parties. Only trust agents and/or trust intermediaries can claim conversion occur; the consortium system structure serves as a front-end infrastructure that can be implemented with minimal impact on the existing old system.

The consortium allows users to seamlessly move back and forth between different sites in the designated consortium in a single sign-on manner. Because of the trust relationship established between the consortium participants, a participant can authenticate the user and then act as the issuer of that user. Other consortium partners become relying parties, so that they rely on the information about the user provided by the publisher and do not directly involve the user.

By requiring users to re-certify their identities with the help of a proof-of-ownership challenge performed after the initial transmission of the statement, the issuing party and the relying party can improve security within the consortium environment. Proof of possession does not replace verifying the challenge/response, but provides an extra layer of security. A proof of possession challenge can also be considered a "proof of liveness" challenge; it is a test where a user has one or more messages that cannot be known by malicious users who try to hijack, intercept, or impersonate a legitimate user's session. Possessing a proof challenge does not prevent so-called man-in-the-middle attacks unless a secure session has been created by using a client-side digital certificate. However, possession of a proof challenge can prevent cheating by someone falsely claiming to have the identity of another user (assuming that the identity of the user is confirmed by the additional challenge/response test of the proof of possession challenge). If the user cannot pass the proof of possession challenge, the relying party may refuse to perform any operation on behalf of the user.

It is important to note that although the present invention has been described in the context of a full-featured data processing system, those of ordinary skill in the art will recognize that the processing of the present invention can be distributed in the form of instructions in a computer-readable medium, as well as in various other forms. , Regardless of the specific type of signal-bearing medium actually used to realize the distribution. Examples of computer-readable media include media such as EPROM, ROM, tape, paper, floppy disk, hard drive, RAM, and CD-ROM, and transmission-type media such as digital and analog communication links.

Methods are often conceived as a consistent sequence of steps leading to the desired result. These steps require physical manipulation of physical quantities. Usually (but not necessarily), these physical quantities take the form of electrical or magnetic signals that can be stored, transferred, combined, compared, and processed in other ways. Sometimes it is advantageous to refer to these signals as bits, values, parameters, items, elements, objects, symbols, characters, items, numbers, etc., mainly for reasons of common application. However, it should be noted that all these terms and similar terms are related to appropriate physical quantities and are merely convenient labels applicable to these physical quantities.

The description of the present invention is given for the purpose of illustration, but the description is not exhaustive or limited to the disclosed embodiments. Many modifications and changes are obvious to those of ordinary skill in the art. The embodiments are used to illustrate the principle of the present invention and its practical application, and to enable those of ordinary skill in the art to understand the present invention, so as to purchase different embodiments with various modifications suitable for other anticipated applications.