JP2013152757A - Intersystem single sign-on - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide techniques for intersystem single sign-on that uses intersystem user ID mapping to map user IDs of multiple systems.SOLUTION: In one implementation, a method obtains a user's ID information associated with a first system, and obtains the user's ID information associated with a second system from the user's ID information associated with the first system according to the intersystem user ID mapping table. The first system sends the user's ID information associated with the second system to the second system, which may allow the user to automatically log on upon successful user ID verification. The user ID information communicated between the systems may be encrypted and decrypted using digital signature techniques. Systems for accomplishing the method are also provided.

Description

  The present disclosure relates generally to computer and Internet technologies, and particularly to systems and methods for intersystem single sign-on (SSO).

  Many Internet-based applications require users to perform a series of steps across multiple systems that are linked to each other but are still independent. For example, in an Internet commercial application, a consumer may select a product to purchase on a merchant's website, but needs to pay through another website owned by a payment service provider. This procedure is particularly common in consumer-to-consumer (C2C) e-commerce applications, where the seller is still not reputed to receive electronic payments or has a reputation for being credible to make direct payments. Not. In an Internet auction, for example, a buyer makes a purchase selection on a C2C website (auction site), but instead of paying directly to the seller, the buyer is often safe, reliable and convenient I prefer to pay from a third party service provider's payment website, sometimes known for instant electronic payments. In this example, the C2C website and the third party payment website are two independent websites maintained by two independent companies, each with its own user ID domain and ID authentication mechanism. . To complete the purchase transaction, the buyer may need to log on twice (once at the C2C website and once at the third party payment website). However, from the user's (buyer's) point of view, it is usually desirable to have a quick and simplified shopping experience without signing on to two different websites during one purchase transaction.

  SSO requires that a user enters user ID information only once for ID authentication, and as a result, can automatically sign on to multiple systems or application programs that require user ID authentication. Refers to the logon environment. One-time input of user ID information is performed by one of a plurality of systems or application programs. The user does not need to input user ID information again from another system or application program.

  Conventional SSO methods and systems include two basic software: (1) a centralized user management system for maintaining a universal user view, and (2) a common user ID authentication system for performing unified user ID authentication. And based on hardware components. The user first uses the universal user ID to sign on to the common user ID authentication system, thereby obtaining an authorization token to prove the user's ID to the subscribing system. When a user requests to visit a subscribed system in the same user ID management domain, an authentication token is included in the user's logon request as a hidden “password”. The target subscribing system inquires the common user ID authentication system to verify the validity of the token, and determines whether the user ID is valid based on the result of the inquiry.

  FIG. 1 illustrates an example of a conventional SSO method and system. The procedure for single sign-on according to the method and system of FIG. 1 is described below.

  In step 1, a user (not shown) makes an initial request to the application system 110 via the user's browser 100 to access that particular resource. If it is found that the user does not have an authorization ID token, the application system 110 redirects the user to the common ID authentication and authorization system 120 for ID authentication. The common ID authentication and approval system 120 uses the common user ID library 130 for user ID management.

  In step 2, the user passes the ID authentication process with the common ID authentication and authentication system 120 and receives an authorization ID token.

  In step 3, the user is redirected to the application system 110 by the common ID authentication and authorization system 120 and sends an authorization ID token to the application system 110.

  In step 4, the application system 110 sends an authorization ID token to the common ID authentication and authorization system 120 to verify the validity of the ID token. If the ID token is proved valid, the application system 110 allows access to the resource requested by the user, otherwise the application system 110 denies access by the user.

