US20130086669A1 - Mobile application, single sign-on management - Google Patents

Abstract

Techniques for managing single sign-on are provided. in some examples, single sign-on functionality may be provided for use on mobile devices by utilizing mobile applications, cloud applications, and/or other web-based applications. For example, a mobile application or mobile web browser may request to authenticate with or access one or more service providers. Authentication credentials may be requested from a user of the mobile device to facilitate such authentication and/or access. Based at least in part on a successful log-in, access to server resources from other applications on the same mobile device may be provided without successive or repetitive credential requests to the user.

Description

CROSS REFERENCES TO RELATED APPLICATIONS
• The present application is a non-provisional of and claims the benefit and priority under 35 U.S.C. 119(e) of U.S. Provisional Application No. 61/541,034 filed Sep. 29, 2011 entitled MOBILE SECURITY AND SINGLE SIGN-ON, the entire contents of which are incorporated herein by reference for all purposes. This application is also related to Application Ser. No. ______, filed on the same day herewith, Attorney Docket No. 88325-831572 entitled “MOBILE APPLICATION, IDENTITY RELATIONSHIP MANAGEMENT,” Application Ser. No. ______, filed on the same day herewith, Attorney Docket No. 88325-831573 entitled “MOBILE APPLICATION, IDENTITY INTERFACE,” and Application Ser. No. ______, filed on the same day herewith, Attorney Docket No. 88325-831574 entitled “MOBILE APPLICATION, RESOURCE MANAGEMENT ADVICE,” the entire contents of each is hereby incorporated by reference as if fully set forth herein, under 35 §120.
BACKGROUND
• Mobile devices are often configured with multiple different applications, including web browsers, native mobile applications, and the like. In general, each application may request individual authentication credentials from users of the mobile devices. Additionally, each application may individually authenticate itself with a server prior to being given access to an account of the server. However, logging in multiple times from the same device, in order to utilize more than one of the multiple different applications may be tedious, time consuming, and unpleasant for the users. Additionally, multiple log-in requests may make users less alert and aware of which applications are regularly requesting credentials. In some instances, this may make password phishing techniques more likely to succeed. As such, finding ways to implement single sign-on for applications of mobile devices continues to be a priority.
BRIEF SUMMARY
• Techniques for managing single sign-on are provided. In some examples, single sign-on functionality may be provided for use on mobile devices by utilizing mobile applications, cloud applications, and/or other web-based applications. For example, a mobile application or mobile web browser may request to authenticate with or access one or more service providers. Authentication credentials may be requested from a user of the mobile device to facilitate such authentication and/or access. Based at least in part on a successful log-in, access to server resources from other applications on the same mobile device may be provided without successive or repetitive credential requests to the user.
• According to at least one example, a computer readable memory may store instructions that, when executed by one or more processors, cause the one or more processors to receive one or more requests to access a service provider. In some examples, the requests may be received from a first application of the mobile device. Additionally, the instructions may also cause the one or more processors to log in a user associated with the first application. The instructions may further cause the one or more processors to provide a token for accessing the service provider to the first application. A second token may then be provided to a second application.
• In some examples, the first application may be configured as an application agent for providing single sign-on functionality for the second application. Additionally, in some examples, the second application may be configured as a web browser application or a native application.
• In one example, the first application may be configured as a browser application associated with a web service while the second application may be configured as a native application associated with an application service provider. The browser application and the native application may be executed or otherwise hosted by a mobile device.
• In some examples, the first application may be configured as a native application of a mobile device. The native application may be associated with an application service provider. Additionally, the second application may be configured as a browser application associated with a web application. The browser application may be executed or otherwise hosted by a mobile device. Further, in some examples, the second application may be configured as a second native application associated with a second application service. The second native application may also be executed or otherwise hosted by the mobile device.
• In one example, a log-in of the user may include an authentication of the user with an authentication service that utilizes a representational state transfer (REST) call. In another example, a second token provided to a second application may enable the second application to log in to an application service provider associated with the second application without the user providing log-in credentials to the application service provider associated with the second application.
• Techniques for managing identities are also provided. In some examples, identity management, authentication, authorization, and token exchange frameworks may be provided for use with mobile devices, mobile applications, cloud applications, and/or other web-based applications. For example a mobile client may request to perform one or more identity management operations associated with an account of a service provider. Based at least in part on the requested operation and/or the particular service provider, an application programming interface (API) may be utilized to generate and/or perform one or more instructions and/or method calls for managing identity information of the service provider.
• According to at least one example, a system may receive a request to perform a function associated with a service provider. The request may be received from a client application and may be formatted as a representational state transfer (REST) call. Additionally, the system may also determine an access management service call corresponding to the service provider for which performance of the function is being requested. Further, the system may perform the access management service call.
• In one example, the client application from which the request is received may be implemented as a mobile application of a mobile device, a software as a service (SaaS) application, and/or a Rich Internet Application (RIA). Additionally, in some examples, the request to perform the function associated with the service provider may include an authorization request. The authentication request may include a user identifier (ID) of a user of the client application. The authentication request may also include a password of the user and/or a client token used to indicate that the client application has been authenticated. The user ID and the password may, in some cases, be used to authenticate the user with the access management service.
• In one example, the access management service call performed by the system may include a method call to implement a token exchange.
• Additionally, in some examples, the request to perform the function associated with the service provider may include an access request. The access request may, in some cases, include a client token indicating that the client is authenticated, a user token indicating that the user is authenticated, and/or an indication of the service provider for which access is being requested. In some cases, the system may receive an indication that the user and/or the client application have been granted access to the service provider by the access management service. In this case, the system may then provide an access token to the client application.
• In one example, service calls f)cu first access management service may be different from service calls for a second access management service. Further, in some cases, the access management service to be utilized may be specified by the service provider, but not indicated to the client application. In this way, the client application can make REST calls independent of the API or other configuration of the service provider.
• According to at least one example, a system may receive an instruction to manage an identity. The system may also be configured to model an identity relationship, associated with the identity that is to be managed, as a uniform resource identifier (URI). The system may also map the URI to a schema associated with a service provider and/or transmit the schema to the service provider for managing the identity as requested.
• In some examples, the received instruction to manage an identity may be received by a mobile client application, an RIA, or a SaaS application. The received instruction may also be formatted as a REST call. Additionally, in some aspects, the modeled identity relationship may include the identity to be managed and/or an association between the identity and another entity. Further, the identity relationship may be modeled as a based at least in part on a string of characters including the identity and the association.
• Techniques for a resource management advice service are also provided. In some examples, resource management advice and/or instructions may be provided for use with mobile devices, mobile applications, cloud applications, and/or other web-based applications. For example, a mobile client may request to perform one or more resource management operations associated with a service provider. Based at least in part on the requested operation and/or the particular, service provider, advice and/or instructions for managing the resource may be provided.
• According to at least one example, a computer readable memory may store instructions that, when executed by one or more processors, cause the one or more processors to receive a request to manage a secure resource of a service provider. The request may be received from a client application and may be formatted as a representational state transfer (REST) call. Additionally, the instructions may also cause the one or more processors to determine an acquisition path for performing the management of the secure resource. The instructions may further cause the one or more processors to generate an instruction set for following the acquisition path. The instruction set may include at least one instruction. Further, the instructions may cause the one or more processors to transmit the instruction set to the client application.
• In one example, the client application from which the request is received may be implemented as a mobile application of a mobile device, a software as a service (SaaS) application, and/or a Rich Internet Application (RIA). Additionally, in some examples, the request to manage the secure resource may include a request to access the secure resource, a request to update the secure resource, or a request to delete the secure resource. The secure resource may include profile information associated with a user of the client application, payroll information associated with a user of the client application, or social information associated with a user of the client application. The generated instruction may, in some cases, be protected by a security filter. In some aspects, the acquisition path may be determined dynamically based at least in part on the secure resource and/or a change associated with the secure resource.
• In one example, the instructions may cause the one or more processors to receive, based at least in part on the transmitted instruction set, an authentication request from the client application. The instructions may also cause the one or more processors to provide, based at least in part on the authentication request, an authentication token to the client application.
• Additionally, in some examples, the instructions may cause the one or more processors to determine a second acquisition path for performing the management of the secure resource, generate a second instruction set, and transmit the second instruction set to the client.
• The foregoing, together with other features and embodiments, will become more apparent upon referring to the following specification, claims, and accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
• The detailed description is set forth with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.
• FIG. 1 is a simplified block diagram illustrating an example architecture for managing single sign-on for mobile devices that includes one or more REST service computers, one or more user devices, and one or more application provider computers connected via one or more networks, according to at least one example.
• FIG. 2 is a simplified block diagram illustrating at least some features of the single sign-on management described herein, according to at least one example.
• FIG. 3 is a simplified block diagram illustrating at least some additional features of the single sign-on management described herein, according to at least one example.
• FIGS. 4-7 are simplified process flow diagrams illustrating at least some features of the single sign-on management described herein, according to at least a few examples.
• FIGS. 8-10 are simplified flow diagrams illustrating example processes for implementing at least some features of the single sign-on management described herein, according to at least a few examples.
• FIG. 11 is a simplified block diagram illustrating components of a system environment that may be used in accordance with an embodiment of the single sign-on management described herein, according to at least one example.
• FIG. 12 is a simplified block diagram illustrating a computer system that may be used in accordance with embodiments of the single sign-on management described herein, according to at least one example.
DETAILED DESCRIPTION
• Overview
• In the following description, various embodiments will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified in order not to obscure the embodiment being described.
• Embodiments of the present disclosure are directed to, among other things, providing single sign-on management to one or more entities (e.g., mobile applications) via a computing resource and/or identity interface service computing system. As used herein, an identity interface service may include one or more computing systems for managing single sign-on and/or authentication requests, client tokens, application tokens, user tokens, or the like. Additionally, the identity interface service may be configured to provide a pluggable interface layer between client applications and other service providers. For example an identity interface service may receive identity management instructions from client applications (e.g., mobile applications of mobile devices, SaaS applications, RIAs, combinations of the foregoing, or the like) and provide appropriately translated instructions to one or more service providers, identity providers, and/or access management providers. In some examples, mobile applications may include, but are not limited to, native applications (e.g., mobile device applications configured to execute on specific mobile devices, in some instances, without interpretation by other software), web browser applications (e.g., for displaying web pages to users of the mobile device), security agent applications, helper applications, and/or authentication delegation applications.
• In some aspects, the identity interface service may provide the ability for mobile applications of a mobile device to perform log-in operations (e.g., authentication, authorization, etc.) on behalf of other mobile applications of the mobile device. In this way, a user may provide log-in information to one of the mobile applications a single time. The mobile application may then log in the user and provide access tokens or other access functionality to other mobile applications associated with the log-in, the user, the mobile device, or other group or sub-group of applications and/or services. In some examples, the log-in operations and/or requests may be provided to the identity interface service in REST style. Further, in some examples, the mobile application making the log-in operation requests may be a native mobile application, a browser application, and/or a security agent application. For example, a security agent application may be a helper application, an authentication delegation application, or other application designated to help or otherwise facilitate the single sign-on described herein. That is, a security agent application may be configured to act as a single sign-on application for native applications, groups of native applications, browser applications, other groups of native and/or browser applications, sub-groups of mobile applications (native and/or browser), or the like. Alternatively, or in addition, a browser application or a native application may be designated and configured to act as the security agent application for other mobile applications, groups of mobile applications, etc.
• Additionally, in some aspects, the identity service may provide authentication, authorization, auditing, token services, user profile management, password management, and/or ID management. Additionally, these services may be exposed or otherwise provided to the mobile applications that may not natively be able to interact with such services (e.g., services deployed by or within an enterprise solution). In one example, the identity interface service may provide a REST interface to the mobile applications to allow the communication of identity management requests to an identity service. In this way, the mobile applications may utilize native Internet-based operations such as those utilizing, but not limited to, the JavaScript Object Notation (JSON) data format, the hypertext transfer protocol (HTTP), and/or the hypertext markup language (HTML). Further, the identity interface service may allow plug-in capabilities for service providers including, but not limited to, enterprise solutions, identity services, access management services, and/or other identity-related solutions. For example, an identity service of an enterprise solution may plug in to the identity interface service to allow for secure interaction with a client application from which it would not ordinarily be able to receive instructions and/or requests. RESTful APIs may be provided for such service providers and, in some examples, security models may be provided for securing the RESTful APIs.
• In one non-limiting example, a security agent application of a mobile device may receive one more log-in requests from a mobile application of the mobile device. The requests may be received in any format, may include user log-in information, and may identify one or more service providers, application providers, or other computing devices associated with the mobile applications. The security agent application may transmit one or more log-in requests, authentication requests, authorization requests, or the like to the identity interface service. These requests may be sent to the identity interface service in REST style. Client tokens, user tokens, and/or access tokens may then be received, by the security agent application, from the identity interface service. In some examples, these tokens may be for providing access to the requested service providers, application providers, or other servers. The security agent application may determine which mobile applications are within a security group, a circle of trust, or other single sign-on group (hereinafter, referred to as a circle of trust) and share received user tokens therewith. Additionally, in some examples, the security agent application may request specific access tokens for each mobile application within the group. In this way, when the user attempts to use different mobile applications within the same circle of trust, user information may not need to be requested again. Further, mobile applications of a mobile device may be given a priority or other level to indicate that, when present, the highest priorities mobile applications may act as the security agent application. In this way, the single sign-on management described herein need not rely on a dedicated security agent application. Rather, any browser application or native application of the mobile device may perform the sing e sign-on operations for other mobile application of a circle of trust.
• In other non-limiting examples, the identity interface service may be configured to receive log-in requests (sometimes, as REST calls) from a dedicated security agent application, a browser application acting as a security agent application, and/or a native application acting as a security agent application. The identity interface service may then respond to the requesting application with user tokens, client tokens, and/or access tokens that may be shared with other applications of the mobile device. For example, the identity interface service may receive one or more identity propagation and/or token exchange requests from a mobile application attempting to access a service provider. The request may be received in REST style (i.e., as a REST call) and may indicate that the client application, the user, or the mobile device has been authenticated or is requesting to be authenticated. The identity interface service may determine, based at least in part on the service provider (e.g., an access management service of an enterprise solution), an appropriate identity propagation and/or token exchange instruction to be performed. The identity interface service may then perform the instruction in order to provide appropriate tokens (e.g., an access token, a user token, or a client token) to the mobile application. Alternatively, or in addition, the identity interface service may format the instruction, based at least in part on an API of the service provider, in such a way that the service provider may be able to perform the instruction. The identity interface service may then transmit the formatted instruction or instructions to the service provider. The service provider may then perform the instructions and, in sonic cases, provide the appropriate access token to the identity interface service. In this way, the mobile application may be provided with appropriate access tokens for accessing the service provider (e.g., assuming the mobile application and the user are granted access) even without directly communicating with the service provider, and/or without knowledge of particular and/or proprietary APIs of the service provider. While this example describes single sign-on, identity propagation (i.e., replicating authenticated identities through multiple systems), and/or token exchange (i.e., providing access tokens based on prior authentication), the identity interface service may be configured, as described above, for implementing other services as well, including, but not limited to, authentication, authorization, auditing, profile management, password management, ID management, etc.
• This brief introduction, including section titles and corresponding summaries, is provided for the reader's convenience and is not intended to limit the scope of the claims, nor the preceding sections. Furthermore, the techniques described above and below may be implemented in a number of ways and in a number of contexts. Several example implementations and contexts are provided with reference to the following figures, as described below in more detail. However, the following implementations and contexts are but a few of many.
• Illustrative Architecture
• FIG. 1 depicts a simplified example system orarchitecture100 in which techniques for managing single sign-on for mobile applications may be implemented. inarchitecture100, one or more users102 (i.e., account holders) may utilize user computing devices104(1)-(N) (collectively, user devices104) to access one ormore browser applications106 ornative applications108 in communication with one ormore web applications110 and/orapplication services112, respectively, via one ormore networks114. In some aspects, theweb application110 and/or application service may be hosted, managed, and/or provided by a computing resources service or service provider, such as by utilizing one or moreapplication provider computers116. The one or moreapplication provider computers116 may, in some examples, provide computing resources and/or services such as, but not limited, web services, data storage, email, identity management, authorization and/or authentication services, or the like. The one or moreapplication provider computers116 may also be operable to provide web hosting, application development platforms, implementation platforms, or the like to the one or more users102.
• In some examples, thebrowser application106 may be any type of web browser configured to retrieve, present, and/or traverse web content on behalf of or for the user102 via theuser device104. In some cases, thebrowser applications106 may access theweb application110 or other web page via thenetworks114. Thenative applications108 may, in some examples, be any type of mobile application designed and/or configured to be executed by theuser device104 including, but not limited to, tax applications, directory applications, expense report applications, log-in applications, library applications, customer relationship management (CRM) software, or the like. Further, in some cases, thenative applications108 may access data and/or other resources stored and/or provided by theapplication services112 via thenetworks114. For example, a native application may be configured as a directory application that access a directory service or server of anapplication provider computer114 for directory information and/or any data not stored locally at theuser device104.
• The users102 may also access one or moresecurity agent applications118 in communication with an identity service or other service provider that may be executed or otherwise hosted by the identityinterface service computers120, via thenetworks114. In some examples, asecurity agent application118 may be a helper application, authentication delegation application, a single sign-on (SSO) mobile application, a security agent, an application agent, or the like (hereinafter, “security agent application”). Thesecurity agent application118 may be configured to perform single sign-on functionality and/or operations on behalf of other mobile applications (e.g.,browser applications106 and/or native applications108) ofuser devices104 or on behalf of users102 of theuser devices104. Further, in some examples, thesecurity agent application118 may transmit and/or receive log-in credentials, security information, tokens, etc., to and/or from aREST module122 of the identityinterface service computers120, for performing the single sign-on functionality described herein. Alternatively, thesecurity agent application118 may communicate with one or more other modules of the identityinterface service computers120 and/or of other computing devices that may facilitate single sign-on operations for mobile devices.
• In some examples, thenetworks114 may include any one or a combination of multiple different types of networks, such as cable networks, the Internet, wireless networks, cellular networks, intranet systems, and/or other private and/or public networks. While the illustrated example represents the users102 accessing theweb application110, theapplication service112, and/or theREST module122 over thenetworks114, the described techniques may equally apply in instances where the users102 interact with one or more service provider computers via the one ormore user devices104 over a landline phone, via a kiosk, or in any other manner. It is also noted that the described techniques may apply in other client/server arrangements (e.g., set-top boxes, etc.), as well as in non-client/server arrangements (e.g., locally stored applications, etc.).
• Thebrowser applications106 and/or thenative applications108 may allow the users102 to interact with theapplication provider computers116, such as to store, access, and/or manage data, develop and/or deploy computer applications, and/or host web content. Theuser devices104 may he any type of computing device such as, but not limited to, a mobile phone, a smart phone, a personal digital assistant (PDA), a laptop computer, a desktop computer, a thin-client device, a tablet PC, etc. In some examples, theuser devices104 may be in communication with theapplication provider computers116 and/or the identityinterface service computers120 via thenetworks114, or via other network connections. Further, theuser devices104 may also be configured to implement one or more mobile applications, RIAs, or SaaS applications. In some examples, however, these mobile applications may not be programmed with, or otherwise aware of, instructions for interacting with theapplication provider computers116 to log in or otherwise access theweb applications110 and/orapplication services112. However, in some cases, the mobile applications (e.g., thesecurity agent application118, thebrowser applications106, and/or the native applications108) may be able to communicate or otherwise interact with the identityinterface service computers120. In this way, the identityinterface service computers120 may act as an interface layer between the mobile applications and theapplication provider computers116. Additionally, the identityinterface service computers120 may provide the appropriate instructions and/or code to thesecurity agent application118 for communicating with or otherwise providing log in functionality and/or access to theweb applications110 and/or the application services112.
• In one illustrative configuration, theuser devices104 may include at least onememory124 and one or more processing units (or processor(s))126. The processor(s)126 may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof. Computer-executable instructions or firmware implementations of the processor(s)1126 may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various functions described.
• Thememory124 may store program instructions that are loadable and executable on the processor(s)126, as well as data generated during the execution of these programs. Depending on the configuration and type ofuser device104, thememory124 may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.). Theuser device104 may also include additional storage (e.g., removable and/or non-removable storage)128 including, but not limited to, magnetic storage, optical disks, and/or tape storage. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing devices. In some implementations, thememory114 may include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), or ROM.
• Thememory124, theadditional storage128, both removable and non-removable, are all examples of computer-readable storage media. For example, computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Thememory124 and theadditional storage128 are all examples of computer storage media.
• Theuser devices104 may also contain communications connection(s)130 that allow theuser devices104 to communicate with a stored database, another computing device or server (e.g., theapplication provider computers116, the identityinterface service computers120, etc.), user terminals, and/or other devices on thenetworks114. Theuser devices104 may also include input/output (I/O) device(s)132, such as a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, a printer, etc.
• Turning to the contents of thememory124 in more detail, thememory124 may include anoperating system134 and one or more application programs or services for implementing the features disclosed herein including at least thebrowser applications106, native applications108 (e.g., a tax application, a directory application, a CRM application, etc.), and/or thesecurity agent application118. As noted above, in some examples thesecurity agent application118 may be a stand-alone application for facilitating single sign-on for the other mobile applications. However, in some examples, thebrowser application106, or anative application108, may be configured to act as the security agent application for a group of mobile applications (e.g., based on a priority, a predetermined list of applications, or the like). Additionally, thememory124 may store access credentials and/or other user information such as, but not limited to, user IDs, passwords, other user information, and/or log-in requests to be sent to the identityinterface service computers120. In some examples, the other client information may include information for authenticating an account access request such as, but not limited to, a device ID, a cookie, an IP address, a location, or the like. In addition, the other client information may include a user102 provided response to a security question or a geographic location obtained by theuser device104.
• In some aspects, the identityinterface service computers120 may also be any type of computing devices such as, but not limited to, mobile, desktop, thin-client, and/or cloud computing devices, such as servers. In some examples, the identityinterface service computers120 may be in communication with theuser devices104 via. thenetworks114, or via other network connections. The identityinterface service computers120 may include one or more servers, perhaps arranged in a cluster, as a server farm, or as individual servers not associated with one another. These servers may be configured to perform or otherwise host features described herein including, but not limited to, the single sign-on service and/or the identity interface service. Additionally, in some aspects, the identityinterface service computers120 may be configured as part of an integrated, distributed computing environment.
• In one illustrative configuration, the identityinterface service computers120 may include at least onememory136 and one or more processing units (or processor(s))138. The processor(s)138 may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof. Computer-executable instruction or firmware implementations of the processor(s)138 may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various functions described.
• Thememory136 may store program instructions that are loadable and executable on the processor(s)138, as well as data generated during the execution of these programs. Depending on the configuration and type of identityinterface service computers120, thememory136 may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.). The identityinterface service computers120 or servers may also includeadditional storage140, which may include removable storage and/or non-removable storage. Theadditional storage140 may include, but is not limited to, magnetic storage, optical disks, and/or tape storage. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing devices. In some implementations, thememory136 may include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), or ROM.
• Thememory136, theadditional storage140, both removable and non-removable, are all examples of computer-readable storage media. For example, computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Thememory136 and theadditional storage140 are all examples of computer storage media.
• The identityinterface service computers114 may also contain communications connection(s)142 that allow theidentity interface computers120 to communicate with a stored database, another computing device or server, user terminals, and/or other devices on thenetworks114. The identityinterface service computers120 may also include input/output (I/O) device(s)1344, such as a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, a printer, etc.
• Turning to the contents of thememory136 in more detail, thememory136 may include anoperating system146 and one or more application programs or services for implementing the features disclosed herein including aREST interface module122. In some examples, theREST interface module122 may be configured to provide a REST API, receive REST API calls, determine appropriate identity service and/or log-in method calls (i.e., API calls), provide the method calls, and/or perform instructions associated with the method calls. In other words, theREST interface module122 may be utilized for interacting with thesecurity agent application118 of theuser devices104.
• By way of example, and without limitation, asecurity agent application118 of auser device104 may transmit a REST API call for performing a particular identity management operation (e.g., a user log-in). TheREST interface module122 may receive the API call and determine an appropriate method call for the application provider computers it116. In some examples, theREST interface module122 may be configured to provide access tokens (e.g., user tokens, client tokens, and/or access tokens) to thesecurity agent application118. These tokens may then be appropriately shared with other mobile applications of theuser device104 such that the user102 may not need to log in multiple times for mobile applications within a trusted group. A few examples of the operations of thesecurity agent application118 and/or the identityinterface service computers120 are described in greater detail below.
• Additional types of computer storage media (which may also be non-transitory) that may be present in the identityinterface service computers120 and/oruser devices104 may include, but are not limited to, programmable random access memory (PRAM), SRAM, DRAM, RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the identityinterface service computers120 and/oruser devices104. Combinations of any of the above should also be included within the scope of computer-readable media.
• Alternatively, computer-readable communication media may include computer-readable instructions, program modules, or other data transmitted within a data signal, such as a carrier wave, or other transmission. However, as used herein, computer-readable storage media does not include computer-readable communication media.
• FIG. 2 depicts a simplified example system orarchitecture200 in which additional techniques for managing single sign-on for mobile applications may be implemented. Inarchitecture200, a user device202 (e.g., a mobile device at least similar to user device104) may be configured with abrowser application204, one or more native applications (e.g., native application one206 and native application two208), and asecurity agent application210 for interacting with one or moreservice provider computers212 and/or one or moreidentity service computers214 via one ormore networks216. In some examples, each mobile application at least thebrowser application204 and/ornative applications206,208 may include software development kit (SDK)information218,220,222 for appropriately interacting with aweb application224, application service one226, and application service two228, respectively. Alternatively, theSDKs218,220,222 may be configured to provide development information for appropriately interacting with theidentity service computers214, or more particularly, with aREST module230 of the identity service computers21.4. Further, in some examples, thesecurity agent application210 may be coupled with awallet232. Thewallet232 may be a location in memory or a separate memory device for storing user credentials and/or log-in information associated with a user of theuser device202.
• As with thenetworks114 ofFIG. 1, thenetworks216 may include any one or a combination of multiple different types of networks, such as cable networks, the Internet, wireless networks, cellular networks, intranet systems, and/or other private and/or public networks. While the illustrated example represents theuser device202 accessing theweb application224, theapplication services226,228, and/or theREST module230 over thenetworks216, the described techniques may equally apply in instances where theuser device202 interacts with such applications and/or modules over a landline phone, via a kiosk, or in any other manner. It is also noted that the described techniques may apply in other client/server arrangements (e.g., set- op boxes, etc. as well as in non-client/server arrange e s (e.g., locally stored applications, etc.).
• In one non-limiting example, thebrowser application204 and native application one206 may be included in a circle of trust, or other trusted group of mobile applications residing on theuser device202. In this example, native application two208 may not be a member of the group. That is, the circle of trust may have been defined to include only thebrowser application204 and native application one206 for some particular reason. As such, single sign-on functionality may only be performed for members of the group (i.e., the circle of trust). However, in other examples, more or less mobile applications of theuser device202 may be included in the trusted group. Here, thesecurity agent application210 may receive a request from thebrowser application204 to log in to theweb application224. In response, thesecurity agent application210 may request log-in credentials from a user of theuser device202 such as, but not limited to, a user name, password, etc. Thesecurity agent application210 may then transmit user and/or context information234 to theREST module230 via thenetworks216. This information234 may be transmitted in REST style.
• TheREST module230 may then translate the REST calls into log-in instructions for authenticating a user of theuser device202, theuser device202, and/or thebrowser application204. Theidentity service computers214 may perform or instruct other computing devices or modules to perform the authentication instructions. Upon authentication, theREST module230 may provide user tokens and/or client tokens back to thesecurity agent application210. In some cases, the user tokens and/or client tokens may signify that the user of theuser device202 and/or the user device itself202 have been authenticated. Similarly, the user tokens and/or client tokens may signify or otherwise indicate that the requesting application (in this case, the browser application204) has been authenticated. Upon successfully logging in, the security application may also receive an access token for accessing the appropriate service of the application provider computers212 (e.g., theweb application224 and/orapplication services226,228). InFIG. 2, the access tokens can be identified by the striped diamond-type shapes. As such, in one example, thesecurity agent application210 may request an access token (e.g., the token with diagonal stripes) for thebrowser application204 based at least in part on the initial request to log in to theweb application224. Thesecurity agent application210 may then provide the access token to thebrowser application204, which may then provide the access token (again, the token with diagonal stripes)to theweb application224. This access token may indicate to the web application that thebrowser application204 of theuser device202 has been authenticated with theidentity service computers214. Theweb application224 may then safely interact with the browser application.
• Additionally, in some examples, thesecurity agent application210 may later receive a request from native application one206 to access application service one226. In this case, since native application one206 is in the same circle of trust as thebrowser application204, and since thesecurity agent application210 has already authenticated the user and/or the user device202 (i.e., user and/or client tokens have already been received), thesecurity agent application210 may be able to request an access token (this time, the token with horizontal stripes) from theidentity service computers214 without re-requesting the user credentials of the user of theuser device202. That is, once thesecurity agent application210 has authenticated the user and thedevice202, thesecurity agent application210 may be able to perform single sign-on functionality for other applications of the circle of trust. However, if the user requested to log in to application service two228 via native application two208 (assuming, as noted above, that native application two208 may not be in the circle of trust), thesecurity agent application210 would not be able to request and/or receive an access token for that operation.
• Additionally, in other examples, theuser device202 may not be configured with a dedicatedsecurity agent application210. In this case, one or more of the mobile applications (i.e., thebrowser application204 and/ornative applications206,208) may act as thesecurity agent application210. That is, once a circle of trust is formed, each application of the circle of trust may be given a priority. The priority may determine or otherwise indicate which mobile application should act as the single sign-on helper (or security) application for the group. In one non-limiting example, all threemobile applications204,206,208 shown inFIG. 2 may be part of a circle of trust. Additionally, native application two208 may be given the highest priority followed by thebrowser application204. As such, when a user attempts to log in to one of the three mobile applications, the user device may first check whether the highest priority application (in this example, native application two208) is installed on theuser device202. If so, native application two208 may act as thesecurity agent application210 and send REST requests to theidentity service computers214 or otherwise perform authentication for the circle of trust and/or receive and share access tokens. Alternatively, if native application two208 is not installed on the user device, thebrowser application204 may act as thesecurity agent application210 to perform the single sign-on operations for the circle of trust. Either way, once a user has logged in to one application of the circle of trust, user credentials will not be needed for accessing other applications of the circle of trust.
• As noted, in at least one example, one or more aspects of the environment orarchitectures100 and/or200 may incorporate and/or be incorporated into a distributed program execution service such as that hosted by theidentity service computers120,214.FIG. 3 depicts asimplified architecture300 illustrating additional aspects and/or features of theidentity service computers120,214 ofFIGS. 1 and 2. Further, in some examples, an identity interface service may actually implement REST service as one of its many services. For example,FIG. 3 illustrates anidentity interface service302, such as that implemented by theidentity service computers120 ofFIG. 1 and/or theidentity service computers214 ofFIG. 2, receiving information, requests, and/or instructions from one or more client applications such as, but not limited to,SaaS applications304,mobile applications306, and/orRIAs308. As noted above, these requests may be formatted, by theclient applications304,306,308, as REST calls and may be based at least in part on a REST API provided by theidentity interface service302. Additionally, theidentity interface service302 may be in communication with one or more service providers/data repositories310 and/or adata tier312 via apluggable layer314. As noted above, by providing apluggable layer314, the one or more service (providers/data repositories310 may be added and/or removed to theservice302 on the fly and/or independent of the type of client application with which it may interact. In this way, theservice302 may maintain flexibility.
• In some examples, the service providers/data repositories310 may include one or moresecurity policy services316,access management services318,directory services320,databases322, and/or identity stores324 (e.g., lightweight directory access protocol (MAP) servers). Additionally, according to some aspects, the service providers/data repositories310 may be in communication with one or more pluggable services such as, but not limited to, an access software development kit (SDK)326, a trust service328, and/or anidentity library330. In some examples, theaccess SDK326, the trust service328, and/or theidentity library330 may collectively make up the interface layer for plugging the service providers/data repositories310 into theidentity interface service302 via thepluggable layer314. For example, theaccess SDK326 may be responsible for plugging theaccess management service318 into theservice302.
• Theidentity interface service302 may also include anadministration module332 for controlling, managing, or otherwise communicating with one or moreruntime data stores334,audit data stores336, and/or configuration data stores338 of thedata tier312. Thedata tier312 may be in communication with theservice302 via aninfrastructure platform340 which may be configured to attach thedata tier312 as well as perform internal file management, logging, monitoring, and/or other administrative tasks. In some cases, theadministration module332 and thedata tier312 may be responsible for controlling, configuring, managing, and/or otherwise administering the services and/or data associated with theidentity interface service302. Additionally, theidentity interface service302 may also include asecurity filter342, a request/response handler344, one or moreREST service engines346, and/or a service provider interface (SPI)framework348.
• In some aspects, thesecurity filter342 may he configured to maintain the security of the REST API that is provided by theidentity interface service302. In this way, only authorized and/or authenticated client applications may he provided with the REST APIs and/or only API calls from authorized and/or authenticated client applications may be processed. The request/response handler344 may be configured to receive requests from, and provide responses to, theclient applications304,306,308, etc. In some examples, theREST service engines346 may be configured to govern policies of theidentity interface service302 such as, but not limited to, enforcing compliance with rules, enhancing infrastructure security, and/or streamlining service operations of theidentity interface service302.
• Further, theSPI framework348 may translate, map, or otherwise determine appropriate method calls and/or instructions for the service providers/data repositories310. These method calls and/or instructions may be based at least in part on the REST API call received and/or the service provider with which the request is associated. For example, and without limitation, the request/response handler344 may receive a request to update an identity relationship. The response may he formatted as a REST call from one of theclient applications304,306,308. The request/response handler344 may forward the request to theSPI framework348 where one or more different instructions or sets of instructions may be determined. For example, the instructions may be different depending on the service provider/data repository310 for which the request was intended. That is, if the request was for adatabase320, theSPI framework348 may determine a different instruction (or set of instructions) for updating identity relationship than if the request was for anLDAP identity store324.
• In some aspects, implementation of theSPI framework348 may include utilizing one or more Sins such as, but not limited to, anauthentication SPI350, anauthorization SPI352, aprofile SPI354, and/orother ID SPIs356. Additionally, theauthentication SPI350 may be configured to provide interaction with one or moreaccess management providers358 and/or one or more trust service providers360. Theauthorization SPI352 may be configured to provide interaction with the one or moreaccess management providers358. Theprofile SPI354 may be configured to provide interaction with one or moreidentity service providers362 and/ordirectory service providers364. Further, theother ID SPI356 may be configured to provide interaction with one or moreother service providers366 such as, but not limited to, password management services, policy management services, token exchange services, and/or user provisioning services. In this way, one or more individual SPIs may be responsible for communicating with the service providers/data repositories310 via thepluggable layer314. That is, theSPI framework348 may act as a proxy between theclient applications304,306,308 and the one ormore service providers310.
• Further, the example architectures, tools, and computing devices shown inFIGS. 1-3 are provided by way of example only. Numerous other operating environments, system architectures, and device configurations are possible. Accordingly, embodiments of the present disclosure should not be construed as being limited to any particular operating environment, system architecture, or device configuration.
• Illustrative Processes
• FIG. 4 depicts asimplified process flow400 of an example device registration performed in conjunction with the single sign-on (SSO) management as described above. In some examples, thesimplified process flow400 may be performed by one or more computing devices such as, but not limited to, theuser devices104 and/or the identityinterface service computers120 ofFIG. 1. In some aspects, a mobile user402 may access a mobile device such as, but not limited to, theuser device104 ofFIG. 1 and/or theuser device202 ofFIG. 2. Additionally, in some examples, the mobile device may include a business application404 (e.g., a browser application, a native application, etc.) and/or an SSO application406 (e.g., the security agent application discussed above at least with reference toFIGS. 1,2). Further, in some examples, the mobile device may interact with a REST server408 (or other identity service) and/or one or more service providers410 (e.g., an access management service and/or servers hosting data for the mobile applications of the mobile device via one ormore networks412. As noted above, at least with reference tonetworks114 ofFIG. 1 and/or thenetworks216 ofFIG. 2, any number and/or combination of networks (wired and/or wireless) may be suitable.
• In at least one non-limiting example, theprocess flow400 may begin when the mobile user402 attempts to access the business application404, at414. In response, the business application404 may attempt to get (e.g., make a request for) session and/or access tokens from thesecurity agent application406, at416. At418, thesecurity agent application406 may present a log-in page to the mobile user402 in order to request user credentials (e.g., user identifier (ID), password, etc). In response, the mobile user402 may provide such user credentials to thesecurity agent application406, at420. In some examples, thesecurity agent application406 may then attempt to register the device of the mobile user402 by providing the user credentials, attributes, and/or context information (e.g., the security agent application ID) to theREST server408 via thenetworks412, at422. At424, theREST server408 may transmit an authentication request including the at least the user credentials to theservice provider410. In some examples, an SSO application handle may be generated at426 to indicate a log-in and/or registration session, in some examples, in conjunction with theREST service408 providing attributes and/or SSO application ID to theservice provider410, at428. At430, theservice provider410 may return a device handle for indicating the registration session for the mobile device. Further, at432, theREST server408 may transmit the SSO application handle and the device handle to thesecurity agent application406, thus indicating that the mobile device has been registered. That is, theprocess400 may provide a device token to the mobile device which can be used to indicate that the mobile device has been registered for the SSO service.
• FIG. 5 depicts asimplified process flow500 of an example application registration performed in conjunction with the single sign-on (SSO) management as described above. In some examples, thesimplified process flow500 may be performed by one or more computing devices such as, but not limited to, theuser devices104 and/or the identityinterface service computers120 ofFIG. 1. In some aspects, a mobile user502 may access a mobile device such as, but not limited to, theuser device104 ofFIG. 1 and/or theuser device202 ofFIG. 2. Additionally, in some examples, the mobile device may include a business application504 (e.g., a browser application, a native application, etc.) and/or an SSO application506 (e.g., the security agent application discussed above at least with reference toFIGS. 1,2). Further, in some examples, the mobile device may interact with a REST server508 (or other identity service) and/or one or more service providers510 (e.g., an access management service and/or servers hosting data for the mobile applications of the mobile device) via one ormore networks512. As noted above, any number and/or combination of networks (wired and/or wireless) may be suitable.
• in at least one non-limiting example, theprocess flow500 may begin when the mobile user502 attempts to access the business application504, at514. In response, the business application504 may attempt to get (e.g., make a request for) session and/or access tokens from thesecurity agent application506, at516. At518, thesecurity agent application506 may present a log-in page to the mobile user502 in order to request user credentials (e.g., user ID, password, etc.). In response, the mobile user502 may provide such user credentials to thesecurity agent application506, at520. In some examples, thesecurity agent application506 may then attempt to register the business application by providing the user credentials, attributes, and/or context information (e.g., the security agent application ID) to theREST server508 via thenetworks512, at522. At524, theREST server508 may transmit an authentication request including the at least the user credentials to theservice provider510. In some examples, an SSO application handle may be generated, at526 to indicate a log-in and/or registration session, in some examples, in conjunction with theREST service508 providing attributes and/or SSO application ID to theservice provider510, at528. At530, theservice provider510 may return a device handle for indicating the registration session for the business application. Further, at532, theREST server508 may transmit the SSO application handle and the device handle to thesecurity agent application506, thus indicating that the business application has been registered. Thesecurity agent application506 may then transmit the application handle to the business application at534. That is, theprocess500 may provide an application (or client) token to the business application which can be used to indicate that the application has been registered for the SSO service. At536, the business application504 may transmit a request to get an access token from theREST server508. The REST server may provide the access token and/or may forward the request to theappropriate service provider510, at538.
• FIG. 6 depicts asimplified process flow600 of an example user log-in performed in conjunction with the single sign-on (SSO) management as described above. In some examples, thesimplified process flow600 may be performed by one or more computing devices such as, but not limited to, theuser devices104 and/or the identityinterface service computers120 ofFIG. 1. In this example, a mobile user602 may access a mobile device such as, but not limited to, theuser device104 ofFIG. 1 and/or theuser device202 ofFIG. 2. Additionally, in some examples, the mobile device may include a business application604 (e.g., a native application including, but not limited to, a tax application, a directory application, an expense report application, etc.) and/or an security agent application606 (e.g., the security agent application discussed above at least with reference toFIGS. 1,2). Further, in some examples, the mobile device may interact with a REST server608 (or other identity service) and/or one or more service providers610 (e.g., an access management service, an identity service, and/or servers hosting data for the mobile applications of the mobile device) via one ormore networks612. As noted above, any number and/or combination of networks (wired and/or wireless) may be suitable.
• In at least one non-limiting example, theprocess flow600 may describe a scenario when the mobile user602 specifically uses a business application604 of the mobile device a native application of the mobile device is used as opposed to a browser application of the mobile device). Theprocess flow600 may begin when the mobile user602 attempts to access the business application604, at614. In response, the business application604 may attempt to get (e.g., make a request for) session and/or access tokens from thesecurity agent application606, at616. At618, thesecurity agent application606 may present a log-in page to the mobile user602 in order to request user credentials (e.g., user ID, password, etc.). In response, the mobile user602 may provide such user credentials to thesecurity agent application606, at620. In some examples, thesecurity agent application606 may then attempt to register and/or authenticate the business application604 by providing the user credentials, attributes, and/or context information (e.g., the security agent application ID) to theREST server608 via thenetworks612, at622. In one example theREST server608 may authenticate the mobile user602, at623, and generate or otherwise obtain user and/or access tokens for the mobile device and/or mobile user602. However, in other examples, any other service provider such as theservice provider610 may perform the authentication. In this case, theREST server608 may receive user and/or access tokens from theservice provider610, at626. Either way, at theREST server608 may provide the user and/or access tokens to thesecurity agent application606 via thenetworks612. At630, thesecurity agent application606 may provide the user and/or access tokens to the business application604 and/or to the mobile user602. The business application604 may then provide application content (e.g., a page from a server or a page containing local content) to the mobile user602, at632.
• FIG. 7 depicts asimplified process flow700 of an example user log-in performed in conjunction with the single sign-on (SSO) management as described above. In some examples, thesimplified process flow700 may be performed by one or more computing devices such as, but not limited to, theuser devices104 and/or the identityinterface service computers120 ofFIG. 1. In this example, a mobile user702 may access a mobile device such as, but not limited to, theuser device104 ofFIG. 1 and/or theuser device202 ofFIG. 2. Additionally, in some examples, the mobile device may include a browser application704 (e.g., a web browser) and/or an security agent application706 (e.g., the security agent application discussed above at least with reference toFIGS. 1,2). Further, in some examples, the mobile device may interact with a web server707 (e.g., theweb application110 ofFIG. 1 configured to serve web pages), a REST server708 (or other identity service), and/or one or more service providers710 (e.g., an access management service, an identity service, and/or servers hosting data for the mobile applications of the mobile device) via one ormore networks712. As noted above, any number and/or combination of networks (wired and/or wireless) may be suitable.
• In at least one non-limiting example, theprocess flow700 may describe a scenario when the mobile user702 specifically uses abrowser application704 of the mobile device (i.e., a web browser of the mobile device is used as opposed to a native and/or business application of the mobile device). Theprocess flow700 may begin when the mobile user702 attempts to access thebrowser application704, at714. In response, thebrowser application704 may communicate this access attempt to theweb server707 via thenetworks712, at716. In some instances, theweb server708 may provide the access request information to the service providers710 (e.g., an identity management application or service), at718, to indicate to theservice provider710 that authentication may be requested in a future communication. At720, theservice provider710 may indicate or otherwise instruct thebrowser application704, via thenetworks712, to request user credentials from the mobile user702. Based at least on some configurations, thebrowser application704 may redirect the user credential request to thesecurity agent application706, at722. At724, thesecurity agent application706 may present a log-in page to the mobile user702 in order to request user credentials (e.g., user ID, password, etc. response, the mobile user702 may provide such user credentials to thesecurity agent application706, at726.
• In some examples, thesecurity agent application706 may then attempt to register and/or authenticate thebrowser application704 by providing the user credentials, attributes, and/or context information (e.g., the security agent application ID) to theREST server708 via thenetworks712, at728. In one example theREST server708 may authenticate the mobile user702 and generate or otherwise obtain user and/or access tokens for the mobile device and/or mobile user702. However, in other examples, any other service provider such as theservice provider710 may perform the authentication. In this case, theREST server708 may transmit the credentials to theservice provider710, at730, and receive user and/or access tokens from theservice provider710, at732. Either way, at734, theREST server708 may provide the user and/or access tokens to thesecurity agent application706 via thenetworks712. At736, thesecurity agent application706 may make a Web View or other method call to theservice provider710 in order to inject a cookie. In some aspects, thesecurity agent application706 may also redirect appropriate information to the browser application, at738, indicating which web pages should be served to the mobile user702. At740, thebrowser application704 may redirect this information to theweb server707. Further, at742, theweb server707 may serve the requested web pages to the mobile user702.
• FIGS. 8-10 illustrate simplified example flow diagrams showingrespective processes800,900, and1000 for providing single sign-on management. These processes are illustrated as logical flow diagrams, each operation of which represents a sequence of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and/or in parallel to implement the processes.
• Additionally, some, any, or all of the processes may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or combinations thereof. As noted above, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.
• In some aspects, theprocess800 ofFIG. 8 may be performed by the one or more user devices102 and/or identityinterface service computers120 ofFIG. 1. Theprocess800 may begin at802 by receiving a request to access a service provider. The request may be received from a first application of a mobile device. In some aspects, the first application may be a native application or a browser application. Additionally, in some cases, the request may be received by a security agent application (e.g., a helper application and/or authentication delegation application) of the mobile device. At804, theprocess800 may log in a user associated with the first application (e.g., the user of the mobile device). In some examples, in response to logging in the user, theprocess800 may provide a token for accessing the service provider to the first application, at806. Theprocess800 may end, at808, by providing a second token to a second application of the mobile device that is associated with the user. In this way, single sign-on may be achieved and the user does not need to be authenticated multiple times to access multiple service providers via multiple applications.
• FIG. 9 illustrates a simplified example flow diagram showing theprocess900 for providing features of single sign-on management. In some aspects, theprocess900 ofFIG. 9 may be performed by the one or more user devices102 and/or identityinterface service computers120 ofFIG. 1. Theprocess900 may begin at902 by receiving a request to access a first remote application. The remote application may be a server or other computer configured to provide application functionality to a mobile application or mobile device. In some cases, the request may be received from a first local application of a mobile device, the local application configured to communicate or otherwise receive content from the remote application. The first local application may be “local” in that it is executed by or otherwise resides on the mobile device. At904, theprocess900 may provide an authentication request (e.g., based at least in part on the access request) to a remote authentication provider. Theprocess900 may also receive a first access token for accessing the first remote application, at906. In sonic cases, the first access token may be received from the remote authentication provider. At908, theprocess900 may provide the first access token to the first local application. At910, theprocess900 may end by providing a second access token to a second local application of the mobile device. This second access token may be for allowing the second local application to access a second remote application. In some cases, theprocess900 may provide the first and/or second access tokens to the first and/or second local applications, respectively, based at least in part on a successful log-in of a user, of the mobile device, and/or of the first and/or second local application.
• FIG. 10 illustrates a simplified example flow diagram showing theprocess1000 for providing features of single sign-on management. In some aspects, theprocess1000 ofFIG. 10 may be performed by the one or more user devices102 and/or identityinterface service computers120 ofFIG. 1. Theprocess1000 may begin by receiving, from a first local application of a mobile device, a request to request to access a first remote application. As noted above, the remote application may be a web service, a web server, and/or any service configured to provide data, processing, and/or services to the local application. At1004, theprocess1000 may provide an authentication request to a remote authentication provider. In some examples, at1006, theprocess1000 may also receive, from the remote authentication provider, a first access token for accessing the first remote application. That is, the first local application may need the access token in order to access the first remote application, indicating that the user, the mobile device, and/or the local application have been authenticated. At1008, theprocess1000 may provide the first access token to the first local application. In some examples, theprocess1000 may also receive, at1010, from the remote authentication provider, a second access token for accessing a second remote application. That is, since the user, mobile device, and/or local application have already been authenticated, the remote authentication device may proactively provide access tokens for accessing other remote applications that are within a particular trusted group (e.g., a circle of trust or circle of trust). At1012, theprocess1000 may receive, from a second local application of the mobile device, a request to access the second remote application. In this example, theprocess1000 has already received the access token for accessing the second remote application. Thus, theprocess1000 may end, at1014, by providing the second access token to the second local application.
• Illustrative Systems
• FIG. 11 is a simplified block diagram illustrating components of asystem environment1100 that may be used in accordance with an embodiment of the present disclosure. As shown,system environment1100 includes one or moreclient computing devices1102,1104,1106,1108, which are configured to operate a client application such as a web browser, proprietary client (e.g., Oracle Forms), or the like. In various embodiments,client computing devices1102,1104,1106, and1108 may interact with aserver1112.
• Client computing devices1102,1104,1106,1108 may be general purpose personal computers (including, by way of example, personal computers and/or laptop computers running various versions of Microsoft Windows and/or Apple Macintosh operating systems), cell phones or PDAs (running software such as Microsoft Windows Mobile and being Internet, e-mail, SMS, Blackberry, or other communication protocol enabled), and/or workstation computers running any of a variety of commercially-available UNIX or UNIX-like operating systems (including without limitation the variety of GNU/Linux operating systems). Alternatively,client computing devices1102,1104,1106, and1108 may be any other electronic device, such as a thin-client computer, Internet-enabled gaming system, and/or personal messaging device, capable of communicating over a network (e.g.,network1110 described below). Althoughexemplary system environment1100 is shown with four client computing devices, any number of client computing devices may be supported. Other devices such as devices with sensors, etc. may interact withserver1112.
• System environment1100 may include anetwork1110. Network110 may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols, including without limitation TCP/IP, SNA, IPX, AppleTalk, and the like. Merely by way of example,network1110 can be a local area network (LAN), such as an Ethernet network, a Token-Ring network and/or the like; a wide-area network; a virtual network, including without limitation a virtual private network (VPN); the Internet; an intranet; an extranet; a public switched telephone network (PSTN); an infra-red network; a wireless network (e.g., a network operating under any of the IEEE 802.11 suite of protocols, the Bluetooth protocol known in the art, and/or any other wireless protocol); and/or any combination of these and/or other networks.
• System environment1100 also includes one ormore server computers1112 which may be general purpose computers, specialized server computers including, by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other appropriate arrangement and/or combination. In various embodiments,server1112 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example,server1112 may correspond to a server for performing processing described above according to an embodiment of the present disclosure.
• Server1112 may run an operating system including any of those discussed above, as well as any commercially available server operating system.Server1112 may also run any of a variety of additional server applications and/or mid-tier applications, including HTTP servers, FTP servers, GCI servers, Java servers, database servers, and the like. Exemplary database servers include without limitation those commercially available from Oracle, Microsoft, Sybase, IBM and the like.
• System environment1100 may also include one ormore databases1114,1116,Databases1114,1116 may reside in a variety of locations. By way of example, one or more ofdatabases1114,1116 may reside on a non-transitory storage medium local to (and/or resident in)server1112. Alternatively,databases1114,1116 may be remote fromserver1112, and in communication withserver1112 via a network-based or dedicated connection. In one set of embodiments,databases1114,1116 may reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any necessary files tier performing the functions attributed toserver1112 may be stored locally onserver1112 and/or remotely, as appropriate. In one set of embodiments,databases1114,1116 may include relational databases, such as databases provided by Oracle, that are adapted to store, update, and retrieve data in response to SQL-formatted commands.
• FIG. 12 is a simplified block diagram of acomputer system1200 that may be used in accordance with embodiments of the present disclosure. Forexample servers122 and/or1212 may be implemented using a system such assystem1200.Computer system1200 is shown comprising hardware elements that may be electrically coupled via abus1224. The hardware elements may include one or more central processing units (CPUs)1202, one or more input devices1204 (e.g., a mouse, a keyboard, etc.), and one or more output devices1206 (e.g., a display device, a printer, etc.).Computer system1200 may also include one ormore storage devices1208. By way of example, the storage device(s)1208 may include devices such as disk drives, optical storage devices, and solid-state storage devices such as a random access memory (RAM) and/or a read-only memory (ROM), which can be programmable, flash-updateable and/or the like.
• Computer system11200 may additionally include a computer-readablestorage media reader1212, a communications subsystem1214 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and workingmemory1218, which may include RAM and ROM devices as described above. In some embodiments,computer system1200 may also include aprocessing acceleration unit1216, which can include a digital signal processor (DSP), a special-purpose processor, and/or the like.
• Computer-readablestorage media reader1212 can further be connected to a computer-readable storage medium1210, together (and, optionally, in combination with storage device(s)1208) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information.Communications system1214 may permit data to be exchanged withnetwork1212 and/or any other computer described above with respect tosystem environment1200.
• Computer system1200 may also comprise software elements, shown as being currently located within workingmemory1218, including an operating system1220 and/orother code1222, such as an application program (which may be a client application, Web browser, mid-tier application, RDBMS, etc.). In an exemplary embodiment, workingmemory1218 may include executable code and associated data structures used for relying party and open authorization-related processing as described above. It should be appreciated that alternative embodiments ofcomputer system1200 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both, Further, connection to other computing devices such as network input/output devices may be employed.
• Storage media and computer readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to, volatile and non-volatile (non-transitory), removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules, or other data, including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium which can be used to store or transmit the desired information and which can be accessed by a computer.
• Although specific embodiments of the disclosure have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the disclosure. Embodiments of the present disclosure are not restricted to operation within certain specific data processing environments, but are free to operate within a plurality of data processing environments. Additionally, although embodiments of the present disclosure have been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described series of transactions and steps.
• Further, while embodiments of the present disclosure have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present disclosure. Embodiments of the present disclosure may be implemented only in hardware, or only in software, or using combinations thereof.
• The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that additions, subtractions, deletions, and other modifications and changes may be made thereunto without departing from the broader spirit and scope. Illustrative methods and systems for providing statistically triggered data placement are described above. Some or all of these systems and methods may, but need not, be implemented at least partially by architectures such as those shown inFIGS. 1-10 above.
• Although embodiments have been described in language specific to structural features and/or methodological acts, it is to be understood that the disclosure is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as illustrative forms of implementing the embodiments. Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments could include, while other embodiments do not include, certain features, elements, and/or steps. Thus, such conditional language is not generally intended to imply that features, elements, and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and/or steps are included or are to be performed in any particular embodiment.

Claims (20)

What is claimed is:

1. A system, comprising:

a memory storing a plurality of instructions; and

one or more processors configured to access the memory, wherein the one or more processors are further configured to execute the plurality of instructions to:

receive, from a first application, an authentication request associated with a second application; and

provide, to the first application, an access token for allowing the second application to access a service provider accessible to the first application or the second application.

2. The system ofclaim 1, wherein the first application comprises a security agent application of a mobile device, the security agent configured to provide single sign-on for at least one of the second application or other applications of the mobile device.

3. The system ofclaim 1, wherein the first application comprises a native application of a mobile device, the native application configured to provide single sign-on for at least one of the second application or other applications of the mobile device.

4. The system ofclaim 3, wherein the native application is configured with an embedded web browser.

5. The system ofclaim 1, wherein the one or more processors are further configured to execute the plurality of instructions to determine, based at least in part on a credential included in the authentication request, when a user is authenticated, and wherein the determination is based at least in part on receiving, from a third-party service, an indication that the user is authenticated.

6. A computer-readable memory storing a plurality of instructions executable by one or more processors, the plurality of instructions comprising:

instructions that cause the one or more processors to receive, from a first application, a request to access a service provider;

instructions that cause the one or more processors to log in a user associated with the first application;

instructions that cause the one or more processors to provide, to the first application, a token for accessing the service provider; and

instructions that cause the one or more processors to provide a second token to a second application associated with the user.

7. The computer-readable memory ofclaim 6, wherein the first application comprises an security agent application of a mobile device configured to provide single sign-on for the second application.

8. The computer-readable memory ofclaim 7, wherein the second application comprises a browser application of the mobile device associated with a web application service provider, a native application of the mobile device associated with an application service provider, or a hybrid application of the mobile device configured as a native application with an embedded browser associated with a hybrid application service provider.

9. The computer-readable memory ofclaim 6, wherein the first application comprises a browser application of a mobile device associated with a web application service provider and the second application comprises a native application of the mobile device associated with an application service provider.

10. The computer-readable memory ofclaim 6, wherein the first application comprises a native application of a mobile device associated with an application service provider.

11. The computer-readable memory ofclaim 10, wherein the second application comprises a browser application of the mobile device associated with a web application service provider.

12. The computer-readable memory ofclaim 10, wherein the second application comprises a second native application of the mobile device associated with a second application service provider.

13. The computer-readable memory ofclaim 6, wherein the log in comprises authenticating the user with authentication service using a representational state transfer (REST) method call.

14. The computer-readable memory ofclaim 6, wherein the second token provided to the second application enables the second application to log in to an application service provider associated with the second application on behalf of the user without the user providing log-in credentials to log in to the application service provider associated with the second application.

15. A computer-implemented method, comprising:

receiving, by a computer system, a request to access a first remote application, the request received from a first local application of a mobile device;

providing, by the computer system, an authentication request o a remote authentication service provider computer;

receiving, by the computer system, a first access token for accessing the first remote application;

providing, by the computer system, the first access token to the first local application; and

providing, by the computer system, a second access token for accessing a second remote application, the second access token provided to a second local application of the mobile device.

16. The computer-implemented method of15, wherein the authentication request is provided to the remote authentication service provider as a representational state transfer (REST) method call.

17. The computer-implemented method of15, wherein the authentication request is provided to request authentication of a user of the mobile device.

18. The computer-implemented method ofclaim 17, wherein the first access token is received from the remote authentication service provider based at least in part on authentication of the user.

19. The computer-implemented method ofclaim 15, further comprising receiving, by the computing system, the second access token from the remote authentication service provider.

20. The computer-implemented method ofclaim 15, wherein the second access token is provided to the second local application at least in response to a request from the second local application to access the second remote application.

Images