Authentication proxy agent
An authentication engine may be configured to receive an authentication request and credentials from a client. The authentication engine may then generate a proxy agent configured to interact with an identity provider to authenticate the client on behalf of the client, using the credentials. In this way, the authentication engine may receive an assertion of authentication of the client from the identity provider, by way of the proxy agent.
Latest BMC SOFTWARE, INC. Patents:
- Probabilistic root cause analysis
- Real-time intelligent filtering and extraction of mainframe log data
- Security profile management for multi-cloud agent registration with multi-tenant, multi-cell service
- Using an event graph schema for root cause identification and event classification in system monitoring
- Systems and methods for isolating transactions to a pseudo-wait-for-input region
This description relates to user authentication.
BACKGROUNDIn many computing scenarios, it is required to authenticate a user, e.g., to verify an identity and/or authorization of the user, prior to granting access to computing resources requested by the user. For example, users often communicate with a provider of computing resources, using a computer network, in order to obtain access to the computing resources. Before granting access to the requested resources, the provider typically verifies an identity and authorization of the user to access the resources. For example, in typical scenarios, the user may be required to submit a username/password combination, which the provider may then verify against a stored database of username/password combinations.
Many scenarios exist in which user authentication is required, and many associated techniques, in addition to the use of a username/password combo as referenced above, may be used in such scenarios. In general, all such scenarios and techniques provide various burdens to both the user and the provider.
For example, the user is typically required to maintain and provide information (e.g., a username/password combination) required to complete the authentication process, whenever required by a provider. Meanwhile, the provider may be required to maintain and protect large amounts of user-specific information, particularly when a large number of users are authorized to access the provider's resources. The provider may be further required to execute all the various processes associated with authenticating each user, each time the user requests access.
Many techniques have been developed to alleviate these and related burdens on the provider and user. For example, techniques have been developed for single sign-on procedures, in which a single authentication process executed with respect to a particular user is relied upon to grant the user access to two or more computing resources. In some examples, an identity provider may provide a service of authenticating users on behalf of a provider of computing resources. In such examples, the provider is relieved of the burden of authenticating each user, based on a trust in the identity provider in providing authentication on behalf of the provider.
Nonetheless, burdens associated with user authentication continue to be problematic in many scenarios for providers and/or users. Consequently, users often experience dissatisfaction with their experience of provider's resources, while the providers experience reduced opportunities to provide their otherwise-available resources.
SUMMARYAccording to one general aspect, a system may include instructions stored on a non-transitory computer readable storage medium and executable by at least one processor. The system may include an authentication engine configured to cause the at least one processor to receive an authentication request and credentials from a client. The authentication may be further configured to cause the at least one processor to generate a proxy agent configured to interact with an identity provider to authenticate the client on behalf of the client, using the credentials, and receive an assertion of authentication of the client from the identity provider, by way of the proxy agent.
According to another general aspect, a method may include receiving an authentication request and credentials from a client. The method may further include generating a proxy agent configured to interact with an identity provider to authenticate the client on behalf of the client, using the credentials, and receiving an assertion of authentication of the client from the identity provider, by way of the proxy agent.
According to another general aspect, a computer program product may include instructions recorded on a non-transitory computer readable storage medium and configured to cause at least one processor to receive an authentication request and credentials from a client. The instructions may be further configured to cause the at least one processor to generate a proxy agent configured to interact with an identity provider to authenticate the client on behalf of the client, using the credentials, and receive an assertion of authentication of the client from the identity provider, by way of the proxy agent.
The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.
In the example of
In conjunction with the above description of the client 102, the mobile server 104 may similarly be understood to represent virtually any server or other computing device which is operable to provide computing resources to the client 102, e.g., over a network. However, as illustrated, the mobile server 104 is referred to as such, for the sake of consistency in referring to interactions with the client 102 in the various scenarios referenced above in which the client 102 executes on a mobile device.
In practice, as referenced above, the client 102 may be developed and deployed by a developer, for the use and enjoyment of a user of the client 102. Consequently, such a developer is typically well-aware that the client 102 will be deployed on a mobile device, and therefore subject to the types of computational and connectivity constraints referenced above. Advantageously, the system 100 allows such developers to develop the client 102, while including a minimal amount of resources associated with enabling the client 102 to authenticate itself with the mobile server 104. Therefore, developers may be more likely to develop and deploy applications, such as the client 102, which are enjoyed and utilized by a large number of users. From the user perspective, individual users are enabled to utilize a larger number of individual clients than would be possible if more computational resources were required for completing authentication of such clients. Moreover, users are enabled to utilize and enjoy such client applications with a minimum of delays associated with authentications thereof.
Meanwhile, the mobile server 104, as referenced above, utilizes fewer resources than would be required if the mobile server 104 were exclusively responsible for authenticating the client 102. On the other hand, compared to conventional scenarios, referenced below, in which the mobile server 104 might rely more extensively on services of the identity provider 106, the mobile server 104 may utilize a relatively greater amount of computing resources. Nonetheless, as described, such a marginal increase in requirements with respect to the mobile server 104 is more than offset with respect to the above-referenced advantages provided to users and developers of the client 102. Thus, the system 100, on net, provides significant advantages to the various entities associated therewith.
Thus, in operation of the system 100, the client 102 provides credentials 108, which are ultimately validated by the identity provider 106, which utilizes an authentication engine 110 to validate the credentials 108 against stored credentials 112. More specifically, as shown and described, an authentication engine 114 associated with the mobile server 104 may be configured to provide a proxy agent 116 that is operable to relay the credentials 108 to the identity provider 106, on behalf of the client 102.
Then, by virtue of the validation of the credentials 108 by the identity provider 106, a session manager 118 of the authentication engine 114 may create a session for the client 102 which will be trusted by the mobile server 104 for purposes of providing services to the client 102. In particular, as described below, the session manager 118 may create a trusted session for the client 102 with respect to two or more services provided by the mobile server 104, so that the client 102 experiences a single sign-on with respect to such services, and perhaps also with respect to services provided by the identify provider 106, if any.
In example embodiments, the identity provider 106 may be implemented as an otherwise-conventional identity provider, such as may be implemented in the context of current, standard authentication protocols. For example, example implementations described below (e.g., with respect to
Thus, the credentials 108 should be understood to represent any suitable type of credential that would be compatible with a corresponding authentication protocol implemented by the identity provider 106. For example, the credentials 108 may include textual information, such as, e.g., username/password combinations, personal identification numbers, one-time passwords, certificated-based authentication, MS KERBEROS tokens, or biometric credentials.
Thus the identity provider 106 may be configured to implement the authentication engine 110 and the credentials 112 in a manner which facilitates some or all of the above-referenced authentication techniques, as needed. Depending on a size of a user base managed by the identity provider 106, the maintenance and management of such authentication services may require significant amounts of human and/or computational resources. Consequently, in many scenarios, the identity provider 106 may be understood to represent, for example, a large provider of services/resources over the Internet, operating as a wholly separate domain from a domain of the mobile server 104. That is, in such scenarios, the identity provider 106 may already be required to provide large-scale authentication services with respect to its own user base, so that it is mutually advantageous for the identity provider 106 to provide authentication services on behalf of the mobile server 104. For example, the mobile server 104 may thus be relieved of the burden of permanently storing user credentials (and associated authentication requirements), while the identity provider 106 may benefit from partnering with the mobile server 104 to provide mobile services to the client 102 (at minimal marginal/incremental cost to the identity provider). In this way, the identity provider 106 may be understood to provide a cross-domain, single sign-on experience to a user of the client 102.
Thus, in the example of
As shown, the proxy agent 116 may include configuration data 120 which governs interactions of the proxy agent 116 with the identity provider 106. More detailed examples of the configuration data 120 are provided below, e.g., in the context of implementations of the system 100 which utilize the SAML standard.
As also shown, the proxy agent 116 receives and temporarily stores the credentials 122, which correspond or are otherwise related to the credentials 108 of the client 102. That is, the proxy agent 116 maintains the credentials 122 for purposes of validating the credentials 122 during interactions with the identity provider 106. However, once authentication occurs, the proxy agent 116 may delete the credentials 122 (or at least the portion thereof which related to the credentials 108), so that burdens associated with maintaining a store of credentials may be avoided by the authentication engine 114.
In the example of
In this regard, such a virtual browser should be understood to refer to software code executed by the proxy agent 116 in the context of the authentication engine 114, which includes some or all of the functionality that would normally be provided in the context of a conventional implementation of a browser. However, in the implementation of
In the example of
In the example of
In the example implementation of
Advantageously, in the example implementations of
In the example of
Somewhat similarly, the specific, illustrated configuration of the authentication engine 114 should be understood to be a representative, non-limiting example. For example, in
Further, the authentication engine 114 is illustrated as including a number of components and subcomponents. However, again, such illustration should be understood to be merely representative. For example, any single component of the authentication engine 114 may be implemented as two or more subcomponents, while, conversely, two or more components may be combined for implementation as a single component.
In the example of
A proxy agent, such as the proxy agent 116, may be generated, and configured to interact with an identity provider to authenticate the client on behalf of the client, using the credentials (204). For example, the proxy agent 116 may be configured to store the credentials 122 temporarily, while communicating with the identity provider 106. In this way, the identity provider 106 may utilize the authentication engine 110 and associated store of credentials 112 to validate the user credentials 108 on behalf of the client 102.
Thereafter, an assertion of authentication of the client may be received from the identity provider, by way of the proxy agent (206). For example, the authentication engine 114 may receive such an assertion from the identity provider 106, by way of the proxy agent 116. For example, in the examples described above in which the system 100 implements the SAML standard, the proxy agent 116 may communicate with the identity provider 106 in accordance with the configuration data 120, to thereby receive an assertion document from the identity provider 106. Thereupon, the session manager 118 may be configured to create a session at the mobile server, with respect to one or more services thereof, on behalf of the client 102.
In the example of
Further, such configuration may include all information associated with defining, storing, and utilizing the configuration data 120 of
Further, for a given identity provider, the configuration data 120 may specify various aspects and manners in which communication with the identity provider should occur. For example, the configuration data 120 may specify a type and format of messages to be exchanged with the identity provider 106. Additionally, the configuration data 120 may specify a sequence or timing according to which such messages may be exchanged, including, e.g., times specified for timeout (after which the exchange must be restarted, retried, or abandoned). Various other configuration data that may additionally or alternatively be utilized in the context of implementing the SAML standard also may be included in the configuration data 120.
Further in
Accordingly, the authentication request and credentials may be passed to the authentication engine 114, for generation of the proxy agent 116 based thereon (306). As just referenced above, the authentication engine 114 may be implemented with and by the mobile server 104, as illustrated in
The appropriate SAML configuration may be retrieved and resolved (308) by the authentication engine 114 for the context of the generated proxy agent 116. As a result, as may be appreciated from the above description, the proxy agent 116 may be provided with the appropriate configuration data 120.
A virtual browser may be selected from the virtual browser pool 126, by the virtual browser manager 124 (310). For example, as referenced above, the virtual browser manager 124 may select an available virtual browser from a number of virtual browsers that have been preconfigured but not yet instantiated for communicating with the identity provider 106 on behalf of the client 102.
The credentials of the client 102 may be posted from the selected virtual browser to the identity provider 106 (312). For example, the SAML standard typically relies on a secure HTTP (hypertext transfer protocol) channel, which may be utilized by the selected virtual browser to push the credentials to the identity provider 106. In communicating with the identity provider 106, the selected virtual browser may rely on aspects of the configuration data 120. For example, as referenced above, the selected virtual browser may determine a type, format, sequence, and timing of messages to be exchanged with the identity provider 106. The virtual browser manager 124 may be configured to monitor such interactions to ensure that the interactions conform to the relevant requirements.
An assertion may be received from the identity provider, so that a corresponding session may be created in response thereto (314). For example, the selected virtual browser may receive an assertion document and associated encrypted string from the identity provider 106. Similarly to a conventional browser, the selected virtual browser may verify a certificate or other proof of identity provided by the identity provider 106, before notifying the session manager 118 that it is permitted to create a new session at the mobile server 104 for the client 102.
Consequently, the session manager 118 may proceed to provide the newly-created session to the mobile server 104 (316), whereupon the mobile server 104 may provide the created session to the client 102 (318). In this way, as described, the client 102 may proceed to benefit from services provided by the mobile server 104, even though the mobile server 104 is not required to provide long-term credential storage on behalf of the client 102, or otherwise assume the burdens of directly authenticating the client 102.
Once authentication has occurred and the new session has been created, the virtual browser manager 124 may return a cleaned or erased version of the selected virtual browser to the virtual browser pool 126. Further, credentials of the credentials 122 corresponding to the credentials 108 to the client 102 may be deleted or otherwise removed from storage by the proxy agent 116. In some implementations, the proxy agent 116 may remain in operation, at least for a predetermined amount of time, in anticipation of receipt of a subsequent authentication request. In other implementations, or after passage of a predetermined amount of time, the authentication engine 114 may delete the proxy agent 116, and may generate a new proxy agent in response to a subsequently-received authentication request.
In the interaction diagram of
The authentication engine 114 resolves an identity of the identity provider 106 (406). The authentication engine 114 also retrieves the appropriate SAML configuration (408), and obtains the correct POST target configuration (410), all of which will be stored within the configuration data 120 of the proxy agent 116.
Accordingly, the authentication engine 114 invokes the proxy agent 116 (412), whereupon the proxy agent 116, in accordance with the configuration data 120 and the user credentials 122, proceeds to POST the user credentials (414) to the identity provider 106. More specifically, in the example of
The identity provider 106 performs the authentication at its authentication engine 110, and based on available credentials 112 (416). The identity provider 106 then creates the SAML assertion (418), and transmits the assertion back to the proxy agent 116 (420), e.g., to the appropriate virtual browser. The proxy agent relays the assertion back to the authentication engine 114 by virtue of HTTP POST operation (422) (or, alternatively, by exchange through an appropriate, available application program interface (API)).
The authentication engine 114 may proceed to decrypt/decode the received assertion (424). The session manager 118 may then create a session based thereon (426). The session may be identified as such so the proxy agent 116 (428), which allows the type(s) of single sign-on experience(s) referenced above. For example, a session token (e.g., encrypted HTTP cookie) may be used to identify a mobile server session of the client 102 to various mobile server applications. The proxy agent 116 provides the session back to the authentication engine 114 (430).
The authentication engine 114 may thus identify the session to the mobile server 104 (432). In this way, the mobile session may be provided to the mobile client 102 (434). Consequently, the mobile client 102 is enabled to execute a get data request (436) or desired resources from the mobile server 104, and the mobile server 104 may securely provide the requested data (438) to the mobile client 102.
In the example of
Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Implementations may implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device (computer-readable medium) for processing by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program, such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be processed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
Method steps may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
Processors suitable for the processing of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer also may include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in special purpose logic circuitry.
To provide for interaction with a user, implementations may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
While certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the scope of the embodiments. It should be understood that they have been presented by way of example only, not limitation, and various changes in form and details may be made. Any portion of the apparatus and/or methods described herein may be combined in any combination, except mutually exclusive combinations. The embodiments described herein can include various combinations and/or sub-combinations of the functions, components and/or features of the different embodiments described.
Claims
1. A system including instructions stored on a non-transitory computer readable storage medium and executable by at least one processor, the system comprising:
- an authentication engine configured to cause the at least one processor to receive an authentication request and credentials from a client; generate a proxy agent configured to interact with an identity provider to authenticate the client on behalf of the client, using the credentials; and receive an assertion of authentication of the client from the identity provider, by way of the proxy agent.
2. The system of claim 1, wherein the authentication engine is implemented by a mobile server providing services to the client, and the client includes a mobile client.
3. The system of claim 1, wherein the authentication engine is configured to cause the at least one processor, in response to the receipt of the authentication request and credentials, to resolve a previously-stored authentication configuration, including identifying the identity provider from among a plurality of identity providers as being associated with the client.
4. The system of claim 1, wherein the proxy agent is configured to store configuration data governing content, format, and timing of interactions with the identity provider.
5. The system of claim 1, wherein the proxy agent includes a virtual browser manager configured to implement a virtual browser used to relay the credentials to the identity provider on behalf of the client.
6. The system of claim 5, wherein the virtual browser manager is configured to access a virtual browser pool storing a plurality of available virtual browsers, and to select the virtual browser therefrom.
7. The system of claim 1, wherein the proxy agent is configured to execute the Security Assertion Markup Language (SAML) standard with the identity provider, including receiving the assertion therefrom, on behalf of the client.
8. The system of claim 1, further comprising a session manager configured to create a session for the client, based on the assertion.
9. The system of claim 8, wherein the authentication engine is provided by a mobile server, and wherein the session provides access to multiple services of the mobile server to the client.
10. A method comprising:
- receiving an authentication request and credentials from a client;
- generating a proxy agent configured to interact with an identity provider to authenticate the client on behalf of the client, using the credentials; and
- receiving an assertion of authentication of the client from the identity provider, by way of the proxy agent.
11. The method of claim 10, wherein receiving the authentication request and credentials further comprises resolving a previously-stored authentication configuration, including identifying the identity provider from among a plurality of identity providers as being associated with the client.
12. The method of claim 10, wherein the proxy agent is configured to store configuration data governing content, format, and timing of interactions with the identity provider.
13. The method of claim 10, wherein the proxy agent includes a virtual browser manager configured to implement a virtual browser used to relay the credentials to the identity provider on behalf of the client.
14. The method of claim 10, wherein the proxy agent is configured to execute the Security Assertion Markup Language (SAML) standard with the identify provider, including receiving the assertion therefrom, on behalf of the client.
15. A computer program product including instructions recorded on a non-transitory computer readable storage medium and configured to cause at least one processor to:
- receive an authentication request and credentials from a client;
- generate a proxy agent configured to interact with an identity provider to authenticate the client on behalf of the client, using the credentials; and
- receive an assertion of authentication of the client from the identity provider, by way of the proxy agent.
16. The computer program product of claim 15, wherein the instructions, when executed, are further configured, in response to the receipt of the authentication request and credentials, to resolve a previously-stored authentication configuration, including identifying the identity provider from among a plurality of identity providers as being associated with the client.
17. The computer program product of claim 15, wherein the proxy agent is configured to store configuration data governing content, format, and timing of interactions with the identity provider.
18. The computer program product of claim 15, wherein proxy agent includes a virtual browser manager configured to implement a virtual browser used to relay the credentials to the identity provider on behalf of the client.
19. The computer program product of claim 18, wherein the virtual browser manager is configured to access a virtual browser pool storing a plurality of available virtual browsers, and to select the virtual browser therefrom.
20. The computer program product of claim 15, wherein the proxy agent is configured to execute the Security Assertion Markup Language (SAML) standard with the identify provider, including receiving the assertion therefrom, on behalf of the client.
7954144 | May 31, 2011 | Ebrahimi et al. |
20060005020 | January 5, 2006 | Hardt |
20060075473 | April 6, 2006 | Moreh et al. |
20060174323 | August 3, 2006 | Brown et al. |
20080046984 | February 21, 2008 | Bohmer et al. |
20080271121 | October 30, 2008 | Hinton et al. |
20100070978 | March 18, 2010 | Chawla et al. |
20100153946 | June 17, 2010 | Bhaskar et al. |
20110030042 | February 3, 2011 | Neal-Joslin |
- “Access Manager for Oracle Access Management 11gR2 PS2”, Technical White Paper, Oracle Corporation, Dec. 2013, 18 pages.
- Lasfargues, Vincent, “Atrium Single Sign on (Atrium SSO)”, BMC Software, Inc., Feb. 15, 2013, 65 pages.
- Oh, Changhun, “Dancing with OAuth: Understanding how Authorization Works”, retrieved from: http://www.cubrid.org/blog/dev-platform/dancing-with-oauth-understanding-how-authorization-works/, 2012, 10 pages.
- Empson, Rip, “Gigya Launches Platform to Give Businesses Access to Users' Complete Social Identities”, retrieved from: http://techcrunch.com/2011/11/02/gigya-launches-platform-to-give-businessess-access-to-users-complete-social-identities/, Nov. 2, 2011, 9 pages.
- “Certificate-Based Single Sign-On Form EMC My Documentum for Microsoft Outlook Using CA Siteminder”, White Paper, EMC Corporation, Dec. 2011, 33 pages.
- “Using Microsoft's Messenger Connect API for Effective Social Distribution”, White Paper, 2011, 15 pages.
- “Security and Usability, How new authentication methods eliminate old trade-offs”, Janrain, Inc., Mar. 2012, 7 pages.
Type: Grant
Filed: Jun 28, 2013
Date of Patent: Nov 24, 2015
Patent Publication Number: 20150007291
Assignee: BMC SOFTWARE, INC. (Houston, TX)
Inventor: Karl Frederick Miller (Dallas, GA)
Primary Examiner: Krisna Lim
Application Number: 13/931,560
International Classification: G06F 15/16 (20060101); H04L 29/06 (20060101); H04L 9/32 (20060101); H04L 9/00 (20060101);