System and method for authentication in a computing system

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.

BACKGROUND OF THE INVENTION

Field 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.

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 authorized access100is shown. In the embodiment shown, a single device110is connected to at least servers160and170. However, in various other embodiments, multiple devices are connected to the servers160and170and connected to one or more other devices. The other multiple devices are not shown for ease of illustration. As shown, the server160includes a user authentication service162, which may also be referred to as an authentication service162or an authorization service.

In some embodiments, a user directory service (not shown) is also used along with the authentication service162during a login process by a user attempting to gain login access to the device110. In some embodiments, each of the user directory service and the authentication service162executes 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 the device110from another computing device102. The login request may include credentials such as at least a username and a password.

One or more of the servers160and170may be a local server. Alternatively, one or more of the servers160and170may be a remote server. In other embodiments, one or more of the user directory service and the authentication service162is a cloud-based application.

In some embodiments, the device110is 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, the device110is 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, the device110is a server unlike the storage appliance as the server may not be shipped with installed software from a single vendor. In various embodiments, the user computing device102is a laptop, a desktop, a tablet, another server, or other computing device able to connect to the device110. The connections between the user computing device102, the device110and the servers160and170may 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 the device110and the servers160and170may be located onsite or may be cloud-based.

As shown, a sequence of steps are used to describe a user gaining authenticated use of the device110and gaining authenticated access of the web resources172. The environment using at least the user computing device102, the device110, and the servers160and170may utilize Web-based applications and Cloud-based applications to manage data. In some embodiments, the client program150is a Web-based backup and recovery application. Alternatively, the client program150is a Web-based application that creates, modifies and removes volumes. In addition, the client program150may 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 the client program150uses 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 the device110in the example shown inFIG. 1. The string “9399” is a port used to communicate with REST APIs associated with a Web service on server170used to access the Web resources172in 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 the client program150in 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 the device110and the server170over a network, such as the Internet, may allow manipulation of the Web resources172using a set of stateless operations. The Web services174are the processes executing on the server170communicating with at least the device110. 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, the device110provides a command line interface (CLI) for the user on the computing device102. The CLI provides a manner to repetitively execute a number of tasks in a fixed sequence as a batch job on the device110. 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 device110may 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 the device110to access the Web services174on the server170.

As shown inFIG. 1, a sequence of steps illustrate a user on the computing device102using a client program150on the device110to access the Web resources172on the server170. For purposes of discussion, the sequence steps in this embodiment are shown in sequential order. However, some sequence steps may be performed concurrently. In sequence 1, the user sends a login request from the computing device102to the device110. In various embodiments, the login request includes at least a username and a password as credentials. Responsive to the device110receiving the login request, a separate request may be sent from the device110to 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 the device110and sends a corresponding reply to the device110. 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 the device110. 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 the device110. 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 the authentication 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 the device110, in sequence 2, the device110sends a request for authentication to the authentication service162on the server160. In other embodiments, the authentication service162executes on a same server as the user directory service. In some embodiments, the authentication service162is integrated with the user directory service. In yet other embodiments, the authentication service162is a Cloud-based application. In yet other embodiments, two or more of the user directory service, the authentication service162, another authentication service for authenticating access of the Web resources172, the client program150and the Web resources172are located on a same device or server. The authentication service162determines whether credentials, such as a password, provided by the user during the login attempt to the device110matches a stored authorized password for the user.

The request in sequence 2 to the authentication service162may include an encrypted version of the password provided by the user during the login request to the device110. The device110may use a secure socket layer (SSL) to send the request to the authentication service162. In some embodiments, a successful verification of authorized access for the user indicated in a response in sequence 3 from the authentication service162allows the device110to retrieve user role information for the user and to create a login session for the user. Some server-side Web application frameworks for implementing the authentication service162includes 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 service162.

In sequence 4, it is detected that the client program150wants to access the Web resources172. For example, the client program150executes a cURL command that includes a HTTP method (verb) identifying at least one of the Web resources172. In response to this detection, in sequence 5, a transaction is sent to the Web service174requesting access of the Web resources172. Without a valid access token, the Web services174initiates verification of the authenticity of the user. However, without credentials, the Web services174is unable to send a request to the authentication service162.

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

