CN111712819A

CN111712819A - Merging identities

Info

Publication number: CN111712819A
Application number: CN201880089141.1A
Authority: CN
Inventors: P·亚雷德; T·科梅茨; J·苏罗韦茨; M·盖多斯; O·埃尔纳加
Original assignee: Citrix Systems Inc
Current assignee: Citrix Systems Inc
Priority date: 2017-12-21
Filing date: 2018-12-14
Publication date: 2020-09-25
Also published as: EP3729320A1; US11316860B2; US20190199729A1; EP3729320A4; AU2018388459A1; CA3086176A1; WO2019125966A1; AU2018388459B2

Abstract

According to various embodiments, a consolidated identity system and method is implemented to provide improved identity management and resource access management, particularly in the case of enterprise systems that require a tight trust model. In at least one embodiment, the described systems and methods provide a mechanism for mapping identities between resources. The system and method can extract information related to a particular entity, such as an employee or user, and can consolidate and/or personalize the information as needed.

Description

Merging identities

Cross Reference to Related Applications

This application claims the benefit of U.S. provisional application serial No. 62/608,581, "merge identity" (attorney docket No. SPH004-pro v), filed on 21/12/2017, the entire contents of which are incorporated herein by reference.

Technical Field

This document relates to techniques for managing authentication and identity in an online environment.

Background

Identity management is a key aspect of many organizations, providing important information about which users are authorized to access and use which resources, either within a single organization or across multiple organizations. Typically, many different resources within an organization are managed using multiple identity management systems, each having a different access protocol and maintaining a separate set of user records. Each such identity management system typically relies on an identity provider that maintains a database of user records that store credentials indicating which users may access which resources. When a user attempts to access a resource, the resource provider may consult the identity provider to verify whether the user is authorized to access the resource. If the user is authorized, the resource will grant access to the user. However, when multiple identity management systems are used for many different resources, the task of determining whether to grant access rights is significantly more complex, especially when the same user may have different electronic identities across different systems.

Federated identity is a known technique for linking an electronic identity and/or attributes of a person across multiple identity management systems. It allows individual parties to establish loosely coupled trust relationships so that an identity provider can guarantee a single service provider that a person has logged into the identity provider's system. For example, a user may log into an airline website and subsequently rent a car from a car rental website without having to manually log in again; more specifically, a previous login from the airline website is used to automatically identify the user and provide access to his or her identity-related information on the car rental website. As another example, a user may log into an identity provider (e.g., AOL) and then visit another website (e.g., weather website); AOL login is automatically used to identify a user on a weather website and provide access to his or her identity-related information on the weather website.

Often, federated identities operate with a loose trust model between the identity provider and the service provider. Federated identity systems typically include mechanisms for controlling which identity information should be shared between identity providers and service providers. The unique identifier of the identity is shared in order to bind different accounts with the identity provider and the service provider.

Liberty alliance projects have developed guidelines and best practices for identity management including federated identities. It has developed a specification, later evolved into Security Assertion Markup Language (SAML), that provides a clear separation of identity information between an identity provider and a service provider and includes the option of an opaque token so that the service provider does not have access to any identifiable information about the identity.

Referring now to FIG. 1, there is shown a block diagram depicting a conceptual model for identity management including federated identities in accordance with the prior art. The user 101 logs in 105 with an identity provider 402 (e.g. AOL). Subsequently, the user 101 wants to rent a car from a service provider 102 (e.g., Hertz). Identity binding 106 allows identity provider 402 to provide service provider 102 with information that allows service provider 102 to automatically identify user 101. Once service provider 102 identifies user 101, service provider 102 may access information specific to user 101, such as rental history 104, which is stored in resources controlled by service provider 102. Notably, however, service provider 102 does not gain access to information stored in resources controlled by identity provider 402, such as AOL account history and information 103. In this way, separation between identity provider 402 and service provider 102 remains even if they share enough information to allow identification of user 101 based on authentication at identity provider 402.

Federated identities of this type are well known; for example, Google and Facebook logins may be used on many websites, allowing authentication at other websites based on the user's Google or Facebook login. Federated identities have also been widely adopted in enterprise environments due to the popularity of standards such as SAML, so that users can use single sign-on for various local deployments (e.g., hosted in customer-owned data centers) and cloud systems (e.g., remotely hosted in third-party data centers).

However, federated identities may not be suitable for enterprise systems that require a tight trust model. Many enterprise environments require a very tight trust relationship between identity provider 402 and service provider 102. In this case, many service providers 102 are hosted by the enterprise itself, and those service providers 102 outside the enterprise are subject to strict security controls and compliance to ensure that employee data remains secure.