As shown, the conventional SSO method requires a common ID authentication and authorization system shared by multiple application systems, and further requires a common user ID library. Since multiple application systems are hosted on various websites using different management systems, establishing a common user ID library and common ID authentication and authorization system presents difficulties for both management strategy and technical implementation. Bring. Typical examples of such difficulties include:
1. Different websites have different user groups. Each of these user groups constitutes a set. These sets may intersect each other but are usually not identical to each other. As a result, it is difficult to integrate different user groups into a common user ID library for centralized management.
2. Different websites have their own unique methods and procedures for user registration and management. Requiring different websites to convert their systems to a common user identity management system is often incompatible with business requirements.
3. Even if the common user ID library is shared by multiple systems, each system may need to be individually upgraded. As a result, it is difficult to reach agreement on the standards used, and it is more difficult to determine which systems should have an advantage in establishing and maintaining a common user ID library.
4). On the Internet, ID tokens are typically communicated using cookies that generally require that all websites in the same SSO logon domain belong to the same network domain. Even if possible, establishing SSO across different network domains requires a very complex procedure.
5. The common user ID authentication system is a centralized session management unit, which is typically a single point of failure and a bottleneck in performance. Solving such problems may require costly and complex cluster technology, which greatly increases system construction and maintenance costs.
6). In order to change a plurality of individual user ID authentication and management systems to a common user ID authentication and management system, significant changes and modifications to existing systems may be required. This not only increases costs, but also carries significant risks.

  For the foregoing reasons, there is a significant need for improved SSO methods and systems.

  A single sign-on (SSO) technique is described that uses a distributed model of user ID management instead of the traditional centralized model. Inter-system single sign-on is made possible by using a user ID mapping concept for mapping user IDs of multiple systems.

  According to one aspect, a method for single sign-on between a first system and a second system is provided. The first system acquires user ID information related to the first system. Thereafter, the first system obtains the user ID information related to the second system from the user ID information related to the first system according to the inter-system user ID mapping relationship, and the user ID information related to the second system is obtained as the second To the system. Upon receiving the user's ID information, the second system allows the user to sign on to the second system.

  In one embodiment, user ID information communicated between systems is encrypted using digital signature technology. For example, the first system creates a signature attached to the user ID information related to the second system, and transmits the signature together with the user ID information related to the second system to the second system. The second system authenticates the user ID information by examining the received signature. In one exemplary application, the user first signs on to the first system. The second system allows the user to sign on to the second system when the user's ID information is authenticated. If the user has not yet signed on to the first system, the first system may require the user to sign on to authenticate the user's identity.

  The first system may be configured to create a signature upon receiving notification that the user has attempted to sign on to the second system. This notification may be either a logon request initiated by a user on the first system or a logon request redirected to the first system by the second system.

  In one embodiment of the method, the first system informs the second system that the user has come from the first system. The second system may use this recognition to narrow, eg limit, the user's authority when signing on to the second system.

  The signature may be encrypted with the cryptographic digital signature by the first system. Thus, the second system decrypts the cryptographic digital signature to authenticate the signature. Encryption and decryption may be performed using any suitable encryption technique such as public key encryption and private key encryption. A hashing technique may also be used. The first system may create a hash from at least a portion of the user ID information for the second system before sending the user ID information to the second system.

  In one embodiment, the first system stamps the signature and / or user ID information about the second system before sending the signature and / or user ID information to the second system. The second system authenticates the signature and / or user ID information by verifying the time stamp information. For example, the time stamp information may be verified by comparing the current time stamp with a previous time stamp for the same user. The signature and / or user identity information is authenticated only if the current timestamp is a successor to the previous timestamp. The second system may maintain signature log records and received user ID information.

  According to another aspect, a system is provided for authenticating inter-system user sign-on. The system includes a data storage and an ID authentication device for authenticating the ID of a user who is requesting logon using user information stored in the data storage. The system further includes user ID mapping data stored in the data storage. The user ID mapping data defines a mapping relationship between user ID information about the current system and user ID information about the partner system. The system is adapted to obtain user ID information about the partner system from user ID information about the system using a matching relationship.

  In one embodiment, the system includes a signature generator for generating a signature that is attached to user ID information about the partner system. The signature generator may use an encryption algorithm.

  According to another aspect, a system for authenticating inter-system user sign-on authenticates a user ID using a data storage storing user ID information related to the current system, and the user ID information stored in the data storage. For having an ID authentication device. The system further includes a signature authentication device for authenticating the received user ID by decrypting the signature attached to the user ID received from the partner system and determining user ID information stored in the data storage. . The system can permit a user to log on after successful authentication of a signature by a signature authentication device. In one embodiment, the system further comprises a user rights controller for restricting user rights according to a user logon method.

  Unlike traditional SSO methods and systems, the techniques described in this disclosure use a distributed user management model instead of a centralized model. A direct user ID mapping table may be constructed to integrate user ID information for different systems using the inter-system ID mapping concept. Digital signature technology can be used to enhance security. Both user ID mapping and digital signature techniques are simple extensions of existing systems and do not require fundamental changes to existing user ID authentication systems. Large collaborative systems that include multiple independent systems may be built based on mutual trust relationships without having to significantly change each system or abandon its independence.

  Other features and advantages of the described technology will be more readily understood from the following detailed description and figures.

  The detailed description is described with reference to the accompanying figures. In the figure, the leftmost digit of the reference number identifies the figure in which the reference number is first displayed. Use of the same reference number in different figures indicates similar or identical items.

