WO2001052025A2

WO2001052025A2 - Accessing multiple services with a unique user name

Info

Publication number: WO2001052025A2
Application number: PCT/US2001/000249
Authority: WO
Inventors: Germano Caronni; Amit Gupta
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 2000-01-10
Filing date: 2001-01-04
Publication date: 2001-07-19
Anticipated expiration: 2002-07-10
Also published as: GB2375414B; GB2375414A; GB0217052D0; AU2001227601A1; WO2001052025A3

Abstract

A user may employ a common user name and a common password to gain access to multiple services. In a first approach, the user is permitted to select a user ID that is already assigned to at least one other user. The password chosen by the user, however, must be unique. In a second approach, an intermediary is provided for translating a generic user name and a generic password into a unique value for each respective service. The unique value may be derived from the generic user ID or from a combination of the generic user name, generic password and service identification.

Description

SHARING USER NAMES ACROSS MULTIPLE SERVICES

Technical Field

The present invention relates generally to services that are accessible via networks and more particularly to the sharing of user names across multiple services.

Background of the Invention

A wide variety of services are available on telecommunications networks or computer networks, such as the Internet. The services may be accessed by a large number of users, and a single user may wish to access a number of different services. Many of the services require the user to provide a user name and password to access the service. Unfortunately, it is not always possible for a user to use a common user name and password for all of the services. Oftentimes, a desired user name is already taken. For example, a user named Joe Smith may not be able to use "joesmith" as a user name because another Joe Smith is already assigned that user name. As a result, the user may be required to keep track of multiple respective user name/password pairs for respective services. This is quite cumbersome and may result in a user providing the wrong user name/password for a given service.

Summary of the Invention

The present invention addresses the above-described limitation of conventional systems by allowing a user to use a common user name across multiple services. In a first approach, the user is permitted to use a user name that is currently assigned to a different user. However, the password assigned to the user must differ from the password assigned to the other user that shares the user name. In a second approach, an intermediary is provided between a user and a service provider to translate the user name and password selected by the user into a unique value that is acceptable to the service provider. These approaches differ from approaches, such as Microsoft Passport, where a user name and password pair are stored in a profile and the profile is accessed to retrieve the pair for participating services. In accordance with one aspect of the present invention, an access regulating facility is provided for regulating access to a service via a network. The facility requires a valid user identification and a valid password from a user before the user is granted access to the service. A request is received from a first user to have a selected user identification and a selected password assigned to the first user. This user identification is already assigned to a second user. However, the selected password is not currently assigned to any other user. The request is granted by assigning the selected user identification and the selected password to the first user for use in gaining access to the service via the access regulating facility.

In accordance with a further aspect of the present invention, a generic user name and a generic password are provided for a user. A request is received at a computer system to establish a user name and password for the user at a service. An identifying token is generated for the user by manipulating the generic user name and the generic password. The identifying token may be generated by calculating a hash function value from the generic user name. The hash function value may be converted into printable characters to produce the identifying token. This method may be performed by an applet running in a web browser, a plug-in to a web browser, a proxy, a servlet or even a script.

Brief Description of the Drawings

An illustrative embodiment that is consistent with the principles of the present invention will be described below relative to the following drawings.

FIGURE 1 is a block diagram of a first alternative implementation for the illustrative embodiment.

FIGURE 2 is a flow chart illustrating the steps that are performed in the first alternative implementation to assign a user a user ID and password.

FIGURES 3 A and 3B illustrate a second alternative implementation of the illustrative embodiment. FIGURE 4 is a flow chart illustrating the steps that are performed in a second alternative implementation.

FIGURE 5A illustrates an instance wherein an intermediary is implemented as an applet at the client.

FIGURE 5B illustrates an example wherein the intermediary is implemented as a local proxy at the client.

FIGURE 5C illustrates an example in which the intermediary is implemented as a plug in to a web browser at the client.

FIGURE 6A illustrates an example where the intermediary is implemented as a proxy on the server.

FIGURE 6B illustrates an example where the intermediary is implemented as a servlet on the server.

FIGURE 6C illustrates an example wherein the intermediary is implemented by a script on the server.