A direct consequence of federated identities is that all data related to an identity is distributed across a large number of systems. For example, employee data is hosted in many systems, including payroll, human resource management, financial and ticketing systems. Federated identities therefore provide only a limited solution in which access to a variety of relatively static data sources is provided.

At the end of the 90 s of the 20 th century and early in the 21 st century, there was a push to provide a community of users with an enterprise portal that would provide a window or "portlet" to each system they need to access. In such an arrangement, each portlet accesses the source system and retrieves information related to the employee. However, setting up integration for each system may be overly complex. In addition, this arrangement may cause performance problems because the loading speed of each portlet can be very slow and it is difficult for an employee to sort all information among all portlets.

Thus, currently, identity management within an enterprise environment is inefficient and cumbersome. While existing solutions provide a mechanism for single sign-on to multiple resources, accessing complete data still requires separate access to each resource containing relevant data.

Disclosure of Invention

According to various embodiments, a system and method for implementing an improved mechanism called merging identities is described. Merging identities solves the above-mentioned problems, especially in the case of enterprise systems that require a tight trust model. For example, in this case, the enterprise itself may be the primary identity provider, and service providers that provide services such as payroll and vacation requests do not maintain any data not belonging to the enterprise. In this way, no significant identity separation is required between the identity provider and the service provider.

In at least one embodiment, the described systems and methods provide a mechanism for mapping identities between resources. The system and method can extract information related to a particular entity, such as an employee or user, and can consolidate and/or personalize the information as needed.

Further details and variations are described herein.

Drawings

The drawings illustrate several embodiments together with the description. Those skilled in the art will recognize that the particular embodiments illustrated in the figures are merely exemplary and are not intended to limit the scope.

FIG. 1 is a block diagram illustrating a conceptual model for identity management including federated identities, according to the prior art.

FIG. 2 is a block diagram depicting an architecture for storing limited data related to federated identities across multiple systems within an enterprise.

FIG. 3 is a diagram depicting relationships between users and data about the users that may be hosted in various enterprise systems.

FIG. 4 is a diagram depicting an example of a method of mapping user identities to verify authorization, according to one embodiment.

FIG. 5 is a diagram depicting a method of enabling chained authentication of access to a service according to one embodiment.

FIG. 6 is a diagram depicting an example of a method of mapping a user's identity from an identity provider to a service provider, importing rights, and filtering access based on the user's identity, according to one embodiment.

Fig. 7 is a diagram depicting an example of a method for copying security authorization from a service provider in a merged identity framework, according to one embodiment.

FIG. 8 is a diagram depicting an example of a method for using the described techniques in conjunction with a service provider using dynamic, logic-based security authorization by accessing the service provider to request rights information, according to one embodiment.

FIG. 9 is a diagram depicting an example of a method of using delegated authentication when writing back to a service provider using an API, according to one embodiment.

FIG. 10 is a diagram depicting an example of a method of automatically logging in a user using single sign-on to enable write back in a system that does not support delegated authentication, according to one embodiment.

FIG. 11 is a diagram depicting an example of a method for directly performing a write back action using a deep link to a related page, according to one embodiment.

Fig. 12 is a diagram depicting the overall conceptual architecture for a consolidated identity system, in accordance with one embodiment.

Fig. 13 is a block diagram depicting a hardware architecture of a client device that may be used in conjunction with the architectures depicted in fig. 12 and/or 14, according to one embodiment.

Fig. 14 is a block diagram depicting the overall physical architecture for a consolidated identity system, in accordance with one embodiment.

Detailed Description

According to various embodiments, the system may be implemented on any electronic device or a group of interconnected electronic devices, each equipped to receive, store, and present information. Each electronic device may be, for example, a server, a desktop computer, a laptop computer, a smart phone, a tablet computer, and the like. As described herein, some devices used in connection with the systems described herein are designated as client devices, which are typically operated by end users. The other devices are designated as servers, which typically perform backend operations and communicate with client devices (and/or other servers) via a communication network such as the internet.

However, those skilled in the art will recognize that the techniques described herein may be implemented in other cases and in virtually any suitable device, set of devices, or system capable of interfacing with existing enterprise data storage systems. Accordingly, the following description is intended to illustrate various embodiments by way of example, and not to limit the scope.

