US10757104B1 - System and method for authentication in a computing system - Google Patents

Abstract

A system and method for efficiently accessing Web resources. A directory service and an authentication service may be used to determine whether a login session attempt on a deployed device is successful. At least one deployed device in a system receives credentials from a user during a login request and requests authorization using the received credentials for both a login session and for accessing Web resources. The device sends the authorization request to Web services on a server hosting the Web resources. The Web services interact with an authentication service to verify authentication for the user. The device receives an access token upon verification for authorization for the given user and securely stores it. When a client program executing on the device requests access to the Web resources, the device sends an access request with a copy of the stored access token to the server hosting the Web resources.

Description

BACKGROUND OF THE INVENTIONField of the Invention

This invention relates to the field of secure network communication and, more particularly, to efficiently accessing web resources for client applications.

Description of the Related Art

As computer memory storage and data bandwidth increase, so does the amount and complexity of data that business and industry manage each day. Data management operations capable of creating, capturing, storing, distributing, protecting and consuming information become complex as the data size grows. In addition, data management operations, such as operations used in enterprise information management, provide regulatory compliance. Regulatory compliance ensures the accuracy and completeness of data contained in files, reports and other data structures as well as consistent data across the enterprise.

Different types of servers are deployed across the enterprise to provide these operations. These servers may be used in a data center, in a remote or branch office, and in virtual environments. For example, the environment may use multiple servers to provide Web-based or Cloud-based applications to end users. These types of applications reside on remote servers rather than on local machines or local communication devices. These applications may not consume an appreciable amount of storage space, if any, on local machines or communication devices and provide the interactivity of a local desktop or local on-machine application while being portable. Maintenance of the applications may occur at a single remote location.

The data being managed in the enterprise or small business environment may be partitioned into web resources, which are accessed, modified, moved, removed and so on by at least Web-based applications and Cloud-based applications. The Web resources may include files, documents, storage volumes, and any other target of a Web-based identifier. The Web-based identifier may include a uniform resource locator (URL), a uniform resource identifier (URI), an internationalized resource identifier (IRI), and the like.

Accessing the Web resources typically includes authorization steps to provide security. A trusted authentication service performs this security measure. A given user provides credentials which are sent to the authentication service for verification. Each time the given user executes a client application requesting access to Web resources in the environment, the client application again prompts the given user for the credentials. Alternatively, each time the given user executes a non-interactive process, such as batch jobs through a scripting language, requesting access to the Web resources in the environment, the non-interactive process does not prompt for the credentials and accordingly fails to obtain access as authentication fails.

In view of the above, improved systems and methods for efficiently accessing web resources for client applications are desired.

SUMMARY OF THE INVENTION

Systems and methods for efficient access of Web resources are contemplated. In various embodiments, a device is deployed among multiple devices in a business environment, such as a relatively small business environment or alternatively a large enterprise environment. In some embodiments, the devices may be purpose-built backup appliances (PBBAs). The PBBA may also be referred to as a storage appliance. In other embodiments, the device is a backup server. The environment may include a directory service and an authentication service. In some embodiments, each of the directory service and the authentication service is on a separate corresponding server. In addition, the environment may include Web resources on one of these servers or on a separate Web server.

Connections between the devices and between the servers and the devices may include wireless connection, direct local area network (LAN) connections, wide area network (WAN) connections such as the Internet, a router, transmission control protocol/internet protocol (TCP/IP) hardware and/or software, and so forth. One or more of the servers and the deployed devices may be located locally onsite, remotely at another site or branch office, or accessed through a cloud-based network.

In various embodiments, one or more of the deployed devices receives credentials corresponding to a login request from a given user for a login session (e.g., a secure shell session). During login authorization, the device uses the received credentials to request authorization for creating both the login session and for accessing Web resources through a Hypertext Transfer Protocol (HTTP) session on the device. In various embodiments, the device sends an authorization request with the credentials to Web services on a Web server. The Web services interact with an authentication service to determine whether the given user is authorized to have the login session and the HTTP session.

The device then receives an access token from the Web services upon verifying authorization for the given user and stores the access token. When a client program executing on the device requests access to Web resources, the user is not prompted for credentials to gain access. Rather, the device sends an access request with a copy of the stored access token to the server hosting the Web resources.

These and other embodiments will be appreciated upon reference to the following description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a generalized block diagram illustrating one embodiment of device authorized access.

FIG. 2 is a generalized block diagram illustrating another embodiment of device authorized access.

FIG. 3 is a generalized block diagram illustrating one embodiment of software components on the device.

FIG. 4 is a flow diagram illustrating one embodiment of a method for efficiently accessing Web resources.

While the invention is susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the invention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth to provide a thorough understanding of the present invention. However, one having ordinary skill in the art should recognize that the invention might be practiced without these specific details. In some instances, well-known circuits, structures, signals, computer program instruction, and techniques have not been shown in detail to avoid obscuring the present invention.