FIGURE 7 shows an example wherein the intermediary is implemented as a repository on a separate device.

FIGURE 8 is a flow chart illustrating the steps that are performed in a second alternative implementation when the intermediary generates a unique user name/password pair.

FIGURE 9 is a flow chart illustrating the steps that are performed in the second alternative implementation when the intermediary generates an identifying token.

Detailed Description of the Invention

- j - The illustrative embodiment allows a user to use a single user name across multiple services. The user name assigned to the user may be shared by other users that access the services. In a first implementation, the user may be assigned a user name that is already assigned to another user for a service, but the user must be assigned a unique password for the service. Each service may have an access regulating facility that enforces these requirements. In a second implementation, an intermediary is provided to translate a generic user name and a generic password provided by the user to unique values for the services which the user wishes to access.

The services may be any of a number of different types of services. For example, the services may be web services that are accessible via the Internet, an extranet or an intranet. The services may be provided by a single shared computer system, a mail server, an FTP server or another type of server. The network that provides communications between the user and the service may be a computer network, a telecommunications network or even a wireless network.

For purposes of the discussion below, a "service" is a customer-based or user- oriented function. A "client" is a user or other entity for which services are provided by a service provider. An "intermediary" is an entity that mediates and/or processes communications between a client and a service provider.

Figure 1 is a block diagram illustrating a first alternative implementation of the illustrative embodiment. A user 10 uses a client system 12 to attempt to access a service provided by a service provider 16. An access regulating facility 14 controls access to the service provided by the service provider 16. The connections between the user 10, access regulating facility 14 and service provider 16 may be local connections or network connections. The client system 12 may be a computer system or other type of electronic device that allows a user to gain access to the service provided by the service provider. For example, the client may be a personal computer, a network computer, a personal digital assistant (PDA) or workstation. Moreover, the client 12 may be an intelligent appliance, a pager or even an intelligent telephone. The client possesses storage capacity that may be implemented using a number of different types of storage technology, including read only memory (ROM), random access memory (RAM), secondary storage media, such as optical disks, magnetic disks or other types of storage technologies.

In the exemplary case depicted in Figure 1 , the service provider 16 provides services via web pages, such as hypertext mark-up language (HTML) documents, extensible mark-up language (XML) documents, other mark-up language documents or other content. As such, the client 12 includes a web browser 18 for receiving and interpreting such documents.

As mentioned above, the access regulating facility 14 controls access to the service provided by the service provider 16. The access regulating facility 14 requires a user to provide a user identification (ID) and a password before service is granted to the user. A table, database or other compilation of user IDs and passwords 19 is stored at the access regulating facility 14 or is stored remotely but is accessible to the access regulating facility. The access regulating facility 14 may be implemented in software as a software facility or in hardware. The service provider 16 may be a dedicated computer system, such as a server, that provides services or a process on a computer system that runs other processes. The service provider 16 may be, for example, a web server, FTP server, a mail server, a time-shared computer system, a server form, or a collection of services available by portal.

Figure 2 is a flow chart illustrating the steps that are performed to assign a user ID and password in the first alternative implementation of the illustrative embodiment. Initially, the user chooses a desired user ID and password (step 30 in Figure 2). For purposes of the discussion below, the phrase "user ID" and the phrase "user name" will be used interchangeably. The user ID 20 and password 22 are forwarded from the client 12 to the access regulating facility 14. The access regulating facility 14 compares the user ID 28 and password 22 with the other user IDs and passwords 19 that have already been assigned to other users. A determination is made whether there are any matching user ID/password pairs that match those provided by the user 10 via client 12 (step 32 in Figure 2). The prohibited passwords (see step 33 in Figure 2) need not be limited strictly to those that are currently assigned but may also be restricted to those that have been assigned to users with like user IDs over a predetermined period of time (e.g. in the last six months). If there are no matching user ID/password pairs, the user ID 20 and password 22 selected by the user are assigned to the user by the access regulating facility 14 (step 34 in Figure 2). Response 24 advises the user of the acceptance of the user ID/password pair. The user 10 may subsequently use the assigned user ID and password to access the service provided by the service provider 16.