As described above, merging identities provides an improved mechanism suitable for operating across high trust networks. In an enterprise, which is itself the primary identity provider, service providers that provide services such as payroll and vacation requests do not maintain any data that is not intended to belong to the enterprise. No significant identity separation between the identity provider and the service provider is required.

In at least one embodiment, because of the sensitivity of employee data and the need for self-service access to the data, consolidated identities provide additional functionality to meet many requirements beyond a single customer master plan, where all information about the customer is consolidated into a single database.

Referring now to FIG. 3, a diagram depicting the relationship between a user 101 and data 301 about the user that may be hosted in various enterprise systems is shown. Such data may include, for example, PTO approval 301A, PTO request 301B, purchase order 301C, fee approval 301D, service ticket 301E, and metrics 301F.

Providing access to limited data in federated identity systems

Referring now to FIG. 2, a block diagram is shown depicting an architecture for providing access to limited data related to federated identities across multiple systems within an enterprise. In this architecture, a user 101 logs in 105 with an identity provider 402. Here, identity provider 402 may be implemented within an enterprise, for example using a Directory service such as the Active Directory available from Microsoft Corporation of Redmond, Washington. As in the example of fig. 1, identity binding 106 defines a relationship between the identity of user 101 at identity provider 402 and an account (e.g., salesforce. Here, however, due to the tight trust model within an enterprise, identity provider 402 and service provider 102 also share identity attributes 203 (e.g., location and team) that may be stored at resources controlled by identity provider 402, and service provider data 204 (e.g., account history) that may be stored at resources controlled by service provider 102.

Framework

Referring now to fig. 14, a diagram depicting the overall physical architecture for a consolidated identity system in accordance with one embodiment is shown.

Client device 1301 is any electronic device that operates under the control of user 101 and may be used to request and receive information from server-based components via communications network 1309. The communications network 1309 may be any suitable electronic network for transmitting electronic data; examples include the internet, intranets, wireless networks, and the like. In at least one embodiment, client device 1301 accesses portal application 1402 running in the data center to request and receive data. In at least one embodiment, a Virtual Private Network (VPN)1401 may be used to improve the security of such access, as is known in the art.

The consolidated identity module 1206 performs various functions described herein, including authenticating the user 101 based on identity information obtained from the identity provider 402, which identity provider 402 may be, for example, an active directory. Once user 101 is authenticated, merge identity module 1206 issues a data request from service provider 602 on behalf of user 101 using enterprise software available from, for example, SAP SE, Walldorf, Germany. In at least one embodiment, the merge identity module 1206 caches the currently relevant activity data in the temporary store 1403; any changes may be later transmitted to service provider 602, as described in more detail below.

Referring now to fig. 12, a diagram depicting the overall conceptual architecture for a merged identity system is shown, in accordance with one embodiment. In at least one embodiment, the merged identity system 1206 described herein includes functionality to provide chained authentication 1207, user identity mapping 1208, access controls 1209, and active data permissions 1210 for enterprise systems.

In at least one embodiment, the consolidated identity module 1206 interacts with various components of the enterprise. The endpoint management system 401 (e.g., including an Enterprise Mobility Management (EMM) system), directory 1201, and identity provider 402 provide functionality for user authentication 1202, user identity/name 1203, access control group 1204, and/or user attributes 1205. One example of an Endpoint Management system 401 that may be used in conjunction with the described system is Citrix Endpoint Management available from Citrix corporation of loddurberg, florida and santa clara, california. The merge identity module 1206 also interacts with various software functions, such as a native application 1215, a cloud application 1216, and/or a proprietary application 1217, each of which may provide an application authentication 1211, a user identity/name 12103, access control groups and policies 1213, and/or activity data 1214.

Referring now to fig. 13, a block diagram depicting a hardware architecture of a client device 1301 is shown, according to one embodiment, the client device 1301 may be used in conjunction with the architectures depicted in fig. 12 and/or 14. Client device 1301 may be any electronic device equipped to receive, store, and/or present information, and to receive user input related to such information. Client device 1301 may be, for example, a desktop computer, a laptop computer, a Personal Digital Assistant (PDA), a cellular telephone, a smart phone, a music player, a handheld computer, a tablet computer, a kiosk, a gaming system, or the like.

In at least one embodiment, client device 1301 has many hardware components well known to those skilled in the art. The input device 1302 may be any element that receives input from the user 101, including, for example, a keyboard, mouse, stylus, touch-sensitive screen (touch screen), touch pad, trackball, accelerometer, five-way switch, microphone, and the like. Input may be provided via any suitable mode, including, for example, one or more of the following: pointing, tapping, typing, dragging, and/or speech. Each user 101 may be, for example, an end user or a system administrator.

The data storage 1306 may be any magnetic, optical, or electronic storage device for data in digital form; examples include flash memory, magnetic hard drives, CD-ROMs, DVD-ROMs, and the like.

The display 1303 may be any element that graphically displays information, such as notifications, data representations, user interface elements, prompts, and the like. Such output may include, for example, raw data, data visualizations, navigation elements, queries requesting confirmation, and/or parameters for information identification, display, or representation, and so forth. In at least one embodiment, where only some desired output is presented at a time, dynamic controls, such as a scrolling mechanism, may be available via input device 1302 to change the information currently displayed, and/or to change the manner in which the information is displayed.

In at least one embodiment, the information displayed on the display 1303 may include data in textual and/or graphical form, and may include various controls and elements for interacting with the displayed data, e.g., to disarm an alarm, follow a link, forward an alarm, investigate further, and/or perform other actions.

The processor 1304 may be a conventional microprocessor that operates on data under the direction of software in accordance with well-known techniques. The memory 1305 may be a random access memory having a structure and architecture known in the art for use by the processor 1304 in running software.

Data storage 1306 may be local or remote to other components of client device 1301. The communication module 1307 provides functionality for communicating with other components of the system via a communication network 1309 (e.g., the internet), for example, to issue information requests, perform authentication, receive notifications, and/or perform other operations. Such communication between client device 1301 and other components may occur wirelessly through an ethernet connection, via a computing network such as the internet, via a cellular network, or by any other suitable means.

In at least one embodiment, data storage device 1306 is removable in the form of a CD-ROM, DVD, flash drive, USB hard drive, or the like. In another embodiment, data storage device 1306 is fixed within client device 1301.

In one embodiment, the system may be implemented as software written in any suitable computer programming language, whether standalone or client/server architecture. Alternatively, it may be implemented and/or embedded in hardware.

The systems and methods described herein may be implemented on an architecture such as that shown in fig. 12 and 13. However, those skilled in the art will recognize that other architectures may be used. Thus, the description provided herein is intended to be illustrative and not to limit the scope to any particular implementation or architecture.

In at least one embodiment, the merged identity framework includes five elements:

(1) merged activity data;

(2) authentication of one or more identity providers;

(3) authorization of the identity provider;

(4) authorization of the service provider; and

(5) write back to the service provider with delegation or direct authorization.

Those skilled in the art will recognize that these five elements may be implemented individually or in any combination. Each of which will be described in turn.

Consolidated activity data

In at least one embodiment, temporary store 1403 contains currently relevant activity data, such as activity data associated with employees from each service provider 602. Since access controls to employee data are also typically stored by each service provider 602, control is also synchronized to the temporary database.

In general, it is not necessary to consolidate all data for the employee; instead, only the active data need be merged. For example, the merged identity request may be for only open vacation requests, rather than for every vacation request ever made by active and inactive employees. Thus, activity data may be defined as a subset of all data of interest at any given time, such as open and recently changed records within a data set.

Sometimes it is not possible to merge some data. Thus, in at least one embodiment, traditional API mechanisms are used to provide rollback by extracting data as needed at any time. For example, if a user attempts to retrieve information from a database containing a large number of records. Given the large number of records, it may not be feasible to synchronize all of the data in all of the records and obtain the data from different sources. Thus, in at least one embodiment, some information may be synchronized, while other information may only be retrieved from the primary source as needed.

In at least one embodiment, when consolidating employee data, control is added to maintain data security. Such control may include, for example, authentication and/or authorization, as described in more detail below.

Authentication of one or more identity providers

One benefit of federated identity is the ability to use identity providers (e.g., active directory federated services) to enable single sign-on (SSO) across multiple service providers (e.g., Salesforce and SAP). However, it is not uncommon for there to be multiple identity providers providing authentication, whether for merger or for compliance reasons. In at least one embodiment, the merged identity framework described herein involves authentication via multiple identity providers, and also binds a user's account name across multiple identity providers.

Another common enterprise solution is to link identity providers, for example when a user authenticates an endpoint management system such as citrixndp management. For example, when the user 101 authenticates using a fingerprint, his or her identity is mapped to a user account in an identity provider, such as an active directory, to verify authorization.

Referring now to FIG. 4, a diagram is shown depicting an example of a method of mapping the identity of a user 101 to bind an authorization, in accordance with one embodiment. The user 101 logs in 403 via the endpoint management system 401. Based on the login information, the user 101 is matched 404 to user accounts on the identity provider 402 (which may be, for example, an active directory) to determine which resources the user 101 is authorized to access. In at least one embodiment, the system does not verify authorization. Instead, the system relies on local means to authenticate the user 101, for example via a fingerprint or password, and then retrieve information that the user 101 is allowed to access.

Authorization of identity provider

In at least one embodiment, the identity provider can provide appropriate authorization in relation to the user 101. Typically, the identity provider provides coarse-grained authorization via groups and attributes. For example, authorization may be provided for a group such as "east coast sales". Such authorization may be asserted in the consolidated identity framework described herein to enable access to services.

Referring now to FIG. 5, an example of a method of chain authentication to enable access to a service is shown, according to one embodiment. As with the method of fig. 4, a user 101 logs in 403 via the endpoint management system 401. Based on the login information, the user 101 is matched 404 to a user account on the identity provider 402. Authorization of user 101 by identity provider 402 is then retrieved 501 to determine which resources user 101 is authorized to access.

In this way, the system is able to determine which authorizations are available to the user 101, even if the authentication device itself does not know this information. The chained authentication referred to in fig. 5 allows two or more authentication providers to be provided, thereby providing improved functionality over conventional systems that provide authorization but do not provide authentication. More specifically, according to the described method, once the user 101 logs in, the system matches the user 101 to records in the identity provider 402 to determine which resources the user 101 is allowed to access, thereby providing a technique for chain authentication. In at least one embodiment, the described method can determine authorization via groups and attributes to enable access to services.

Authorization of service provider

In some cases, it may be desirable for a service provider to include fine-grained security control over data and records. For example, human resource systems often attempt to ensure that human resource personnel can only see data associated with their staff population.

The following is an example of three ways in which the consolidated identity framework can integrate service provider authorization.

1) Importing rights embedded in data records