In sequence 8, a request is sent from the Web services174on the server170to the authentication service162on 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 the Web services174to the authentication services162. In some embodiments, the same authentication service162is used for authenticating the login on the device110and for authenticating access of the Web resources172on the server170. 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 the device110, such as the authentication service162on the server160. A second authentication service may be used for authenticating access of the Web resources172on the server170. The second authentication service may be located on the server170or another server (not shown).

In the embodiment shown, the authentication service for authenticating access of the Web resources172is located on server160. Therefore, the sequences 8 and 9 are between the server170and the server160. In other embodiments where the authentication service for authenticating access of the Web resources172is located on another server, the sequences 8 and 9 would be between the server170and the other server. The request in sequence 8 to the authentication service162may again include an encrypted version of at least the username and the password provided by the user.

Responsive to verifying authorized access of the Web resources172for the user, in sequence 9, a response indicating that the authorized access is verified is sent from the authentication services162to the Web services174. An access token is generated for the HTTP session to be created on the device110. When created on the device110, the HTTP session may be accessed with cURL commands executed by the client program150on the device110. 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 the client program150to send authenticated requests from the device110for accessing the Web resources172on behalf of the user using the computing device102. In some embodiments, the authentication service generates the access token. In other embodiments, the Web services174generates 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. In sequence 10, the generated access token is sent from the server170to the device110. 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, the device110has or establishes an HTTP session. The HTTP session executes on the device110with the login session, such as the SSH session that was created earlier in sequences 2-3. In sequence 11, a request or transaction is sent from the device110to the server170. The request uses a communication protocol such as the RESTful API protocol. The Web resources172are 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 the resources172identified in the request. Although not shown, a corresponding response is sent from the server170to the device110.

In various embodiments, sequences 5-11 may be repeated and the user prompted for credentials, such as in sequence 6. For example, the sequences 5-11 may be repeated each time the client program150executes commands that access the Web 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 authorized access200is shown. Circuitry and logic described earlier are numbered identically. In various embodiments, the device210may be a purpose-built backup appliance (PBBA) similar to the device110described earlier. The PBBA may also be referred to as a storage appliance. In other embodiments, the device210is a server. The device210may process a login request differently than the previous description for the device110. Similar to the authorized access100shown inFIG. 1, a sequence of steps are used inFIG. 2to describe a user gaining authenticated use of the device210and gaining authenticated access of the web resources172. As shown, sequence 1 is the same as sequence 1 in the authorized access100descried earlier. Here, though, the previous sequence 7 replaces sequence 2. The device210includes a pluggable authentication module (PAM)240that sends an authentication request to the Web services174before a login session, such as a secure shell (SSH) session, is created.

Responsive to receiving the user login request from the computing device102, the device210may use the received credentials for authenticating two sessions: the login session on the device210and the HTTP session on the device210for accessing Web resources. Although, no detection for an access of the Web resources172by the client program150has yet occurred, the device210may use the received credentials for the login session to authenticate both the login session and the HTTP session.

In the current sequence 2, the user-provided credentials are sent from the device210to the Web services174. In the current sequence 3, a request is sent from the Web services174on the server170to the authentication service162on 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 the Web services174to the authentication services162.

The current sequence 3 is similar to the previous sequence 8 described earlier for the authorized access100. As described earlier, in some embodiments, the same authentication service162is used for authenticating the login on the device210for the user and for authenticating access of the Web resources172on the server170for the user. In other embodiments, different authentication services are used.

When different authentication services are used, the Web service174may simultaneously send two requests, one request for each authentication service. Alternatively, the Web service174may send a first request to the authentication service for authenticating the user for the login session. In some embodiments, the Web service174may initially send a request to a user directory service as described earlier. Responsive to receiving a response indicating the user exists for the device210, the Web service174may 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, the Web service174may 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.