If, in contrast, there is a matching user ID/password pair (see step 32 in Figure 2) the user 10 is sent a response 24 that advises the user to select another password (step 36 in Figure 2). The user then chooses a new password that is forwarded via the client 12 to the access regulating facility 14 (step 38 in Figure 2). The process is repeated beginning at step 32 until a non-matching user ID/password pair is found. Those skilled in the art will appreciate that other passwords may be prohibited, such as passwords that are excessively short, easily guessed or those that meet other criteria.

Figure 3 A illustrates an example of a second alternate implementation in which an intermediary is used to translate a user name and password into information that is unique to a service. In Figure 3 A, a client 40 is used by a user 10 to attempt to gain access to a service provided by a server 44. The client 40 and the server 44 may be any of a number of different devices such as described above for the client 12 and service provider 16 described with reference to Figure 1. The user 10 chooses a generic user name 46 and a generic password 48 for use with all services. The client 40 forwards the generic user name 46 and generic password 48 to an intermediary 42 along with a server ID 50 that identifies the server 44 to which the user wishes to gain access. The server ID 50 may be, for example, a uniform resource locator (URL) The client 40 may also optionally forward a key generation token 52 that is used to generate a unique user name/password pair 54 such that two parties names "Joe Smith" with the same password accessing a service get a different username/password pair for the service. The token 52 is randomly chosen and influences the generation of the per service user/name password pairs. In the example case depicted in Figure 3 A, the intermediary 42 receives the generic user name 46, the generic password 48, the server ID 50 and, optionally, the key generation token 52. The intermediary 42 produces a unique user name/password pair 54 that is forwarded to the server 44 along with the password 56 so that the user 10 may gain access to the service provided by the server. The details of the process performed by the intermediary and the protocol will be set forth in more detail below.

Figure 4 is a flow chart that provides an overview of the steps that are practiced with the second implementation to access a service. The user chooses a generic user ID and a generic password (step 64 in Figure 4). The generic user ID and the generic password are used to access multiple services by way of the intermediary 42 (step 66 in Figure 4).

Those skilled in the art will appreciate that the intermediary 42 may take many different forms. The intermediary 42 may be implemented on the client 40, on the server 44 or on a separate dedicated repository device. When the intermediary 42 is implemented on the client 40, there are a number of implementation options. First, the intermediary may be implemented as an applet that runs on a web browser 70 on the client 40, as shown in Figure 5 A. Alternatively, the intermediary may be implemented as a local proxy 74 that interacts with the web browser 70 on the client 40, as shown in Figure 5B. Another alternative is for the intermediary to be a plug-in 76 to a web browser 70 at the client, as shown in Figure 5C. Those skilled in the art will appreciate that other alternative implementation options are available for implementing the intermediary at the client.

As mentioned above, the intermediary may be implemented on the server 44 rather than on the client 40. The intermediary may be implemented as a proxy 80 at the server 44, as shown in Figure 6A. The intermediary may also be implemented as a servlet 82 at the server 44, as shown in Figure 6B. Still further, the intermediary 84 may be implemented as a script, such as a CGI -bin script, as shown in Figure 6C. Those skilled in the are will appreciate that additional implementation options on the server may be used to implement the intermediary in the present invention.

The intermediary 92 may also be implemented on a repository 90. The repository 90 is a separate device that is distinct from the client 40 and the server 44. The repository 90 may be, for example, a computer system on which the intermediary 92 runs. Figure 8 illustrates a flow chart of the steps that are performed for the second alternative implementation as depicted in Figure 3 A. Initially, the user 10 registers a generic user name and a generic password with the intermediary 42 (step 100 in Figure 8). The user 10 may optionally provide a key generation token at the time of registration. When the user wishes to access a service provided by the server 44, the user 10 provides the generic user name 46 and generic password 48 to the intermediary 42 along with server ID 50 (step 104 in Figure 8). The intermediary generates a unique value 54 from the provided information (step 106 in Figure 8). The unique value 54 is forwarded along with a password 56 to the server 44 to access the service (step 108 in Figure 8).