Referring toFIG. 1, a generalized block diagram of one embodiment of device authorizedaccess100 is shown. In the embodiment shown, asingle device110 is connected to at leastservers160 and170. However, in various other embodiments, multiple devices are connected to theservers160 and170 and connected to one or more other devices. The other multiple devices are not shown for ease of illustration. As shown, the server160 includes auser authentication service162, which may also be referred to as anauthentication service162 or an authorization service.

In some embodiments, a user directory service (not shown) is also used along with theauthentication service162 during a login process by a user attempting to gain login access to thedevice110. In some embodiments, each of the user directory service and theauthentication service162 executes on a same server. In other embodiments, the user directory service and the authentication service execute on separate servers. In various embodiments, the login request may be conveyed to thedevice110 from anothercomputing device102. The login request may include credentials such as at least a username and a password.

One or more of theservers160 and170 may be a local server. Alternatively, one or more of theservers160 and170 may be a remote server. In other embodiments, one or more of the user directory service and theauthentication service162 is a cloud-based application.

In some embodiments, thedevice110 is a type of storage, such as a disk storage, a backup server, a Network-Attached Storage (NAS) device, a Storage Area Network (SAN) device, or other. In other embodiments, thedevice110 is a purpose-built backup appliance (PBBA). The PBBA may also be referred to as a storage appliance. Typically, storage appliances are a server based on common-used and certified server-hardware sold together with software, wherein the hardware and the software are provided by a single vendor. The storage appliance may include the server, data storage, an operating system, backup software and deduplication software. The all-in-one approach for the storage appliance may lead to relatively quick install (deploy) times. The storage appliance may provide storage, enable storage on another appliance or another storage medium, and/or provide deduplication for both physical systems and virtual systems.

The storage appliances typically provide data storage with capacities between 4 terabytes (TB) and 500 TB. As a result, the storage appliances may replace tape-based backup and recovery processes. In other environments, such as enterprise environments and mainframe environments, the storage appliances may be deployed alongside tape-based systems. The storage appliances may be used for cloud-based storage or on premise storage.

In yet other embodiments, thedevice110 is a server unlike the storage appliance as the server may not be shipped with installed software from a single vendor. In various embodiments, theuser computing device102 is a laptop, a desktop, a tablet, another server, or other computing device able to connect to thedevice110. The connections between theuser computing device102, thedevice110 and theservers160 and170 may include a variety of techniques including wireless connection, direct local area network (LAN) connections, wide area network (WAN) connections such as the Internet, a router, may further include remote direct memory access (RDMA) hardware and/or software, transmission control protocol/internet protocol (TCP/IP) hardware and/or software, router, repeaters, switches, grids, and/or others. As described earlier, each of thedevice110 and theservers160 and170 may be located onsite or may be cloud-based.

As shown, a sequence of steps are used to describe a user gaining authenticated use of thedevice110 and gaining authenticated access of theweb resources172. The environment using at least theuser computing device102, thedevice110, and theservers160 and170 may utilize Web-based applications and Cloud-based applications to manage data. In some embodiments, theclient program150 is a Web-based backup and recovery application. Alternatively, theclient program150 is a Web-based application that creates, modifies and removes volumes. In addition, theclient program150 may create, mount and share a file system.

Generally speaking, Web resources are software components, artifacts, or data and metadata used by Web-based and Cloud-based applications for creating, modifying, rendering, removing, reading and so forth. The Web resources may include files, documents, storage volumes, and any other target of a Web-based identifier. The Web-based identifier may include a uniform resource locator (URL), a uniform resource identifier (URI), an internationalized resource identifier (IRI), and the like. Web resources are typically collected in a location such as in a subdirectory of a root directory for the Web-based application. In some examples, the subdirectory may be indicated as resources/resource-identifier.

Web resource identifiers are unique strings conforming to a given format such as [locale-prefix/][library-name/][library-version/]resource-name[/resource-version]. Taking the use of URLs as an example, the Web resource URL is an address that theclient program150 uses to access the Web resource. In the case that the Web resource is a backup server connected to a backup and recovery application, the corresponding address may use a format such as http://localhost:9399/api/backupServers/79460354-e7c8-6df2-45a7-01df2bcd9b2a. The format includes a base URL and a Web resource location.

Here, the base URL is an entry point to the backup and recovery application's RESTful API, which is further described shortly. The base URL in this example is http://localhost:9399/api/. The string “localhost” is the machine's name where the backup and recovery application is installed. For example, this string may identify thedevice110 in the example shown inFIG. 1. The string “9399” is a port used to communicate with REST APIs associated with a Web service onserver170 used to access theWeb resources172 in the example shown inFIG. 1.