It is a figure which shows the example of the conventional SSO method and system. 1 is a schematic diagram of an exemplary system for achieving single sign-on in Internet electronic commerce. FIG. FIG. 3 is a flow diagram illustrating an exemplary single sign-on process. FIG. 5 illustrates an exemplary single sign-on process that defines when website B requests website A to sign user ID information.

  As demonstrated in the following representative examples, the techniques described herein depart from the centralized model of user ID management found in existing single sign-on (SSO) methods, and a distributed model of user ID management. Is introduced. This design addresses high technical complexity issues and management difficulties.

  According to one aspect of the present disclosure, a method for inter-system single sign-on is provided that uses inter-system user ID mapping to map user IDs of multiple systems. Separate partner systems, each of which may be an independent website, such as a C2C website or a payment website, can have their own user ID and user ID management system, and a common user ID It is not necessary to comply with the library and the common user ID management system.

  Since user IDs for different systems can be different even for the same user, this disclosure introduces inter-system user ID mapping techniques to coordinate between different systems. Mapping defines the matching correspondence of the same user ID between different systems. Each ID of a particular user may have basic attributes such as username and password, which may be different in different systems, but includes other attributes such as date of birth, address, and preferences In some cases. The mapping may be done in any suitable manner, but preferably the system can uniquely identify each user and is based on the recognition of the user's ID information associated with another system. Each user's ID information for one system should be identifiable.

  FIG. 2 is a schematic diagram of an example system 200 for achieving single sign-on in Internet electronic commerce according to the present disclosure. As shown in FIG. 2, user C attempts an Internet transaction related to two partner systems represented by website A and website B via the user's browser 210. Single sign-on is performed between the website A and the website B. Website A and Website B are two independent websites on the Internet. They may be located anywhere on the Internet, may belong to two different domains, network domain A and network domain B, or may belong to the same network domain.

  Website A has its own user group defined by a user library 224 stored in data storage 220. Website B also has its own user group defined by user library 234 stored in data storage 230. Each of the data storages 220 and 230 may be a single storage device or a composite storage system.

  The website A further includes an ID authentication device 221 for authenticating the ID of the user who is requesting logon. The authentication process uses user ID information stored in the data storage 220 in the user library 224. Once the user's ID is authenticated, the user is allowed to access the requested resource of website A.

  Website A further includes user ID mapping data 226 stored in data storage 220. The user ID mapping data 226 defines a mapping relationship between user ID information related to the website A and user ID information related to the website B. The user ID mapping data 226 enables the website A to acquire the user ID information related to the website B from the ID information of the same user related to the website A.

  Website A further includes an ID signature generator 222 for generating a signature attached to the user ID information for website B. The ID signature generator 222 and the ID authentication device 221 may be integrated into either two separate units or a single unit.

  The website B also has an ID authentication device 231 for authenticating the user ID using the user ID information of the user library 234 stored in the data storage 230. Website B further includes a signature authentication device 232 for decrypting the signature attached to the user ID information received from website A. The ID authentication device 231 and the ID signature authentication device 232 can be implemented in either two separate units or a single unit.

  Signature decryption is used to verify the authenticity and integrity of the user ID received from website A. If the user's ID is authenticated, the user may be allowed to access the requested resource of website B.

  In the exemplary application, website A and website B establish a partnership for electronic commerce. The partnership allows website A and website B to exchange user information and thus retrieve user ID mapping data 226, which may be in the form of a mapping table. User C is a customer of both website A and website B. Typically, user C may have become a customer of website A and website B separately and independently. The same user C may have different user ID information (eg, different usernames or passwords) for website A and website B. For example, if the ID of user C for website A is CA and the ID of user C for website B is CA, user ID mapping data 226 (such as a mapping table) is between CA and CB. This means that a user who includes an input indicating the mapping relationship as CA → CB and whose ID on the website A is CA has an ID of CB on the website B. When properly constructed, the user ID mapping data 226 allows website A to uniquely identify each user, and based on the recognition of the same user's ID information for website A, website B ID information of each user can be specified.

  The matched ID information may include attributes such as the logon user name and password, but may include additional attributes that differ between systems. Further, additional information used for user ID authentication and user authority control and restriction may be attached to the user ID information.

  In an exemplary process, website A obtains user C's ID information for website A when user C signs on website A via the user's browser 210. By appropriately using the ID mapping data 226, the website A acquires the ID information of the user C related to the website B from the ID information of the same user C related to the website A. Thereafter, the website A transmits the user ID information regarding the website B to the website B. If the received ID information is satisfactory upon receiving the user's ID information, the second system may allow user C to sign on to the second system.

  User ID information communicated between website A and website B may be encrypted using digital signature technology to be secure. Website A has an ID signature generator 222 for this purpose. For example, after user C has successfully signed on to website A, website A defines user C's ID information for website A and website B as CA and CB, respectively, and ID signature generator 222 Before sending to site B, the user ID information CB may be digitally signed. Any suitable encryption technique may be used to generate a signature for digitally signing the user ID information CB. In general, the signature algorithm needs to be negotiated at both website A and website B to coordinate the encryption at website A and the decryption at website B. One example of a suitable signature algorithm is a public key signature algorithm, where website A uses it to sign user ID information using its private key, and website B uses website A's The public key that matches the private key may be used to decrypt the signature.

  The digital signature generated by the ID signature generator 222 at the website A is attached to the user ID information CB related to the second system. The digital signature and the ID information CB are both sent to the website B in order to request a logon to the website B.

  Website B receives a logon request from website A and detects that the logon request includes a signature that requires authentication. Website B has an ID signature verifier 232 for this purpose. The ID signature verifier 232 decrypts the signature and verifies the validity of the received signature and the user's ID information such as reliability and integrity. When the signature and the user ID information pass the validity test, the website B determines the ID of the user C from the ID information transmitted from the website A. Website B approves CB as a valid ID of user C for website B, thereby establishing the appropriate role and session for user C.

  If the signature and ID information fails the validity test, website B will reject the logon request by user C. In some cases, even though the signature and ID information pass the validity test, a specific user ID, CB, may not yet be allowed to log on due to certain additional restrictions introduced at website B. For example, a specific user ID, CB, may be expired or has an incorrect status, or is found in a black list maintained at website B. Under such circumstances, website B may still deny user C's logon request.

  Website B further includes an authority controller 233 for controlling the authority given to user C as a visitor accessing the resources on website B. Typically, a user with a particular user ID has a unique set of privileges that is defined when the user ID is created. However, it may be desirable to further control the user's authority by the manner in which the user requests logon. For example, a user who logs on directly to the website B may be given unique authority, while a user who is redirected from another website (for example, the website A in this embodiment) may be given less authority. is there. To determine the unique authority of the user requesting logon, the authority controller 233 may consult the user library 234 stored in the data storage 230. In order to determine the user's login method, the authority controller 233 may examine the logon request information (included with the signature and user ID) sent from the website A. Alternatively, the authority controller 232 may examine session information recorded on the website B including information on the user logon method. The session information is usually recorded in a log file on the website B after the user C signs on and establishes a session.

  In the exemplary application, website A is a C2C website and website B is a payment website. When user C signs on to website B (payment website) launched at website A (C2C website), user C only conducts payment transactions related to website A during the current session, The authority controller 233 may limit the authority of user C's current session so as not to make payment transactions related to other websites. In general, payment websites are more secure than C2C websites. The use of the authority controller 233 helps achieve a better partnership with the right balance of safety and convenience. For example, with proper authority control, user ID information (such as user name and password or security code) regarding the C2C website can be stolen or compromised only for transactions between the user and the C2C website. Affect.