The current sequence 4 may be similar to the previous sequence 9 with some changes. For example, in the current sequence 4, responsive to a successful verification of authorized access for the user to login to device210and to gain access to the Web resources172, the authentication service162allows the device210to 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, the Web services174generates the access token (e.g., responsive to receiving in sequence 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 the server170to the device210. 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 the server170, the device210generates two sessions for the user based on the single login request: a login session, such as an SSH session, and an HTTP session. The device210securely 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.

The current sequence 6 may be the same as the previous sequence 4, wherein it is detected that the client program150wants to access the Web resources172. Here, the device210already has the access token. Accordingly, in sequence 7, the device210sends an access request or transaction to the server170. 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 components300of the device is shown. The device210includes multiple software components such as at least an operating system (OS)120, a web service130, a shell service132, a pluggable authentication module (PAM)240, a name service switch (NSS) module142, and a directory protocol configuration file144. The OS120may 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.

The shell process132provides a secure shell (SSH) user interface for accessing services of the OS120. The shell service132provides a command-line interface (CLI) to the services of the OS120and other software applications on the device210. When a user opens a secure shell (SSH) session and successfully logs in as an authorized user, the authenticated shell session152is provided to the user. The session152may be a CLI providing a manner to repetitively execute a number of tasks in a fixed sequence as a batch job on the device210. 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 authenticated shell session152may be provided on a local monitor onsite with the device210. Alternatively, the authenticated shell session152may be provided on a remote monitor offsite when the user remotely logs in to the device210.

The web service130may be any one of available internet World Wide Web browsers, such as Firefox, Internet Explorer, Google Chrome, and Safari. The web service130may be used to provide a graphical user interface (GUI) to the services of the OS120and other software applications on the device210. 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 the device210. Alternatively, the authenticated browser session may be provided on a remote monitor offsite when the user remotely logs in to the device210. 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, the device210is 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 the device210, 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 the device210and sends a corresponding reply to the device210.

In addition, the directory service may provide user role information to the device210. 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 the device210. As described earlier, the authentication service determines whether credentials, such as a password, provided by a given user during a login attempt to the device210matches a stored authorized password for the given user. Some server-side Web application frameworks for implementing the authentication service162includes 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 the device210to use each of the directory service and the authentication service, both the device210and 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 directory protocol configuration file144is a configuration file that defines communication protocols for the libraries installed on the servers. In addition, the file144defines 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, the file144is the ldap.config file.

The name service switch (NSS) module142allows services to access appropriate databases on corresponding servers. The NSS module142organizes 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, the NSS module142may 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 the device210, the configuration file for the NSS module142indicates the location of the directory service. In some embodiments, the NSS module142is included in the OS120.

The NSS module142may receive a username from the shell process132or the web service130during a login request from a given user. The NSS module142may determine to access the directory service, such as by accessing the configuration file for the NSS module142, and further determine which server hosts the directory service. Therefore, the request to determine whether the given user exists for the device210is sent to the directory service. The request includes at least the username provided by the given user. The directory service sends a response to the device210after determining whether the given user exists for the device210. In response to receiving an indication indicating the given user exists as a user for the device210, the pluggable authentication module (PAM)240may be notified to determine whether the login request is authorized.

The PAM240provides a manner for establishing or verifying that a given user is who they claim to be. The PAM240includes a library that is a generalized API that includes a library of modules for authentication-related services. The PAM240allows 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 the PAM240receives an indication indicating that a given user requesting login to the device210exists for the device210, the PAM240determines to access the authentication service, such as by accessing the configuration file for the PAM module240, and further determines which server hosts the authentication service. In addition, the PAM module240may determine the location of Web services providing access to Web resources. The PAM module240may send a request to the Web service on a corresponding Web server to determine both whether the given user is authenticated for use of the device210and 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, the PAM module240may 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 the device210and for accessing the Web resources, the device210may create a login session for the given user using the stored user role information. As shown, the authenticated secure shell (SSH) session152is provided to the user. In addition, the device210may 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 a method400for 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. In block404, 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 block406and prior to sending an authorization request to the Web services. In block408, the credentials are verified for access to Web resources. The credentials may be sent from the Web services to an authentication service.

In block410, 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. In block412, the generated access token is sent from the Web services to the device. In block414, 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. In block416, 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 in block420, 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.