The Web resource location in the above example is /backupServers/79460354-e7c8-6df2-45a7-01df2bcd9b2a. The Web resource location identifies the path to the Web resource itself in the backup and recovery application's RESTful API. The Web resource location is suffixed to the base URL, forming the URL for the Web resource. The Web resource location may include a uniform resource name (URN). Both URL and URN are uniform resource identifiers (URIs). However, the URN is also associated with uniform resource characteristics (URC), which allows a user to add descriptive information associated with the Web resource in the URN such as an author name, a timestamp, a data size, and so forth. Additionally, the URN may include an entity identifier (ID), or key, that uniquely identifies the Web resource. In the above example, the key is 79460354-e7c8-6df2-45a7-01df2bcd9b2a. For the example of a name, accessing a collection of jobs, such as jobs setup for a given batch, may be identified by the URN/jobs7. The complete URL may be http://localhost:9399/api/jobs7.

The key value in the above example may remain valid for identifying an associated Web resource only during the time of the backup and recovery application's RESTful API work session. The application's RESTful API work session, or the work session for theclient program150 in the example, may also be referred to as a Hypertext Transfer Protocol (HTTP) session. The HTTP session is an authenticated and interactive session between the HTTP client (client program150) and the HTTP server (server170). The HTTP protocol is used for data communication on the World Wide Web, which is also referred to as “Web” or “web”. The Web is an information system of interlinked hypertext documents (Web pages) and other digital resources, such as the above Web resources, that are accessed via the Internet.

In various embodiments, the machine-to-machine (client-server) data communication, which is maintained by processes known as Web services, between thedevice110 and theserver170 over a network, such as the Internet, may allow manipulation of theWeb resources172 using a set of stateless operations. TheWeb services174 are the processes executing on theserver170 communicating with at least thedevice110. The Web application programming interface (API) used in this data communication may use relatively simple simpler representational state transfer (REST) based communication. An API that uses REST is referred to as a RESTful API. A RESTful API breaks down a transaction to create a series of smaller transactions, each of which performs a particular underlying function of the full transaction. This modularity provides developers with flexibility.

The REST architectural style is used by Web APIs within Web browsers. With an increase in the use of Web-based applications and Cloud-based applications, various APIs, such as RESTful APIs, are emerging to expose Web services. RESTful APIs communicate over the Hypertext Transfer Protocol (HTTP) with HTTP verbs or methods. The HTTP methods (verbs) indicate the action to be performed on an identified Web resource. The Web resource may represent pre-existing data. Alternatively, the Web resource may represent dynamically generated data. The HTTP/1.0 specification defines the HTTP methods (verbs) GET, POST and HEAD. The HTTP/1.1 specification further defines the HTTP methods (verbs) OPTIONS, PUT, DELETE, TRACE and CONNECT.

In various embodiments, thedevice110 provides a command line interface (CLI) for the user on thecomputing device102. The CLI provides a manner to repetitively execute a number of tasks in a fixed sequence as a batch job on thedevice110. When the batch job utilizes conditional code, scripting may be used with the languages Java, Perl, Python and so forth. The CLI commands may be entered interactively by the user or passed to the CLI in files. Thedevice110 may provide the cURL (“see” URL) command line tool for retrieving, sending and modifying files and other data using the URL syntax. The cURL tool uses libcurl library, which is a client-side URL transfer library. This library supports multiple communication protocols including HTTP and credential authentication such as user-plus-password authentication. The cURL commands may allow a secure shell (SSH) session on thedevice110 to access theWeb services174 on theserver170.

As shown inFIG. 1, a sequence of steps illustrate a user on thecomputing device102 using aclient program150 on thedevice110 to access theWeb resources172 on theserver170. For purposes of discussion, the sequence steps in this embodiment are shown in sequential order. However, some sequence steps may be performed concurrently. Insequence 1, the user sends a login request from thecomputing device102 to thedevice110. In various embodiments, the login request includes at least a username and a password as credentials. Responsive to thedevice110 receiving the login request, a separate request may be sent from thedevice110 to the user directory service (not shown) to verify a username or other identifier associated with the given user. The user directory service verifies whether the provided identifier identifies a valid user for thedevice110 and sends a corresponding reply to thedevice110. It is noted that while the present description describes a particular sequence for purposes of convenience, in various embodiments the order of the steps occurring may differ. Additionally, other steps may be include that are not shown, and in some embodiments some steps may be combined and some may be eliminated. All such embodiments are contemplated.

In addition, the user directory service may provide user role information to thedevice110. The user role information may include a user role, such as a system administrator or a normal user; and privileges and permission for the user. The user directory service may provide the user role information during the verification of the existence of the user for thedevice110. Alternatively, the user directory service may provide the user role information at a later time, such as during a second request after the user has been authenticated by theauthentication service162. Examples of the user directory service include Microsoft Active Directory, Linux Network Information Service (NIS), the Apache Directory, and so forth.