As indicated above, single sign-on between website A and website B is enabled by user ID mapping data and is further secured by digital ID signature technology. The signature algorithm used for digital ID signing is an important component to provide security for single sign-on according to the present disclosure. Preferably, the signature algorithm should satisfy the following security requirement aspects:
(1) Reliability for proving that the information (including the signature for signing the user ID information relating to the website B and other additional signature information) is indeed transmitted from the website A.
(2) Completeness to prove that the signature and the ID information have not been tampered with by an unauthorized person after the ID information is signed.
(3) Non-repudiation guaranteeing that no one other than Website A, including Website B and any other third party, can create a valid signature on the record. If appropriate non-repudiation means the validity and safety questions are discussed, website A cannot be denied to be the creator of the signature on the record.
(4) Prevention of replay, which ensures that the ID signature is used only once. Once used, the ID signature is no longer valid and therefore cannot be used again. This prevents the third eavesdropper from stealing the user ID signature and reapplying the signature to gain logon access to website B.

  One exemplary technique for achieving the security measures described above (reliability, integrity, and non-repudiation) is a public key digital signature algorithm. In order to use this algorithm, website A and website B negotiate a set of public and private keys in advance. The private key is stored hidden from website A by other entities including website B. The public key that matches the private key is made public and is known in particular to website B. In an actual application, the ID signature generator 222 of website A applies a public key digital signature algorithm and signs user ID information about website B using a private key. Upon receiving the signed user ID, the ID signature verifier 232 of website B decrypts the received signature using the public key according to the same public key digital signature algorithm. This encryption-decryption procedure provides the basis for verifying the authenticity and integrity of the ID signature signed by website A. At the same time, website B records the authenticated ID signature in the session log to provide a non-repudiation means. The recorded session log avoids denying that website A has executed the recorded ID signature when a discussion occurs.

  One exemplary technique for preventing replay is the use of time stamps. The user ID communicated from the website A to the website B is stamped with a time stamp, and the logon request is stamped with the user ID and by the system website B that is the recipient. Information indicating that confirmation and authentication are required may be included. In a preferred embodiment, the time stamp is implemented as an integral part of the digital signature signature procedure. For example, a digital signature algorithm selected to create a signature may require that a time stamp be attached to the ID information signed at website A, and the time stamp and ID information may be signed together. is there. This ensures the reliability and integrity of both ID information and timestamp information. At website B, signature decryption simultaneously verifies the authenticity and integrity of both ID information and time stamp information.

  Time stamp information may be used to prevent replay in various ways. The following are two examples.

  1. At the website B, the ID signature verifier 232 authenticates the ID signature received from the website A, and at the same time, the current ID signature time stamp and the previous ID transmitted from the website A of the same user (user C). Compare signature timestamps. Since continuous logon requests by the same user always increase in time, a replay attempt is detected if the current timestamp is either older than the previous timestamp or is identical to the previous timestamp There is a possibility that. After performing such detection, the ID signature authentication fails, and the website B denies access by the user C.

  If user C is visiting website B for the first time, the time stamp may need to be approved without comparing it to the previous time stamp, but because the signature and user ID information are applied for the first time, In this special situation, there is no risk of replay. If User C has a genuine and legitimate repeated visit, the current signature and the previous signature with different, unique and continuous timestamps are created separately. Using this technique, if user C makes a genuine visit with a particular signature, the same signature effectively expires. This technique requires website B to keep a log of all logon requests, including additional attachment information such as time stamps.

  2. Website A and website B negotiate a validity period for the signature after creation. For example, website A and website B may negotiate that the signature is valid for only one minute after creation. Upon receiving the signature, website B compares the signature timestamp with the current time (actual time) to determine whether the signature is still valid. Using this technique, the validity of any event where a signature is stolen or leaked is limited to only one minute. Thus, the consequences of security breaches are minimized. In practice, it may be desirable for website A to send immediately after creating a signed user ID information signature. This may be possible by negotiating an expiration date well below one minute.

  The above two techniques for using time stamp information are not mutually exclusive. They may be combined with practice. For example, the first technique, when used alone, may be compromised in the event that a signature created on website A is stolen or leaked before being transmitted to website B. In this case, website B does not have an appropriate record of user C's time stamp, and a criminal who owns a stolen or leaked signature may pass the time stamp test. However, the combination of both the first and second techniques described above solves the problem because a stolen or leaked signature is unlikely to be applied until a significant amount of time has passed. There is a possibility that.

  Signature algorithms that can be used for signature creation and authentication include, but are not limited to, public key signature algorithms such as a digital signature algorithm (DSA). Various technologies are available and the one that best suits the needs of the partner website may be selected. For example, if website A and website B have a sufficient degree of mutual trust, a mechanism for non-repudiation may not be necessary. In this case, the website A uses a secret key algorithm to encrypt the user ID information and the time stamp information, and sends a ciphertext (cipher text string) to the website B to obtain reliability, integrity, and Guarantees replay prevention.

  Alternatively, a simpler algorithm such as a hash algorithm SHAI (Secure Hash Algorithm, version 1.0) or MD5 (Message Digest, version 5) may be used for signing ID information and time stamp information. A seed selected by a hash algorithm and negotiated by both (website A and website B) may be used to prevent a third party from creating a valid signature on the user ID information.

  FIG. 3 shows a flow diagram of an exemplary single sign-on process according to this disclosure. A process is shown in the logical flow graph as a collection of blocks, indicating a series of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, a block represents a computer-executable instruction that, when executed on one or more processors, performs the operations described. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or introduce particular abstract data types. The order in which the actions are described is not intended to be a parsing limitation, and any number listed in the block can be combined in any order and / or in parallel with the process. Can be introduced. For discussion purposes, the process will be described with reference to the system 200 of FIG.

  In this embodiment, the user first signs on to the website A. Website A initiates the process of creating a user ID signature to achieve automatic logon to website B. An exemplary single sign-on process is described in the following blocks.

  In block 300, user C requests to log on to website A and enters ID information (such as a username and password) for ID authentication.

  In block 301, the ID authentication device 221 of the website A reads the user ID information from the user library 224 stored in the data storage 220 and authenticates the user ID information provided by the user C.

  In block 302, user C is allowed to access the resources of website A upon successful user ID authentication.

  In block 303, website A determines user C's ID information for website B and generates a user ID signature based on the user ID information. In some cases, a mechanism may be employed that allows Website A to detect if User C is signed on at Website B before User C's ID information is determined and signed. Good. This can be done automatically or with specific instructions from user C. For example, website A automatically knows that user C is about to sign on to website B when user C requests a resource from website A that requires service or support from website B. It may be detected.

  The ID information of user C regarding website B is determined at website A using ID mapping data 226 stored in data storage 220. For example, if the user ID mapping data 226 includes a website A / website B (A / B) mapping table, the ID signature generator 222 obtains the ID information of the user C regarding the website B by reading the mapping table. May be. The ID signature generator 222 then signs the user C's ID information about the website B and other additional information (such as time stamp information) using the negotiated signature algorithm. The ID signature generator 222 further attaches an ID signature to the logon request to the website B.

  At block 304, website A directs website B to a logon request that includes a user ID signature. In the logon request, website A may further label user C as coming from website A. Such labeling may be in the form of different subdomain names or additional attached parameters.

  In block 305, website B determines whether the user ID signature received from website A is valid. This is done by an ID signature verifier 232 that uses a negotiated signature algorithm to decrypt the signature. If the user ID signature is invalid, the website B rejects the user C logon request. If the user ID signature is valid, the process proceeds to the next step 306.

  At block 306, because it is determined that the user ID signature from website A is valid, website B has already signed on to website A that user C can trust, so Determine that permission to log on should also be given. Thus, website B establishes user C's session and allows user C to access the resources requested by website B. The session is established according to the user ID information relating to the website B identified from the user ID information received from the website A. Website B may also record a user ID signature in the session log that may be used for other purposes, such as comparing timestamps of future logon requests.

  In block 307, website B checks the status of user C and determines its authority for the established session. This is performed by the authority controller 233. If it is discovered that a particular user C is not authorized to access a particular requested resource, website B may request user C's request even though user C's user ID is valid. Deny. If a particular user C is found to have the right to access a particular requested resource, the website grants the access.

  It is understood that the above steps may be integrated into fewer steps or expanded to more steps to achieve the same or similar objectives. For example, step 306 and step 307 may be performed simultaneously as a single step.

  The single sign-on process described above may be performed only once for an unclosed session that involves multiple requests or multiple transactions by the same user C. Once user C and website B have established a valid session, user C chooses to continue the session, returns to website A, and without repeating the single sign-on process described above, website B You may access the authorized resources directly. A continuous session may include repeated access to the originally accessed resource or new access to other authorized resources.

  In the exemplary embodiment above, website A initiates the signing process. Note that the signature need not be generated every time user C requests to log on to website B. The method according to the present disclosure may be configured such that website A is required to sign user ID information only when a new signature is required. For example, every time user C tries to visit website B from website A, instead of website A starting its own signature process, website B receives a request to send signed user ID information Only in this case may website A perform this action. This design avoids unnecessary repetition and redundant signature creation and authentication. Since the execution of the signature algorithm uses a considerable amount of computer resources, reducing such execution can save a significant amount of operating costs. Furthermore, the lower incidence of signature creation and authentication results in a lower risk of leaking recorded records and signatures.

  FIG. 4 is a flow diagram illustrating an exemplary single sign-on process, where website B determines when website A requests to sign user ID information. An exemplary process is described in the following blocks.

  In block 400, user C logs on to website B and requests access to a particular resource. This may be initiated directly by user C at website B, but website A is a C2C site, while website B is a payment site, in the example shown, to sign on. This request is likely to be directed from website A to website B. In this case, the logon request may identify user C as coming from website A. Such an identification may include either a different subdomain name or additional attached parameters in the logon request information.

  In block 401, website B determines directly or indirectly from the website via a single sign-on process whether user C has already signed on to website B. If user C has already signed on to website B, the process skips the signature creation and authentication steps and jumps to step 407 to determine user C's authority for access to the resources requested by website B. . If user C has not yet signed on to website B, the process proceeds to step 402.

  In block 402, website B redirects user C's logon request to website A. The request includes a parameter that identifies a request for website A to send user C's ID information to website B. If the ID information is protected by a signature, the request includes a parameter that identifies the request for website A to securely sign the ID information sent to website B. If desired, the request may also identify a particular resource of website B for which user C is requesting access.

  In block 403, the ID signature generator 222 of the website A reads the user ID information regarding the website B of the user C from the user ID mapping data 226 and uses the signature algorithm negotiated for the website A and the website B. A user ID signature is generated from the ID information. The user ID signature also covers additional information such as time stamp information. Preferably, website A may check whether user C has already signed on to website A at the beginning of step 403. If user C has not yet signed on to website A, website A should normally request user C to sign on to website A first before performing step 403. In this case, the normal logon process may be performed after the user name and password are confirmed and authenticated by the ID authentication device 221.

  In block 404, website A attaches the newly created user ID signature to the logon request and redirects the logon request including the user ID signature to website B.

  At block 405, the ID signature verifier 232 of website B verifies the validity of the ID signature by decrypting using the signature algorithm negotiated by website A and website B. If the ID signature is invalid, website B denies user C access to the requested resource. If the ID signature is valid, the process proceeds to step 406.

  In block 406, because it is determined that the user ID signature from website A is valid, website B determines that user C has already signed on to trusted website A, and the user User C's session is established so that C can access the resources requested by website B. The session is established according to the user ID information relating to the website B received from the website A. Website B may also record the user ID signature in a session log and use it for other purposes, such as time stamp comparisons for future logon requests.

  At block 407, the authority controller 233 of website B checks the status of user C and determines its authority for the established session. If it is found that user C is not authorized to access a particular requested resource, website B denies user C's request. If it is found that user C has the right to access the requested resource, website B grants the access.

  The above techniques may be implemented using one or more computer readable media containing computer executable instructions. The computer executable instructions enable the processor to perform an intersystem single sign-on (SSO) procedure according to the techniques described herein. It will be appreciated that the computer-readable medium may be any suitable memory device for storing computer data. Such memory devices include, but are not limited to, hard disks, flash memory devices, optical data storage, and floppy disks. Further, a computer readable medium containing computer-executable instructions may be comprised of components of a local system or components distributed over multiple remote systems. Computer post-completion indication data may be transmitted to a physical memory device that is tangible or may be transmitted electronically.

  As shown herein, this disclosure proposes a distributed model for single sign-on by introducing an inter-system user ID mapping concept. The distributed model avoids some administrative and technical risks inherent in the traditional centralized model of single sign-on methods. While partner systems (eg, website A and website B in the exemplary embodiment) retain their independence, the user ID mapping component between partner systems is flexible and the actual needs at that time Depending on the gender, it can be built, modified, or removed.

  With a distributed model, the ID signature generator and ID signature verifier establish a mutually trusted system (eg, inter-website) single sign-on mechanism without using a centralized user ID authentication system, and thus Avoid potential performance bottlenecks and single points of failure caused by centralized user ID authentication systems. The ID signature generator and ID signature verifier according to the present disclosure is a simple extension of an existing website. Compared to a centralized ID authentication system, the technique described in this disclosure does not require significant modification of the original ID authentication system of an existing website. This helps mitigate the high operating cost and high risk problems of traditional single sign-on methods. Safety measures are also a simple extension of existing systems. A person who ensures the reliability, integrity, non-repudiation, and replay prevention of the single sign-on process may easily select and implement a suitable signature algorithm. The level of safety can meet most of the stringent security requirements of websites that conduct electronic commerce. The single sign-on procedure according to the present disclosure may be optimized to minimize signature generation and authentication, and as a result, achieve speed and convenience design objectives.

  Although the exemplary embodiment is illustrated using two partner websites, website A and website B, it is understood that the techniques described in this disclosure are not limited to this type of application. For example, in addition to establishing a user ID mapping table for website A / B with website B, website A may establish a user ID mapping table for website C and website A / C. Similarly, website B may establish a user ID mapping table for website C and website B / C. That is, the website C may establish a partner relationship with a plurality of websites. In addition, website B also establishes a user ID mapping table for website B / A, which is the opposite of the transaction performed using website A / B's user ID mapping table as described herein. This transaction may be executed. Regardless of the complexity of the implementation and the number of parties, the two websites that established the user ID mapping table may perform transactions in the same manner as described herein.

  Further, although exemplary embodiments are shown using a website in the context of electronic commerce, the techniques described in this disclosure are not limited to this type of application. The technology may be applied to any network system and communication system, such as an instant messaging system where user ID authentication is required for at least one of the partner systems to access resources in the system.

  The term “user ID signature” as used herein refers to a signature that is signed or attached to specific user ID information, and that the signature has been signed by the owner of the user ID. Note that it doesn't mean. In the exemplary embodiments described herein, for example, instead of the user himself signing the user's ID information, the first system (eg, website A) is the user ID information of the user (user C). It is preferable to sign.

  The above description, including the specification and drawings, is illustrative and not restrictive. By examining this disclosure, many different techniques will become apparent to those skilled in the art. Various features and aspects of the disclosure set forth above may be used separately or jointly. Further, the present disclosure may be utilized in any number of environments and applications beyond those described herein without departing from the broadest spirit and scope of the present specification. Accordingly, the scope of the present disclosure should not be determined with reference to the above description, but instead should be determined with reference to the appended claims, along with their full scope of equivalents. is there.

