The ability to access information over a network has been a boon to most users. That a user can access desired information from a remote location (possibly, even a location that the user could not locate or reach physically) has resulted in benefits to many.
But it remains important to be certain that the user accessing the resource is a legitimate user. To that end, users need to log in to the network and authenticate themselves. If they cannot identify themselves properly to the network, they are denied access to the network resources. This situation occurs when the Common Internet File System (CIFS) authentication is used, and is exemplified in the Network Attached Storage (NAS) architecture.
In many situations, the server to which the user connects is not the authentication source that actually authenticates the user. This adds a second level to the process, as the server must recognize the user before the user can even attempt authentication from the authentication source. For example, in FIG. 1 a user is logged in to client 105. Client 105 can be any type of computer system: desktop, laptop, thin client, dumb terminal, personal digital assistant (PDA), etc. Client 105 includes the appropriate components for its design. If client 105 is a desktop computer, client 105 includes a computer, monitor, keyboard, and mouse. The computer includes a central processing unit, memory, and other appropriate elements. Other components of client 105 can be present, such as a printer. A person skilled in the art will recognize other variations of client 105.
The user logs in to server 110 from client 105 via network 112. Network 112 can be any variety of network connection between client 105 and server 110. For example, network 112 can be a direct connection between client 105 and server 110, a wired network connection (such as Ethernet or token ring), a wireless connection (such as IEEE 802.11b, IEEE 802.11a, or Bluetooth®), or any other type of connection. Server 110 verifies that the user is listed in user list 115, which is part of server 110. If the user is not listed in user list 115, then server 110 denies the user permission to proceed with logging in. Otherwise, the server forwards the authentication request to authentication source 120 over network connection 122. Network connection 122 can be any variety of network connection, just like network connection 112. Further, there is no requirement that network connections 112 and 122 be of the same type. Once authentication source 120 has received the authentication request, authentication source 120 can authenticate the user.
Observe that server 110 can deny the user permission to log in if the user is not listed in user list 115, even though the user is capable of authenticating himself to authentication source 120. Other than verifying that the user is in user list 115, server 110 merely acts as a conduit for authenticating the user. In technical terms, the authentication is performed as pass-through authentication. That is, the authentication communications between client 105 and authentication source 120 pass through server 110.
User list 115 can be implemented using Novell Directory Service, a component of versions of Novell Netware. When using Novell Directory Service, the user information is stored in user objects in user list 115.
In FIG. 1, a user John Smith is attempting to authenticate himself. Authentication request 130-1 is sent from client 105 to server 110. Server 110 checks to see that John Smith is in user list 115. Since John Smith is listed in user list 115 as entry 125, the server forwards authentication request 130-2 to authentication source 120. Authentication source 120 responds with challenge 135-1, which server 110 forwards challenge 135-2 to client 105. Challenge 135-1 and 135-2 is a randomly generated number, that both client 105 and authentication source 120 can hash to another value (called a credential), without revealing the user's (secret) password. If the credential generated by the client agrees with the credential generated by authentication source 120, then the user is authenticated.
Client 105 responds with credential 140-1, which server 110 forwards as credential 140-2 to authentication source 120. Once credential 140-2 is verified, authentication source 120 can validate the user. Authentication source 120 then sends back response 145-1, in this case indicating that the user has been successfully authenticated. Server 110 forwards response 145-2 to client 105, and client 105 is then allowed access to the resources offered by server 110.
There are two major problems with the authentication process described in FIG. 1. First, the user must have a user object in user list 115. If there is no user object for the user in user list 115, server 110 prohibits pass-through authentication, even if the user could authenticate himself to an authentication source. Currently, adding a user to user list 115 requires an administrator to insert the user into user list 115. This manual step is time consuming and error prone.
Second, even if the user is listed in user list 115 on server 110, if authentication source 120 is unavailable, the user cannot be authenticated. There are numerous reasons why authentication source 120 might be unavailable. For example, authentication source 120 might not be operating. Or network connection 122 might be down, even though authentication source 120 is operating. A person skilled in the art will recognize other ways in which authentication source 120 might be unavailable. And even though server 110 is technically capable of performing the authentication of the user, because authentication source 120 is unavailable, the user cannot be authenticated.
Accordingly, a need remains for a way to add users to a user list on the server without requiring manual insertion of the user data, and to allow the server to authenticate a user when the authentication source is unavailable, to address these and other problems associated with the prior art.
USPTO Backgrounds
USPTO Backgrounds