Responsive to receiving an indication indicating the user's credentials are verified as identifying an existence of the user for thedevice110, insequence 2, thedevice110 sends a request for authentication to theauthentication service162 on the server160. In other embodiments, theauthentication service162 executes on a same server as the user directory service. In some embodiments, theauthentication service162 is integrated with the user directory service. In yet other embodiments, theauthentication service162 is a Cloud-based application. In yet other embodiments, two or more of the user directory service, theauthentication service162, another authentication service for authenticating access of theWeb resources172, theclient program150 and theWeb resources172 are located on a same device or server. Theauthentication service162 determines whether credentials, such as a password, provided by the user during the login attempt to thedevice110 matches a stored authorized password for the user.

The request insequence 2 to theauthentication service162 may include an encrypted version of the password provided by the user during the login request to thedevice110. Thedevice110 may use a secure socket layer (SSL) to send the request to theauthentication service162. In some embodiments, a successful verification of authorized access for the user indicated in a response insequence 3 from theauthentication service162 allows thedevice110 to retrieve user role information for the user and to create a login session for the user. Some server-side Web application frameworks for implementing theauthentication service162 includes Microsoft ASP.NET, Kerberos Authentication Service, SafeNet Authentication Service, and so forth. In addition, the framework Spring Security may be used to provide features in enterprise applications such as theauthentication service162.

Insequence 4, it is detected that theclient program150 wants to access theWeb resources172. For example, theclient program150 executes a cURL command that includes a HTTP method (verb) identifying at least one of theWeb resources172. In response to this detection, in sequence 5, a transaction is sent to theWeb service174 requesting access of theWeb resources172. Without a valid access token, theWeb services174 initiates verification of the authenticity of the user. However, without credentials, theWeb services174 is unable to send a request to theauthentication service162.

Insequence 6, theWeb services174 sends a request for the user's credentials. The user may be prompted to provide credentials for accessing theWeb resources172. For example, a login window may be presented to request at least a username and a password. Insequence 7, the user-provided credentials are sent from thedevice110 to theWeb services174. Although the user is already verified as an authenticated user for thedevice110 and has a currently running login sessions, such as a secure shell (SSH) session, the user is still prompted to provide credentials for access of theWeb resources172.

Insequence 8, a request is sent from theWeb services174 on theserver170 to theauthentication service162 on the server160. The request includes at least the credentials provided by the user. In various embodiments, the credentials may be encrypted and a copy of the encrypted values is included with the request sent from theWeb services174 to the authentication services162. In some embodiments, thesame authentication service162 is used for authenticating the login on thedevice110 and for authenticating access of theWeb resources172 on theserver170. In other embodiments, different authentication services may be used where the services are located on different servers. For example, a first authentication service may be used for authenticating the login on thedevice110, such as theauthentication service162 on the server160. A second authentication service may be used for authenticating access of theWeb resources172 on theserver170. The second authentication service may be located on theserver170 or another server (not shown).

In the embodiment shown, the authentication service for authenticating access of theWeb resources172 is located on server160. Therefore, thesequences 8 and 9 are between theserver170 and the server160. In other embodiments where the authentication service for authenticating access of theWeb resources172 is located on another server, thesequences 8 and 9 would be between theserver170 and the other server. The request insequence 8 to theauthentication service162 may again include an encrypted version of at least the username and the password provided by the user.

Responsive to verifying authorized access of theWeb resources172 for the user, insequence 9, a response indicating that the authorized access is verified is sent from theauthentication services162 to theWeb services174. An access token is generated for the HTTP session to be created on thedevice110. When created on thedevice110, the HTTP session may be accessed with cURL commands executed by theclient program150 on thedevice110. The access token may also be referred to as a session identifier (ID) for the HTTP session. The purpose of the access token is to allow theclient program150 to send authenticated requests from thedevice110 for accessing theWeb resources172 on behalf of the user using thecomputing device102. In some embodiments, the authentication service generates the access token. In other embodiments, theWeb services174 generates the access token responsive to receiving an indication that the authorized access is verified.

The access token may have a finite lifetime, such on the order of minutes or hours. Responsive to detecting the access token expires, attempts to further use the access token fail. A new access token needs to be obtained. Insequence 10, the generated access token is sent from theserver170 to thedevice110. In various embodiments, the access token is protected against interception through the use of a secure socket layer (SSL).