Referring now to fig. 6, a diagram is shown depicting an example of a method of mapping the identity of a user 101 from an identity provider 402 (e.g., active directory 402) to a service provider 602, importing rights, and filtering access based on the identity of the user 101, according to one embodiment. In this manner, after a single location login, user 101 may be known system-wide via dynamic account mapping.

Many service providers (e.g., SAPs) include rights directly in the records, specifying who is authorized to do what work (e.g., approve a purchase order) on each record. In at least one embodiment, the consolidated identity framework maps the identity of user 101 from identity provider 601 to service provider 602.

For example, as shown in FIG. 6, user 101 logs in 601 with identity provider 402 as "jsmith" and is determined to be a member of a group called "administrator". On service provider 602 (SAP in this example), user 101 is referred to as "smithj 0422" and has access to view a record (e.g., purchase order 603) with smithj0422 as an approver. Further, service provider 602 specifies that user 101 is able to approve purchase order 604. Since these rights in the valid purchase order can be copied into temporary storage 1403, the consolidated identity framework imports the rights originating from service provider 602 and can filter the access appropriately based on the identity of user 101.

2) Synchronizing authorization groups and defined record filters

For service providers that use medium granularity filtering, such as established groups and defined record filters, such security authorizations can be copied into the merge identity framework and applied directly to temporary data. For example, the administrator only needs to access open vacation requests and should only see vacation requests of their employees. The employee should only be able to see his vacation request.