Claims (17)

Under the control of one or more computing devices comprising one or more processors,
Receiving a request for a first service, wherein the request includes a user ID associated with the second service, and wherein the user ID information includes user authentication information; When,
Verifying the request based on the user ID information and user ID mapping data associated with the first service and the second service, wherein the user ID mapping data is a user for the user; An information attribute and a privilege attribute, wherein the user information attribute includes account information associated with the first service and the second service, and the privilege attribute is assigned to the first service of the user. Verifying indicating a first resource access privilege of the user to access the first service between sessions established using associated user ID information;
In response to the verification, the user to access the first service based on a second resource access privilege assigned to the user to access the first service during a session Establishing the one session for a computing device associated with the first resource access privilege is higher than the second resource access privilege;
A method comprising the steps of:   The method of claim 1, wherein the user ID information is generated based on a user ID associated with the second service and the user ID mapping data. The first service includes payment of a transaction;
The second service includes a consumer-to-consumer (C2C) service of a transaction, and the second resource access authority restricts the payment of the transaction between the one session to the user. The method according to claim 1. Allowing the user to access the first service comprises:
The method of claim 3, comprising allowing the user to access one or more of the first services associated with the transaction.   The method of claim 1, wherein the request includes a signature including a time stamp. Authenticating the signature by comparing the time stamp of the user's previous signature with the time stamp of the signature;
6. The method of claim 5, further comprising: allowing a user associated with the user ID information to access the first service after authenticating the signature. One or more persistent computer-readable storage media storing computer-executable instructions that, when executed by one or more processors, perform the following operations, comprising:
Receiving a request for the first service, the request including a signature and user ID information associated with a second service, wherein the first service and the second service are Having a partnership for e-commerce, steps;
Verifying the request based on the user ID information and user ID mapping data associated with the first service and the second service;
Assigning resource access privileges for accessing the first service based on the user ID information;
Authenticating the signature by comparing the timestamp of the signature with the timestamp of the previous signature of the user;
Allowing a user associated with the user ID information to access the first service based on the resource access privilege;
A computer-readable recording medium comprising:   The computer-readable recording medium according to claim 7, wherein the user ID information is generated based on a user ID associated with the second service and the user ID mapping data. Receiving an additional request including an additional user ID associated with the first server for the first service by the server;
9. The computer readable record of claim 8, comprising: allocating an additional resource access privilege higher than the resource access privilege to access the first service based on the additional user ID. Medium.   The computer-readable recording medium of claim 7, wherein the resource access privilege is determined based on session information associated with the user recorded by the first service. The first service is associated with payment of a transaction;
The computer-readable medium of claim 7, wherein the second service comprises a consumer-to-consumer (C2C) service for trading.   Allowing the user to access the first service comprises allowing the user to access one or more portions of the first service associated with the transaction. The computer-readable recording medium according to claim 11, further comprising: One or more processors;
A memory that maintains a plurality of components executable by the one or more processors, and the plurality of components comprises:
An ID authentication unit,
Receiving a request for a first service, the request including a signature associated with a second service and the user ID information, wherein the first service and the second service are: Having a partnership for electronic commerce; authenticating the request based on the user ID information and user ID mapping data associated with the first service and the second service;
A privilege controller for allocating resource access privileges for accessing the first service based on the user ID information;
ID signature verifier
Authenticating the signature by comparing the time stamp of the signature with the time stamp of the user's previous signature;
Allowing the first service to the user associated with the user ID information based on the resource access privilege.   The method of claim 13, wherein the user ID information is generated based on a user ID associated with the second service and the user ID mapping data.   The method of claim 13, wherein the resource access privilege is determined based on session information associated with the user recorded by the first service. The first service is associated with payment of a transaction;
14. The method of claim 13, wherein the second service is associated with a consumer-to-consumer (C2C) service for the transaction.   Allowing the user to access the first service, allowing the user to access one or more portions of the first service associated with the transaction; The method of claim 16, comprising:

Images