Responsive to receiving the access token, thedevice110 has or establishes an HTTP session. The HTTP session executes on thedevice110 with the login session, such as the SSH session that was created earlier in sequences 2-3. Insequence 11, a request or transaction is sent from thedevice110 to theserver170. The request uses a communication protocol such as the RESTful API protocol. TheWeb resources172 are accessed by the authenticated request, wherein the authenticated request includes a copy of the access token. The request may include an encrypted copy of the access token. The designated command, or HTTP method (verb), included in the request is executed on the Web resource of theresources172 identified in the request. Although not shown, a corresponding response is sent from theserver170 to thedevice110.

In various embodiments, sequences 5-11 may be repeated and the user prompted for credentials, such as insequence 6. For example, the sequences 5-11 may be repeated each time theclient program150 executes commands that access theWeb resources172. In other examples, the sequences 5-11 may be repeated each time an obtained access token expires, which may be on the order of minutes. Alternatively, each time the given user executes a non-interactive process, such as batch jobs through a scripting language, requesting access to the Web resources in the environment, the non-interactive process does not prompt for the credentials and accordingly fails to obtain access as authentication fails.

Turning now toFIG. 2, a generalized block diagram of another embodiment of device authorizedaccess200 is shown. Circuitry and logic described earlier are numbered identically. In various embodiments, thedevice210 may be a purpose-built backup appliance (PBBA) similar to thedevice110 described earlier. The PBBA may also be referred to as a storage appliance. In other embodiments, thedevice210 is a server. Thedevice210 may process a login request differently than the previous description for thedevice110. Similar to the authorizedaccess100 shown inFIG. 1, a sequence of steps are used inFIG. 2 to describe a user gaining authenticated use of thedevice210 and gaining authenticated access of theweb resources172. As shown,sequence 1 is the same assequence 1 in the authorizedaccess100 descried earlier. Here, though, theprevious sequence 7 replacessequence 2. Thedevice210 includes a pluggable authentication module (PAM)240 that sends an authentication request to theWeb services174 before a login session, such as a secure shell (SSH) session, is created.

Responsive to receiving the user login request from thecomputing device102, thedevice210 may use the received credentials for authenticating two sessions: the login session on thedevice210 and the HTTP session on thedevice210 for accessing Web resources. Although, no detection for an access of theWeb resources172 by theclient program150 has yet occurred, thedevice210 may use the received credentials for the login session to authenticate both the login session and the HTTP session.

In thecurrent sequence 2, the user-provided credentials are sent from thedevice210 to theWeb services174. In thecurrent sequence 3, a request is sent from theWeb services174 on theserver170 to theauthentication service162 on the server160. The request includes at least the credentials provided by the user. The credentials may be encrypted and a copy of the encrypted values is inserted in the request sent from theWeb services174 to the authentication services162.

Thecurrent sequence 3 is similar to theprevious sequence 8 described earlier for the authorizedaccess100. As described earlier, in some embodiments, thesame authentication service162 is used for authenticating the login on thedevice210 for the user and for authenticating access of theWeb resources172 on theserver170 for the user. In other embodiments, different authentication services are used.

When different authentication services are used, theWeb service174 may simultaneously send two requests, one request for each authentication service. Alternatively, theWeb service174 may send a first request to the authentication service for authenticating the user for the login session. In some embodiments, theWeb service174 may initially send a request to a user directory service as described earlier. Responsive to receiving a response indicating the user exists for thedevice210, theWeb service174 may send a request to the authentication service for authenticating the user for the login session as described earlier. Responsive to receiving a response indicating the authentication is successful, theWeb service174 may send a second request to the authentication service for authenticating the user for the HTTP session. In both cases, each of the requests sent to authentication services may again include an encrypted version of at least the username and the password provided by the user.

Thecurrent sequence 4 may be similar to theprevious sequence 9 with some changes. For example, in thecurrent sequence 4, responsive to a successful verification of authorized access for the user to login todevice210 and to gain access to theWeb resources172, theauthentication service162 allows thedevice210 to retrieve user role information for the user and an access token is generated for the HTTP session. In some embodiments, the authentication service generates the access token. In other embodiments, theWeb services174 generates the access token (e.g., responsive to receiving insequence 4 the response indicating the authorized access is verified). Various such embodiments are possible and are contemplated.

In sequence 5, the generated access token is sent from theserver170 to thedevice210. In various embodiments, the access token is protected against interception through the use of a secure socket layer (SSL). Responsive to receiving the single access token from theserver170, thedevice210 generates two sessions for the user based on the single login request: a login session, such as an SSH session, and an HTTP session. Thedevice210 securely stores the access token and allows the access token to be used for the established HTTP session for the user. Should the same user establish another HTTP session, the access token obtained in sequence 5 would not be available for the other HTTP session.

Thecurrent sequence 6 may be the same as theprevious sequence 4, wherein it is detected that theclient program150 wants to access theWeb resources172. Here, thedevice210 already has the access token. Accordingly, insequence 7, thedevice210 sends an access request or transaction to theserver170. The access request uses a communication protocol such as the RESTful API protocol and includes the access token.