Referring now to fig. 7, a diagram depicting an example for using the described techniques in conjunction with a service provider 602 by replicating security authorizations (e.g., security groups) in a consolidated identity framework and applying such authorizations to cached data from the service provider 602 is shown, in accordance with one embodiment. In this example, user 101 logs in 601 with identity provider 402 as "jsmith". On the service provider 602 (SAP in this example), the user 101 is referred to as "smithj 0422" and is determined to be a member of a cache identity group defined at the service provider 602, referred to as "administrator". The security authorization is copied from the service provider 602 and placed into the merged ID framework. Such security authorizations may be associated with individual users and/or groups.

Thus, user 101 has the right to view cached purchase order 603 with smithj0422 as an approver. Further, service provider 602 specifies that user 101 is able to approve purchase order 604.

The method may also be combined across systems. For example, relevant employee HR data may be copied from the human resources system to temporary data storage along with the group and record filter specifications. The HR data may then be combined with HR data from other systems, each with its own group and record filter specifications. When the HR worker queries the temporary data store to extract the employee's merged view, he or she can only see the specific data that they are allowed to view as specified in each source system.

3) Consult the service provider at any time as needed to see what the user can do

Some service providers 602 use very dynamic, logic-based security authorization. In this case, the consolidated identity system accesses service provider 602 to request rights information. However, the merged identity system does not need to query actual data from multiple systems, but only the right to view the data.