The unique value 54 may be generated by taking a hash of the generic user name 46 and the server ID 50. A suitable hash function is the MD5 hash function. Those skilled in the art will appreciate that a number of different hash functions may be utilized. The hash function value of the results may be converted into printable characters to form the user name/password pair 54. For example, the output from the hash algorithm may be printed as hexadecimal digits. Alternatively, for every six bits of output, a single letter uu-encoded may be output.

Figure 3B illustrates another case for the second alternative implementation where the intermediary 42 produces an identifying token 60 rather than the unique value 54. The identifying token 60 is passed without passing a password 48 in contrast to the case depicted in Figure 3A. Figure 9 is a flow chart illustrating the steps that are performed in such a case. Steps 100 and 104 are like those described above relative to Figure 8. In step 110, however, the intermediary 42 generates an identifying token 60. This identifying token 60 is sent to the server 44 without the need for sending the password 48 to the server (step 112 in Figure 9). The identifying token 60 is created by taking the hash of the generic user name 36, the generic password 48, the server ID 50 and the key generation token 52. The resulting value is converted into printable characters to form the identifying token 60. Since the generic password 48 is integrated into the identifying token 60, there is no need to send the identifying token separately. While the present invention has been described with reference to an illustrative embodiment thereof, those skilled in the art will appreciate that various changes in form and detail may be made without departing from the intended scope of the present invention as defined in the appended claims.

Claims

1. In a computer system, a method, comprising: providing an access regulating facility for regulating access to a service, wherein said access regulating facility requires a valid user identification and a valid password from a user before the user is granted access to the service; receiving a request from a first user to have a selected user identification and a selected password assigned to the first user, wherein the selected user identification is already assigned to a second user and the selected password is unassigned to any other user; and granting the request by assigning the selected user identification and the selected password to the first user for use in gaining access to the service via the access regulating facility.

2. The method of claim 1 wherein the computer system is a server.

3. The method of claim 2 wherein the computer system is a web server.

4. The method of claim 1 wherein the selected password is different from any password that has been assigned to the second user within a given time frame.

5. The method of claim 1 wherein the first user accesses the service over the Internet.

6. The method of claim 1 wherein the user accesses the service over a telephone network.

7. In a computer system where a user wishes to access a service, a method, comprising: receiving a generic user name and a generic password for a user; receiving a request to establish a user name and a password for the user at the service; and generating an identifying token for the user by manipulating the generic user name and generic password.

8. The method of claim 7 wherein the identifying token is generated by calculating a hash function value from the generic user name and the generic password.

9. The method of claim 8 wherein the identifying token is generated by converting the hash function value into printable characters.

10. The method of claim 8 wherein the identifying token is passed to the service as a valid user name.

11. The method of claim 7 further comprising the step of passing the generic password to the service along with the identifying token.

12. The method of claim 7 wherein the service is provided by a server having a server identification and wherein the identifying token is generated by calculating a hash function value from the generic user name, the generic password and the server identification.

13. The method of claim 12 wherein the server identification is a uniform resource locator (URL).

14. The method of claim 12 wherein the server identification is an Internet Protocol (IP) address.

15. The method of claim 7 wherein the method is performed by an applet running in a web browser.

16. The method of claim 7 wherein the method is performed by a plug-in to a web browser.

17. The method of claim 7 wherein the method is performed by a proxy.

18. The method of claim 7 wherein the method is performed by a servlet.

19. The method of claim 7 wherein the method is performed by a script.

20. A computer system, comprising: an access regulating facility for regulating access to a service, wherein the access regulating facility requires a valid user identification and a valid password from a user before the user is granted access to the service, said access regulating facility comprising: (i) means for receiving a request from a first user to have a selected user identification and a selected password assigned to the first user, wherein the selected user identification is already assigned to a second user and the selected password is not assigned to any other user; and (ii) means for granting the request by assigning the selected user identification and the selected password to the first user for use in gaining access to the service via the access regulating facility.

21. The computer system of claim 20 wherein the computer system is a server.

22. The computer system of claim 20 wherein the computer system is an intermediary between a client and a server.

23. The computer system of claim 20 wherein the computer system is a client that seeks to access the service, which is provided by a server.