Referring now toFIG. 3, a generalized block diagram of the software components300 of the device is shown. Thedevice210 includes multiple software components such as at least an operating system (OS)120, aweb service130, ashell service132, a pluggable authentication module (PAM)240, a name service switch (NSS)module142, and a directoryprotocol configuration file144. TheOS120 may be representative of any of a variety of specific operating systems, such as, for example, Symantec Appliance Operating System, Linux, or Sun Solaris. As such, the operating system may be operable to provide a software framework operable to support the execution of various programs such as deduplication, automatic backup, recovery and shell session or web-based browser session creation for authorized users, such as system administrators.

Theshell process132 provides a secure shell (SSH) user interface for accessing services of theOS120. Theshell service132 provides a command-line interface (CLI) to the services of theOS120 and other software applications on thedevice210. When a user opens a secure shell (SSH) session and successfully logs in as an authorized user, the authenticatedshell session152 is provided to the user. Thesession152 may be a CLI providing a manner to repetitively execute a number of tasks in a fixed sequence as a batch job on thedevice210. When the batch job utilizes conditional code, scripting may be used with the languages Java, Perl, Python and so forth. The CLI commands may be entered interactively by the user or passed to the CLI in files. The authenticatedshell session152 may be provided on a local monitor onsite with thedevice210. Alternatively, the authenticatedshell session152 may be provided on a remote monitor offsite when the user remotely logs in to thedevice210.

Theweb service130 may be any one of available internet World Wide Web browsers, such as Firefox, Internet Explorer, Google Chrome, and Safari. Theweb service130 may be used to provide a graphical user interface (GUI) to the services of theOS120 and other software applications on thedevice210. When a user opens a particular web page and successfully logs in as an authorized user, the authenticated browser session is provided to the user. The authenticated browser session may be provided on a local monitor onsite with thedevice210. Alternatively, the authenticated browser session may be provided on a remote monitor offsite when the user remotely logs in to thedevice210. The GUI authenticated browser session may provide an easy-to-use interface for the user. As is well known to those skilled in the art, the GUI authenticated browser session may lack sufficient support for efficient automated operation sequences, such as sending batch jobs.

As shown, thedevice210 is connected to a user directory service also referred to as simply a directory service. As described earlier, the directory service allows the sharing of information about users, systems, networks, services, and applications throughout a given network or a given work environment. The directory service may determine the existence of a given user in the work environment. For example, when a user attempts to login to thedevice210, a request may be sent to the directory service to verify a username or other identifier associated with the given user. The directory service verifies whether the provided identifier identifies a valid user for thedevice210 and sends a corresponding reply to thedevice210.

In addition, the directory service may provide user role information to thedevice210. The user role information may include a user role, such as a system administrator or a normal user; and privileges and permission for the user. The directory service may provide the user role information during the verification of the existence of the user for thedevice210. As described earlier, the authentication service determines whether credentials, such as a password, provided by a given user during a login attempt to thedevice210 matches a stored authorized password for the given user. Some server-side Web application frameworks for implementing theauthentication service162 includes Microsoft ASP.NET, Kerberos Authentication Service, SafeNet Authentication Service, and so forth. In addition, the framework Spring Security may be used to provide features in enterprise applications such as the authentication service.

Each of the directory service and the authentication service may follow an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. However, the application protocol does not specify how the directory service operates. One example of such a protocol is the Lightweight Directory Access Protocol (LDAP), which is based on a client-server model. An application programming interface (API) for the application protocol, such as LDAP, may simplify the creation of directory service applications.

In order for thedevice210 to use each of the directory service and the authentication service, both thedevice210 and each of the servers hosting the directory service and the authentication service is configured to use the application protocol, such as LDAP. Libraries corresponding to the application protocol may be installed on the servers. One or more of the SSL and Transportation Layer Security (TLS) may be setup for encrypting communication with the servers. The directoryprotocol configuration file144 is a configuration file that defines communication protocols for the libraries installed on the servers. In addition, thefile144 defines the location of the servers, a priority of which servers to contact for verification of users, and a communication protocol with at least the servers. In the LDAP example, thefile144 is the ldap.config file.

The name service switch (NSS)module142 allows services to access appropriate databases on corresponding servers. TheNSS module142 organizes the services and corresponding databases into groups or modules. For example, the groups may include mail aliases, network protocols, host names, Ethernet numbers, user names, user group names, and so forth. For each group, theNSS module142 may include multiple corresponding databases listed according to priority. A configuration file, such as an nsswitch.conf file, provides a lookup process for each database. For example, when determining whether a given user requesting a login to thedevice210, the configuration file for theNSS module142 indicates the location of the directory service. In some embodiments, theNSS module142 is included in theOS120.