Referring now to fig. 8, a diagram depicting an example of such a method is shown. The method of fig. 8 is similar to the method of fig. 7. However, here, upon determining that user 101 is referred to as "smithj 0422" on service provider 602, the system accesses service provider 602 to request rights information. Once the rights information is provided, the rights and restrictions specified by service provider 602 can be applied, such as the ability of user 101 to view cached purchase order 603, which is the approver, and to approve purchase order 604.

Thus, the technique shown in fig. 8 allows for more complex and/or more specific authorization. For example, the user 101 may be authorized to view records relating to a particular territory and/or dollar amount; this particular authorization may be enabled using the dynamic approach shown in fig. 8.

Write back to service provider

In at least one embodiment, temporary store 1403 is used as a result of merge identity module 1206; any data changes are returned directly to service provider 102.

One key aspect of write back is to verify the consistency of the temporary store. For example, before a purchase order of a particular amount can be approved, the system must first verify that the purchase order is still the correct amount and has not been changed to another amount in the source system.

Any of a variety of mechanisms may be used to perform write back to the service provider 102 depending on the service provider API capabilities and compliance with enterprise policies. Three examples of such mechanisms are described below.

1) API for delegating authentication using service accounts

In at least one embodiment, the merge identity framework can employ delegated authentication when writing back to the service provider 102 using the API. Referring now to fig. 9, a diagram depicting an example of such a process is shown. User 101 logs into identity provider 402 (902). When the user 101 performs an action 903 requiring a write back to the service provider 602, the merged identity framework uses the API to the service provider 602 and is authenticated by the service account 901 on behalf of the user 101. The user account at service provider 602 is then used 1005 to perform the write back at service provider 602.

In various embodiments, service provider 602 records 904 the fact that user 101 performed the action requiring the write back by recording user 101 as the originator of the write back, or by appending a comment to the record indicating that service account 901 performed the write back on behalf of user 101. Service provider 602 is the authenticator for the write back, but completes the write back on behalf of user 101.

2) API for user-based authentication using SSO

Some APIs, such as SAP BAPI, do not support delegated authentication and write back is only performed if user 101 has logged on to him or herself. In at least one embodiment, the merge identity framework can employ delegated authentication when writing back to the service provider 102 using an API. Referring now to fig. 10, a diagram is shown depicting an example of a method for automatically logging in to a user 101 using single sign-on to enable write back in a system that does not support delegated authentication, according to one embodiment.

User 101 logs in 1002 via identity provider 402 to a consolidated identity framework that supports single sign-on functionality 1001 of service provider 602. When the user 101 performs an action 903 requiring a write back to the service provider 602 (step 1), several steps occur. First, the user 101 is redirected to the login page of the service provider 602, the SSO 1001 automatically logs 1004 in 1004 to the user 101 (step 2), and then redirects the user 101 back to the consolidated identity system (step 3). Now the merged identity system now has to write back the necessary credentials using the credentials execution 1005 of the user 101 (steps 4 and 5).

3) Delivery to service providers using deep links

As a third approach, for systems that do not support API access or do not allow API access for compliance reasons, the user 101 may be deep-linked directly to the relevant page of the service provider application to perform write back actions directly by clicking a button or other workflow.

Referring now to fig. 11, an example of such a process is shown. User 101 logs in 1002 via identity provider 402 to a consolidated identity framework that supports single sign-on capability 1001 of service provider 602. When the user 101 performs 903 an action requiring a write back to the service provider 602, the user 101 is deeply linked 1104 to the service provider page and logs in using SSO. The user 101 may then manually perform 1105 a write back action directly within the service provider 602. Alternatively, the write back action may occur automatically.

Those skilled in the art will recognize that the examples depicted and described herein are merely illustrative, and that other arrangements of user interface elements may be used. Additionally, some of the depicted elements may be omitted or changed, and other elements may be depicted, without departing from essential characteristics.

The present system and method have been described in particular detail with respect to possible embodiments. Those skilled in the art will appreciate that the system and method may be practiced in other embodiments. First, the particular naming of the components, capitalization of terms, the attributes, data structures, or any other programming or structural aspect is not mandatory or significant, and the mechanisms and/or features may have different names, formats, or protocols. Further, the system may be implemented via a combination of hardware and software, or entirely in hardware elements or entirely in software elements. Moreover, the particular division of functionality between the various system components described herein is merely exemplary, and not mandatory; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component.

Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" or "in at least one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