TheNSS module142 may receive a username from theshell process132 or theweb service130 during a login request from a given user. TheNSS module142 may determine to access the directory service, such as by accessing the configuration file for theNSS module142, and further determine which server hosts the directory service. Therefore, the request to determine whether the given user exists for thedevice210 is sent to the directory service. The request includes at least the username provided by the given user. The directory service sends a response to thedevice210 after determining whether the given user exists for thedevice210. In response to receiving an indication indicating the given user exists as a user for thedevice210, the pluggable authentication module (PAM)240 may be notified to determine whether the login request is authorized.

ThePAM240 provides a manner for establishing or verifying that a given user is who they claim to be. ThePAM240 includes a library that is a generalized API that includes a library of modules for authentication-related services. ThePAM240 allows a system administrator to add new authentication methods by installing new libraries. A configuration file, such as a pam.conf file, determines which authentication services to select.

When thePAM240 receives an indication indicating that a given user requesting login to thedevice210 exists for thedevice210, thePAM240 determines to access the authentication service, such as by accessing the configuration file for thePAM module240, and further determines which server hosts the authentication service. In addition, thePAM module240 may determine the location of Web services providing access to Web resources. ThePAM module240 may send a request to the Web service on a corresponding Web server to determine both whether the given user is authenticated for use of thedevice210 and whether the user is authenticated for access of the Web resources. The request may be sent to the Web server hosting the Web services and the Web resources. The request includes at least an encrypted version of the username and the password provided by the given user. In this case, thePAM module240 may be proactive in setting up a login session and an HTTP session for the user based on the single login request.

In response to receiving an indication indicating the given user is authorized for thedevice210 and for accessing the Web resources, thedevice210 may create a login session for the given user using the stored user role information. As shown, the authenticated secure shell (SSH)session152 is provided to the user. In addition, thedevice210 may create a HTTP session for the given user. Again, the login session, or the secure shell session, and the HTTP session are created based on the same single login request.

Turning now toFIG. 4, another embodiment of amethod400 for efficiently accessing Web resources is shown. For purposes of discussion, the steps in this embodiment are shown in sequential order. However, some steps may occur in a different order than shown, some steps may be performed concurrently, some steps may be combined with other steps, and some steps may be absent in another embodiment.

In block402, a given user attempts a login on a device. The login request includes at least a username and a password for the given user. In some embodiments, the device is a storage appliance. In other embodiments, the device is a backup server. The device may be deployed with multiple other devices in either a small business environment or an enterprise environment. Inblock404, the credentials are accessed from the login request and inserted in an authorization request being sent to Web services.

In block406, the credentials are used to verify the existence of the given user for the device. The credentials may be sent to a user directory service as described earlier. Alternatively, one or more of the credentials may be sent to the user directory service prior to block406 and prior to sending an authorization request to the Web services. Inblock408, the credentials are verified for access to Web resources. The credentials may be sent from the Web services to an authentication service.

Inblock410, an access token is generated for accessing the Web resources. The access token may be generated by the authentication service. Alternatively, the access token may be generated by the Web server hosting the Web services and the Web resources. Inblock412, the generated access token is sent from the Web services to the device. Inblock414, the received access token is securely stored on the device so as to prevent any source or agent other than processes for the given user's login session from accessing the stored access token. Inblock416, a login session, such as a secure shell (SSH) session, is generated for the given user on the device. The given user has both a login session and an HTTP session on the device based on the login request.

If a client program on the device executing under the given user's login session requests access to the Web resources (conditional block418), then inblock420, a copy of the stored access token is inserted in a resource access request being sent to Web services on a designated Web server hosting the Web resources. In block422, the Web server processes the received request after access is verified with the included access token.

In various embodiments, one or more portions of the methods and mechanisms described herein may form part of a cloud computing environment. In such embodiments, resources may be provided over the Internet as services according to one or more various models. Such models may include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). In IaaS, computer infrastructure is delivered as a service. In such a case, the computing equipment is generally owned and operated by the service provider. In the PaaS model, software tools and underlying equipment used by developers to develop software solutions may be provided as a service and hosted by the service provider. SaaS typically includes a service provider licensing software as a service on demand. The service provider may host the software, or may deploy the software to a customer for a given period of time. Numerous combinations of the above models are possible and are contemplated.

Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims (10)

What is claimed is:

1. An authentication system comprising:

a storage device comprising a first set of resources; and

a web server comprising a second set of resources, wherein the first set of resources comprises at least one Web-based application which requests access to the second set of resources when executed;

wherein in response to receiving, from a user computing device, at the storage device a single request to establish a first session with the storage device with no request for access to the second set of resources by the user computing device, the request including credentials from a user, the storage device is configured to:

send a single authorization request with the credentials to the web server requesting a single authorization for establishing both the requested first session with the storage device and a second session with the web server despite there being no detection of a request for access to the second set of resources by the user computing device,

wherein the single authorization request is sent before the first session with the storage device is established to allow for the first set of resources to request access to the second set of resources;

verify, by the storage device, an existence of the user on the storage device prior to sending said authorization request to the web server;

send, by the web server, the credentials to an authentication service;

verify, by the authentication service, that the user is authorized to access resources of each of the storage device and the web server;

send, by the web server, said single authorization to the storage device allowing the user to establish both the first session and the second session, in response to receiving an indication that the user is authorized to access the first set of resources of the storage device and an indication that the user is authorized to access the second set of resources of the web server;

wherein said single authorization comprises a single session token;

receive the single authorization for the user to access both the first set of resources and the second set of resources; and

establish, using said received single authorization, without generating another authorization, both the second session with the web server and the first session with the storage device based on the single authorization request.

2. The authentication system as recited inclaim 1, wherein in response to receiving the session token, the storage device is further configured to store the session token for use by client programs on the storage device.

3. The authentication system as recited inclaim 1, wherein in response to receiving a request by a client program associated with the second session that requests access to web resources of the web server, the storage device is configured to send a corresponding request to the web server, wherein the corresponding request includes an indication of said single authorization.

4. A device comprising:

a processor;

a memory configured to store instructions of a pluggable authentication management (PAM) module; and

wherein in response to receiving, from a user computing device, a single request with credentials from a user to establish a single session with no request for access to the second set of resources by the user computing device, wherein the single session is a first session on the device comprising a first set of resources, the instructions of the PAM module are executable by the processor to:

send a single authorization request with the credentials to the web server requesting a single authorization for establishing both the requested first session with the device and a second session with a web server despite there being no detection of a request for access to the second set of resources by the user computing device,

wherein the single authorization request is sent before the first session with the device is established to allow for the first set of resources to request access to a second set of resources,

wherein the web server comprises the second set of resources, and wherein the first set of resources comprises at least one Web-based application which requests access to the second set of resources when executed;

verify, by the device, an existence of the user on the device prior to sending said authorization request to the web server;

receive, from the web server, said single authorization to the device allowing the user to establish both the first session and the second session, wherein said single authorization indicates the web server received an indication that the user is authorized to access the first set of resources of the device and an indication that the user is authorized to access the second set of resources of the web server;

wherein said single authorization comprises a single session token;

establish, using said received single authorization, without generating another authorization, both the second session with the web server and the first session with the storage device based on the single authorization request.

5. The device as recited inclaim 4, wherein the memory is further configured to store instructions of a name switch service (NSS) module, wherein the instructions of the NSS module are executable by the processor to send an identifier associated with the user to a directory service to verify an existence of the user on the device prior to sending said authorization request to the web server.

6. The device as recited inclaim 4, wherein in response to receiving the session token, the instructions of the PAM module are further executable by the processor to store the session token for use by client programs on the device.

7. The device as recited inclaim 4, wherein the memory is further configured to store instructions of an operating system, wherein in response to receiving a request by a client program associated with the second session that requests access to web resources of the web server, the instructions of the operating system are further executable by the processor to send a corresponding request to the web server, wherein the corresponding request includes an indication of said single authorization.

8. A method for executing on a processor, the method comprising:

wherein in response to receiving, from a user computing device, a single request with credentials from a user to establish a single session with no request for access to the second set of resources by the user computing device, wherein the single session is a first session on a storage device comprising a first set of resources:

sending a single authorization request with the credentials to a web server requesting a single authorization for establishing both the requested first session with the storage device and a second session with a web server despite there being no detection of a request for access to the second set of resources by the user computing device, wherein the single authorization request is sent before the first session with the storage device is established to allow for the first set of resources to request access to a second set of resources, wherein the web server comprises the second set of resources, and wherein the first set of resources comprises at least one Web-based application which requests access to the second set of resources when executed;

verifying, by the storage device, an existence of the user on the storage device prior to sending said authorization request to the web server;

receiving, from the web server, said single authorization to the storage device allowing the user to establish both the first session and the second session, wherein said single authorization indicates the web server received an indication that the user is authorized to access the first set of resources of the storage device and an indication that the user is authorized to access the second set of resources of the web server;

wherein said single authorization comprises a single session token;

establishing, using said received single authorization, without generating another authorization, both the second session with the web server and the first session with the storage device based on the single authorization request.

9. The method as recited inclaim 8, wherein in response to receiving the session token, the method further comprises storing the session token for use by client programs on the user computing device.

10. The method as recited inclaim 8, wherein in response to receiving a request by a client program associated with the second session that requests access to web resources of the web server, the method further comprises sending a corresponding request to the web server, wherein the corresponding request includes an indication of said single authorization.

Images