Various embodiments may include any number of systems and/or methods for performing the above-described techniques, alone or in any combination. Another embodiment includes a computer program product comprising a non-transitory computer-readable storage medium and computer program code encoded on the medium for causing a processor in a computing device or other electronic device to perform the above-described techniques.

Some portions of the above are presented in terms of algorithms and symbolic representations of operations on data bits within a memory of a computing device. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, considered to be a self-consistent sequence of steps (instructions) leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Furthermore, it is also convenient at times, to refer to certain arrangements of steps requiring physical manipulations of physical quantities as modules or code devices, without loss of generality.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "displaying" or "determining" or the like, refer to the action and processes of a computer system, or similar electronic computing module and/or device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Certain aspects include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions can be embodied in software, firmware, and/or hardware, and when embodied in software, can be downloaded to reside on and be operated from different platforms used by a variety of operating systems.

This document also relates to apparatus for performing the operations herein. The apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computing device selectively activated or reconfigured by a computer program stored in the computing device. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, DVD-ROMs, magnetic-optical disks, read-only memories (ROMs), Random Access Memories (RAMs), EPROMs, EEPROMs, flash memory, solid-state drives, magnetic or optical cards, Application Specific Integrated Circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Further, the computing devices referred to herein may include a single processor, or may be architectures employing multiple processor designs for increased computing capability.

The algorithms and displays presented herein are not inherently related to any particular computing device, virtualization system, or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description provided herein. In addition, the systems and methods are not described with reference to any particular programming language. It should be appreciated that a variety of programming languages may be used to implement the teachings described herein, and any references above to specific languages are provided for disclosure of enablement and best mode.

Accordingly, various embodiments include software, hardware, and/or other elements for controlling a computer system, computing device, or other electronic device, or any combination or plurality thereof. Such electronic devices may include, for example, a processor, input devices (e.g., keyboard, mouse, touch pad, track pad, joystick, trackball, microphone, and/or any combination thereof), output devices (e.g., screen, speaker, etc.), memory, long-term storage devices (e.g., magnetic storage devices, optical storage devices, etc.), and/or a network connection, in accordance with techniques well known in the art. Such electronic devices may be portable or non-portable. Examples of electronic devices that may be used to implement the described systems and methods include: mobile phones, personal digital assistants, smart phones, all-in-one machines, server computers, enterprise computing devices, desktop computers, laptop computers, tablet computers, consumer electronic devices, and the like. The electronic device may use any operating system, such as, but not limited to: linux; microsoft Windows, available from Microsoft corporation of Redmond, Washington; MacOS X available from Apple Inc. of Cupertino, Calif.; iOS available from Apple inc. of cupertino, california; android available from Google, inc. of mountain view, california; and/or any other operating system suitable for use on a device.

While a limited number of embodiments have been described herein, those skilled in the art, having benefit of the above description, will appreciate that other embodiments are contemplated. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the subject matter. Accordingly, the disclosure is intended to be illustrative, but not limiting in scope.

Claims

1. A computer-implemented method for consolidating identity information across an enterprise comprising a plurality of enterprise systems, comprising:

copying a plurality of entitlements associated with a user from at least one of the enterprise systems to at least another one of the enterprise systems;

authenticating a user at an identity provider;

receiving a request from the user to access a resource associated with one of the enterprise systems;

determining whether the user is authorized to access the requested resource based on at least one copy of at least one entitlement;

in response to a determination that indicates that the user is authorized to access the requested resource, providing access to the requested resource; and

in response to a determination that indicates that the user is not authorized to access the requested resource, access to the requested resource is denied.

2. The method of claim 1, wherein:

each entitlement is associated with a group of users; and

determining whether the user is authorized to access the requested resource includes determining whether the user belongs to a group indicated as being authorized to access the requested resource in at least one copy of at least one entitlement.

3. The method of claim 1, wherein determining whether the user is authorized to access the requested resource comprises:

matching the user with an account on the identity provider;

retrieving at least one identity provider authorization for the user; and

determining whether the user is authorized to access the requested resource based on the retrieved at least one identity provider authorization.

4. The method of claim 1, wherein determining whether the user is authorized to access the requested resource comprises:

mapping a user identity on the identity provider to a second user identity on a service provider;

determining at least one right for the user at a service provider; and

importing the at least one right from the service provider to authorize access to the requested resource.

5. The method of claim 4, wherein importing the at least one right from the service provider comprises copying the at least one right into a temporary storage repository.

6. The method of claim 1, wherein determining whether the user is authorized to access the requested resource comprises:

determining, at the service provider, that the user is a member of a cached group of service providers;

determining, at the service provider, at least one entitlement for the user based on the user's membership in the cached group of service providers; and

7. The method of claim 6, wherein importing the at least one right from the service provider comprises copying the at least one right into a temporary storage repository.

8. The method of claim 6, wherein determining at least one right of the user comprises initiating access to a service provider to request rights information and receiving the requested rights information.

9. The method of claim 1, further comprising:

detecting a user action requesting a write back to a service provider;

identifying, at the service provider, an account associated with the user;

authenticating the user in connection with the identified account; and

the write back is performed using the identified account.

10. The method of claim 9, wherein authenticating the user in connection with the identified account comprises authenticating the user based on a single sign-on at the identity provider.

11. The method of claim 9, wherein performing the write back using the identified account comprises:

presenting a link to a service provider page to the user; and

receiving user input via the service provider page to perform the write back.

12. A non-transitory computer-readable medium for consolidating identity information across an enterprise comprising a plurality of enterprise systems, comprising instructions stored thereon which when executed by at least one processor perform the steps of:

authenticating a user at an identity provider;

13. The non-transitory computer-readable medium of claim 12, wherein:

each entitlement is associated with a group of users; and

14. The non-transitory computer-readable medium of claim 12, wherein determining whether the user is authorized to access the requested resource comprises:

matching the user with an account on the identity provider;

retrieving at least one identity provider authorization for the user; and

15. The non-transitory computer-readable medium of claim 12, wherein determining whether the user is authorized to access the requested resource comprises:

determining at least one right for the user at a service provider; and

copying at least one entitlement from the service provider into a temporary storage repository to authorize access to the requested resource.

16. The non-transitory computer-readable medium of claim 12, wherein determining whether the user is authorized to access the requested resource comprises:

copying the at least one entitlement from the service provider into a temporary storage repository to authorize access to the requested resource.

17. The non-transitory computer-readable medium of claim 16, wherein determining at least one right of the user comprises initiating access to a service provider to request rights information and receiving the requested rights information.

18. The non-transitory computer-readable medium of claim 12, further comprising instructions stored thereon that when executed by at least one processor perform the steps of:

detecting a user action requesting a write back to a service provider;

identifying, at the service provider, an account associated with the user;

authenticating the user in connection with the identified account; and

the write back is performed using the identified account.

19. The non-transitory computer-readable medium of claim 18, wherein authenticating the user in connection with the identified account comprises authenticating the user based on a single sign-on at the identity provider.

20. The non-transitory computer-readable medium of claim 18, wherein performing the write back using the identified account comprises:

presenting a link to a service provider page to the user; and

receiving user input via the service provider page to perform the write back.

21. A system for merging identity information across an enterprise comprising a plurality of enterprise systems, comprising:

a processor configured to:

copying a plurality of entitlements associated with a user from at least one of the enterprise systems to at least another one of the enterprise systems; and

authenticating a user at an identity provider; and

an input device configured to receive a request from the user to access a resource associated with one of the enterprise systems;

wherein the processor is further configured to:

22. The system of claim 21, wherein:

each entitlement is associated with a group of users; and

23. The system of claim 21, wherein determining whether the user is authorized to access the requested resource comprises:

matching the user with an account on the identity provider;

retrieving at least one identity provider authorization for the user; and

24. The system of claim 21, further comprising a temporary repository, wherein determining whether the user is authorized to access the requested resource comprises:

determining at least one right for the user at a service provider; and

copying at least one entitlement from the service provider into the temporary storage repository to authorize access to the requested resource.

25. The system of claim 21, further comprising a temporary repository, wherein determining whether the user is authorized to access the requested resource comprises:

copying the at least one entitlement from the service provider into the temporary storage repository to authorize access to the requested resource.

26. The system of claim 25, wherein determining at least one right of the user comprises initiating access to a service provider to request rights information and receiving the requested rights information.

27. The system of claim 21, further comprising:

detecting a user action requesting a write back to a service provider;

identifying, at the service provider, an account associated with the user;

authenticating the user in connection with the identified account; and

the write back is performed using the identified account.

28. The system of claim 27, wherein authenticating the user in connection with the identified account comprises authenticating the user based on a single sign-on at the identity provider.

29. The system of claim 27, wherein performing the write back using the identified account comprises:

presenting a link to a service provider page to the user; and

receiving user input via the service provider page to perform the write back.