Enabling access to an enterprise network domain based on a centralized trust

A method of establishing centralized trust includes, at a policy server having connectivity to a network, establishing a trust relationship with a first enterprise network domain and a second enterprise network domain. One or more criterion from a server in the first enterprise network domain are received by the policy server and a federation relationship is established between at least a portion of the first enterprise network domain and one or more entities in the second enterprise network domain based on the one or more criterion. Based on the federation relationship, the policy server enables the one or more entities in the second enterprise network domain to access the at least a portion of the first enterprise network domain.

TECHNICAL FIELD

The present disclosure relates to security services and, more specifically to identity and federation management.

BACKGROUND

The Internet of Everything (IoE) is creating many new scenarios where both people and things (i.e., machines or devices) in an enterprise environment are interconnected through the enterprise's information technology (IT) infrastructure to form an enterprise ecosystem (i.e., an enterprise network domain). Moreover, enterprises are now partnering to form partner ecosystems that allow partner vendors to service enterprise devices or provide other support services to the enterprise ecosystem. The number of IT partners supporting or otherwise connected to an enterprise ecosystem can be very large, thereby causing the enterprise ecosystem to become quite complex. Enterprise ecosystems become even more complex when IT partners connect through the cloud. Due to the increased use of cloud infrastructure and the increased number of partnerships, the overall infrastructure complexity is rapidly increasing.

In order to utilize partner ecosystems, enterprises frequently look for identity brokerage services to allow users from partner enterprises to access their resources and infrastructure. Remote Authentication Dial-In User Service (RADIUS), which was designed with an enterprise focus, is one of the most commonly used protocols for authenticating network-based and remote-access users (or even devices) when devices and/or users need authentication services to access resources included in an enterprise network domain. Additionally, in some instances, two enterprises may agree to form a federation relationship that helps broker information from one identity database in a first enterprise network domain to another that is maintained and managed by a different enterprise network domain. In a federation relationship, the partner enterprises are interconnected and configured to operate in a common management framework under a common management authority. The interdependency between different entities in cross-domain relationships further increases the infrastructure complexity.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

Techniques are provided herein for enabling access to an enterprise network domain based on establishing a centralized trust. These techniques may be embodied as a method, a system, and instructions in a non-transitory computer-readable storage media to perform the method.

According to at least one example embodiment, at a policy server having connectivity to a network, a trust relationship is established with a first enterprise network domain and a second enterprise network domain. The policy server receives one or more criterion from a server in the first enterprise network domain and establishes a federation relationship between at least a portion of the first enterprise network domain and one or more entities in the second enterprise network domain based on the one or more criterion. Based on the federation relationship, the policy server enables the one or more entities in the second enterprise network domain to access the at least a portion of the first enterprise network domain.

Example Embodiments

Presented herein are systems and methods to enable access to an enterprise network domain based on establishing a centralized trust. More specifically, techniques presented herein enable a cloud-based server to facilitate an exchange of access or information, including identity information, between multiple enterprise network domains. The cloud-based server (i.e., a policy server) establishes trust relationships with a number of enterprise network domains and, based on information received from the enterprise network domains, establishes federation relationships between the trusted enterprise network domains. In other words, the cloud-based server may act as a “central hub” for identity management and federation through which enterprise network domains can connect to partner enterprise network domains. The cloud-based server controls these connections by enforcing the policies of the enterprise network domains that are connected to the server.

By establishing a trust relationship between a “central hub” and enterprise network domains (i.e., authenticating the identity of each enterprise network domain) prior to allowing any two enterprise domains to enter into or form a trusted relationship, the techniques provided herein enable authentication or identification processes to be separated from federation or partnership processes. Consequently, a much more flexible and scalable form of federations can be created. For example, instead of managing (i.e. developing and enforcing) peering or partnership policies for every partner, an enterprise can manage and enforce a single set of policies that can be scaled to any number of partners via the central hub (i.e., policy server), thereby reducing the required number of managed policies from a multiple of the number of partners (i.e., N partners×M policies) to a sum of the number of partners and the number of policies (i.e., N partners+M policies). Moreover, semantic trust separation makes it natural and easy to establish ad-hoc or permanent sub-federations (subsets of entities within the federation) and recursive federations which may further reduce the number of policies that an enterprise needs to manage to control the access provided to partner enterprises. Still further, by moving the policy enforcement to the cloud, administrators can benefit from predefined federations and sub-federations and implementing a network roaming policy can be as simple as clicking a checkbox.

Reference is first made toFIG. 1, which illustrates a cloud computing environment100that includes a first enterprise network domain112, a second enterprise network domain114, and a third enterprise network domain116that are connected to each other and to a policy server118via a network, e.g., the Internet120. Each of the first enterprise network domain112, second enterprise network domain114, and the third enterprise network domain116includes network equipment122(e.g., network switches, routers, etc.) to enable network connectivity within the respective enterprise network domain and to the Internet120. Additionally, each of the first enterprise network domain112, second enterprise network domain114, and the third enterprise network domain116includes at least one server124, such as a RADIUS server, that collectively services computing needs of the enterprise and a group of authorized users126that are authorized to access the servers124and network equipment122within their respective enterprise network domain112,114, or116. As an example, each of the first enterprise network domain112, second enterprise network domain114, and the third enterprise network domain116may include a RADIUS server to manage and authenticate the identities of the authorized users126for its respective enterprise network domain. Put another way, each enterprise network domain, at least for the purposes of the examples presented herein, includes any resources (i.e., applications, equipment, information, etc.) maintained by the enterprise, as well as any users who are authorized to access these resources (i.e., employees).

The policy server118includes various modules that interact with the enterprise network domains112,114, and116, in order to process data provided by the enterprise network domains112,114, and116, and form relationships between the enterprise network domains112,114,116, or at least portions thereof. More specifically, policy server118includes a server processing module132that can interact with any servers124included in the enterprise network domains112,114, and116and an exchange enablement module134that can authorize or enable an exchange of access or information between the first enterprise network domain112, the second enterprise network domain114, and the third enterprise network domain116, or at least portions thereof. The policy server118also includes a policy enforcement module136that can analyze and enforce any policies or criterion received from the first enterprise network domain112, the second enterprise network domain114, and the third enterprise network domain116. Additionally, policy server118includes a memory140and a network interface unit138to enable network connectivity, such as to the Internet120.

Generally, memory140may include read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical or other physical/tangible (e.g., non-transitory) memory storage devices. Thus, in general, the memory140may be or include one or more tangible (non-transitory) computer readable storage media (e.g., a memory device) encoded with software comprising computer executable instructions. For example, memory140may store instructions that may be executed by the server processing module132, the exchange enablement module134, and/or the policy enforcement module138for performing tasks associated with establishing a centralized trust and/or enabling access to an enterprise network domain based on the centralized trust, as described below with reference toFIGS. 2-6.

Now referring toFIG. 2, high-level flowchart200depicts operations performed by the policy server118to enable access to an enterprise network domain based on establishing a centralized trust, according to an example embodiment. Reference is also made toFIG. 1for purposes of the description ofFIG. 2. Initially, at step210, the policy server118establishes a trust relationship with a first enterprise network domain112. In other words, the policy server118establishes a technical trust with the first enterprise network domain112. However, at step210only the validity of the endpoints is established (i.e., “am I talking to the host I think I should be talking to”) and business relationships between multiple enterprise network domains are not recognized or established.

In some embodiments, the policy server118automatically establishes a trust relationship with a first enterprise network domain112by exchanging metadata with a server included in the first enterprise network domain112. For example, the policy server118and one of the servers124in the first enterprise network domain112may exchange metadata including domain names, Internet Protocol (IP) addresses of the various servers124included in the first enterprise network domain112(i.e., RADIUS servers), shared keys, X.509 certificates, protocol endpoint information, and/or other such information. In some embodiments, the policy server118establishes the trust relationship with a RADIUS server included in the servers124of the first enterprise network domain112because the RADIUS server may be able to authenticate the identity of the first enterprise network domain112.

However, in other embodiments, the first enterprise network domain112may establish or authenticate its identity with the policy server118in any manner. For example, in some embodiments, an administrator from the first enterprise network domain112may enroll the first enterprise network domain112with the policy server118. In these instances, once an enterprise decides to take part in a network roaming ecosystem, the enterprise may sign a policy agreement and then the first enterprise network domain112and policy server118can be configured to mutually trust each other. Regardless of how the first enterprise network domain112is authenticated, a successful authentication allows the policy server118to establish a trust relationship with the first enterprise network domain112. Moreover, once a first enterprise network domain112establishes a trust relationship with the policy server118, the first enterprise network domain112may not need to establish another trust relationship. Instead, the first enterprise network domain112may form a single trust relationship with the policy server118and the policy server118may establish any further trust or federation relationships.

Once a trust relationship is established at step210, the first enterprise network domain112is considered a part of an identification federation service provided by the policy server118. However, the first enterprise network domain112cannot send or process any requests through or from the policy server118, respectively, to establish a federation relationship until the policy server118establishes a trust relationship with another participating enterprise. Consequently, at step220, a trust relationship is established with a second enterprise network domain, e.g., enterprise network domain114. A trust relationship can be established with the second enterprise network domain114in the same manner that a trust relationship is established with the first enterprise network domain112at step210. In other words, the policy server118can establish a trust relationship with the second enterprise network domain114by automatically exchanging metadata with a server224in the second enterprise domain114, by enrolling the second enterprise network domain114and configuring the second enterprise network domain114and policy server118accordingly, or any other manner. Since the technical trust establishment performed at steps210and220involves authenticating endpoints, and does not involve business relationships between enterprises, in some embodiments the trust establishment (i.e., enrollment) can easily be subcontracted and automated. For example in a managed services offering with an on-premises portion, the necessary technical trust may be part of the already created trust relation between the on-premises portion and the enterprise's cloud infrastructure.

At step230, the policy server118receives one or more criterion from a server124in the first enterprise network domain112. In other embodiments, the policy server118may receive one or more criterion from any enterprise network domain that the policy server118has established a trust relationship with; however, for simplicity, the first enterprise network domain112is shown and described as providing the one or more criterion since the policy server118is establishing a federation relationship for the first enterprise network domain112. In some embodiments, the one or more criterion may include a list of enterprise network domains that the first enterprise network domain112considers trusted. However, in other embodiments, the one or more criterion may be or include policies, rules, etc. that enable the policy server118, via the policy enforcement module136, to determine whether the first enterprise network112desires to enter into a federation relationship with another enterprise network domain or a portion thereof (i.e., certain entities included in the second enterprise network domain114). As is described below with regards toFIGS. 3-6, in different embodiments, the one or more criterion may have any degree of granularity. Consequently, some criteria may define specific entities or portions of another enterprise network domain (i.e., specific servers of servers124or groups of the authorized users126from the second enterprise network domain114or third enterprise network domain116) as entities that may be given access to the first enterprise network domain112, or portions thereof, while other criteria may define enterprise network domains that may be given access to the first enterprise network domain112, or portions thereof.

In some embodiments, the policy server118may provide a portal (i.e., website) with a graphical user interface to allow an administrator associated with the first network enterprise112to provide the one or more criterion. In these embodiments, the administrator in the first enterprise network domain112may connect to a portal from any device in the first enterprise network domain112(since these devices are authorized at step210). From the portal, the administrator may modify any criterion or policies associated with the first enterprise network domain112, such as join and/or disjoin policies.

At step240, a federation relationship is established between at least a portion of the first enterprise network domain112and one or more entities in the second enterprise network domain114based on the one or more criterion received at step230. In some embodiments, the policy server118may establish a federation relationship between two enterprise network domains selected from a list of enterprise network domains that have already established a trust relationship with the policy server118(i.e., enterprise network domains that have already registered or enrolled in the federation service) based on the one or more criterion received at step230. Additionally or alternatively, the policy server118may send or accept requests to form a federation relationship based on the criteria received at step230. In these instances, the criteria may define requests that should be made to other enterprise network domains and/or which requests should be accepted from other enterprise network domains enrolled with the federation system.

In some embodiments, the policy server118may automatically generate a request to establish a federation relationship. Additionally or alternatively, the policy server118may allow an administrator to search for other enterprises with which the first enterprise network domain112desires to establish a federation relationship. For example, the policy server118may enable an administrator from the first enterprise network domain112to search for a second enterprise network domain114that has already established a trust relationship with the policy server118(i.e., it is part of the federation service) and send a request to establish a federation. Regardless of how the request is generated, a request may contain the following information: a destination domain (i.e., xyz.com), a destination server (i.e., id.xyz.com), whether trust should be enabled (i.e., Yes or No), a source domain (i.e., abc.com), and a source domain server (i.e., id.abc.com). In other words, a request may identify the sender (the source) and the receiver (the destination) of the request. As another example, a first enterprise network domain may submit a request to join a roaming consortium with at least some of the same information.

In some embodiments, the second enterprise network domain114may be required to approve a request from the first enterprise network domain112, either explicitly or by indicating an intention to accept via one or more criterion submitted to the policy server118. For example, in some embodiments, upon approving a request for access, the administrator of the second enterprise network domain114can select a certain server to provide access to and enforce security controls (i.e. an identity (ID) server with virtual local area network (VLAN) security), such that authorized users124from the first enterprise network domain112are only provided with access to the ID server with the applied security controls. More specifically, the administrator of the second enterprise network domain114may input at least the following information when accepting (or denying) a request: destination domain (i.e., abc.com), domain destination server (i.e., id.abc.com), whether trust should be enabled (Yes or No), and policy profile (i.e., VLAN10).

Once a federation relationship is established between at least a portion of the first enterprise network domain112and one or more entities of the second enterprise network domain114, the exchange enablement module134of the policy server118enables an exchange of access or information therebetween at step250. As is discussed in further detail below, in some embodiments, the relationship may enable authorized users126from the second enterprise network domain114to access to the network equipment122from the first enterprise network domain112, such that the authorized users126from the second enterprise network domain114can access the Internet120while on the premises of the first enterprise. However, in other embodiments, the relationship may enable authorized users124from the second enterprise network domain114to access to some or all of the servers124included in the first enterprise network domain112. The amount of access provided to the enterprise network domains, or portions thereof, in a federated relationship may be controlled by the exchange enablement module134of policy server118based on analysis performed by the policy enforcement module138on the one or more criterion received from these enterprise network domains.

Now referring toFIG. 3, an example partner ecosystem300is illustrated. Reference is also made toFIG. 1for purposes of the description ofFIG. 3. In example partner ecosystem300, the policy server118has established trust relationships with six different enterprise network domains: the first enterprise network domain112, the second enterprise network domain114, the third enterprise network domain116, a fourth enterprise network domain302, a fifth enterprise network domain304, and a sixth enterprise network domain306. As mentioned above, the policy server118may receive one or more criterion from each of these enterprise network domains and, based on the one or more criterion, the policy server118, via policy enforcement module136, may establish federation relationships between any of these enterprise network domains.

In the example embodiment depicted inFIG. 3, the policy server118has received criteria from the fifth enterprise network domain304indicating that the first enterprise network domain112, the second enterprise network domain114, the third enterprise network domain116, and the sixth enterprise network domain306are trusted partners of the fifth enterprise network domain304. Additionally, the policy server118has received criteria from the first enterprise network domain112, the second enterprise network domain114, the third enterprise network domain116, and the sixth enterprise network domain306indicating that the fifth enterprise network domain304is a trusted partner. Thus, a federation relationship has been formed between the fifth enterprise network domain304and each of these enterprise network domains. For example, the fifth enterprise network domain304may have a business relationship with the first enterprise network domain112, the second enterprise network domain114, the third enterprise network domain116, and the sixth enterprise network domain306and may have provided an indication of this relationship to the policy server. By comparison, the fifth enterprise network domain304may not have a business relationship with the fourth enterprise network domain302and, thus, a federation relationship has not been formed with the fourth enterprise network domain302.

Due to the established federation relationships, users associated with the first enterprise network domain112, the second enterprise network domain114, third enterprise network domain116, and the sixth enterprise network domain306can access at least a portion of the resources of the fifth enterprise network domain304. Similarly, the federation relationship may allow the users associated with the fifth enterprise network domain304to access at least a portion of the resources (i.e., a cloud-based security service) of the first enterprise network domain112, at least a portion of the resources of the second enterprise network domain114(i.e., resources relating to a partnership project), at least a portion of the resources of the third enterprise network domain116(i.e., an identify management server), and at least a portion of the resources of the sixth enterprise network domain306(i.e., a file sharing server). In other words, the fifth enterprise network domain304may leverage services or resources from its partners after the policy server118establishes a federation relationship therebetween. Similarly, the partner enterprise network domains may access the portions of the fifth enterprise network domain304required to provide their respective service.

Now referring toFIGS. 4 and 5, in some embodiments, a federation relationship may include role-based policy enforcement such that different levels of access are enabled based on the one or more criterion provided by an enterprise network domain. Consequently, in some embodiments, an enterprise network domain (such as the fifth enterprise network domain304) may have different levels of trust with its partners and, thus, a federation relationship established with different partners may enable certain enterprise network domains to access different portions of the first enterprise network domain112, as illustrated inFIG. 4. Additionally or alternatively, the federation relationship may only enable specific entities in an enterprise network domain to access specific portions of the first enterprise network domain112, as is illustrated inFIG. 5. Each of these scenarios is described in more detail below; however, the ecosystems illustrated inFIGS. 4 and 5are merely examples and, in other embodiments, the policy enforcement module136may enable access in any manner. Reference is also made toFIGS. 1 and 3for purposes of the description ofFIGS. 4 and 5.

In the ecosystem400depicted inFIG. 4, the fifth enterprise network domain304has role-based policies for its servers124on an enterprise level and, thus, when the policy server118forms a federation relationship between the fifth enterprise network domain304and a partner enterprise network domain, the entirety of the partner enterprise network is enabled to access the same portion of the fifth enterprise network domain304(even though the fifth enterprise network domain304may not have access to the entirety of its partner's enterprise network domain, since this access may controlled by criteria supplied to the policy server by the partner enterprise network domain). Consequently, if a partner enterprise network domain, such as the third enterprise network domain116, is enabled to access all of the servers124in the fifth enterprise network domain304, any entities (i.e., the sales team, management team, research and development team, servers, etc.) included in that partner enterprise network domain can access all of the servers124included in the fifth enterprise network domain304. By comparison, in the depicted embodiment, entities included in the first enterprise network domain112can only access a second server404, entities included in the second enterprise network domain114can only access a first server402, and entities included in the sixth enterprise network domain306can only access a third server406. Among other advantages, enterprise level granularity may be desirable when working with smaller vendors or vendors with a specific task, since the entirety of these partner enterprises may need access to the same portion of the fifth enterprise network domain's resources in order to complete their task, project, job, etc.

By comparison, in the ecosystem500depicted inFIG. 5, the first enterprise network domain112and second enterprise network domain114have established rules on an entity level. Consequently, a first group of authorized users126C (i.e., administrators) from the second enterprise network domain112may have full access to any infrastructure (i.e., network equipment122and servers124) in the first enterprise network domain112while a second group of authorized users126D (i.e., a sales team) from the second enterprise network domain114may only be enabled to access the Internet (via network equipment122) when roaming in the first enterprise network domain112. The same level of access may also be applied to servers and other such infrastructure. For example, the second enterprise network domain114may include a first server124C and a second server124D while the first enterprise network domain112may include a first server124A and a second server124B. Based on the rules or policies provided to the policy server118by the first enterprise network domain112and the second enterprise network domain114, different servers may be enabled to access each other. In ecosystem500, the first server124A from the first enterprise network112is enabled to access the first server124C and the second server124D from the second enterprise network domain114and each of the servers124C,124D from the second enterprise network domain114can access the first server124A, but not the second server124B, from the first enterprise network domain112. As an example, entity level granularity may be preferred when larger enterprises are working together on multiple projects and a first team of users needs access to a first set of resources while a second team of users needs access to a different, second set of resources.

Now referring toFIG. 6, another example partner ecosystem600includes sub-federations. Reference is also made toFIGS. 1, 3, and 4for purposes of the description ofFIG. 6. Generally, as policy-driven trust relationships are built, an ecosystem of sub-federations can be established based on the level of trust an enterprise has with the other enterprise (perhaps a partner or a supplier) by grouping together enterprises or entities with the same level of trust. In other words, the federation relationships shown inFIGS. 3-5can be aggregated into labeled groups, referred to herein as sub-federations. Then, the policy server118may enable different levels of access within an enterprise network domain for the different sub-federations based on the one or more criterion supplied by that enterprise network domain, perhaps enabling partners in a first sub-federation to have full access to that enterprise network domain, while partners in a second sub-federation only are enabled to access a specific portion of that enterprise network domain, such as the guest network.

As a more concrete example, if the second enterprise network domain114and the third enterprise network domain116are both suppliers to the fifth enterprise network domain304, the enterprise network domains114and116can be grouped into a first sub-federation602and enabled to have the same access within the fifth enterprise network domain304(i.e., access to the first server402). Similarly, if the third enterprise network domain116is also a lab partner and IT provider for the fifth enterprise network domain304, the third enterprise network domain116may be grouped into a second federation604for lab partners with the fourth enterprise network domain302and a third sub-federation606for IT providers with the first enterprise network domain112. The third enterprise network domain116may be provided with access to servers124within the fifth enterprise network domain304based on each of these groupings. In particular, the policy server118may enable the second sub-federation604to have access to the second server404in the fifth enterprise network domain304and may enable the third sub-federation606to have access to the third server406in the fifth enterprise network domain304, such that the third enterprise network domain116is enabled to access each of server402, server404, and server406.

Once sub-federations are established, a policy can be expressed in terms of labels instead of users, organizations, or some other entity. For example, a sub-federation called “suppliers” could be constructed by the first enterprise network domain112and could carry its own set of policy rules. Then, as the first enterprise establishes business relationships with different suppliers, the suppliers can be added to the suppliers sub-federation and the policy server118can automatically apply a set group of policies to the new suppliers based on their inclusion in the sub-federation. In other words, the federations may be recursive, insofar as the federations may update or repeat.

As an example, in some embodiments, the first enterprise network domain112could establish that any enterprise network domains that are classified (by the first enterprise network domain112) as suppliers should have access to a first server, but not to a second server, included in the servers124of the first enterprise network domain112, while enterprise network domains that are classified as lab partners should have access to the second server included in the servers124of the first enterprise network domain112. In these embodiments, the labeled groups are maintained (i.e., created, monitored, updated, etc.) by an administrator from the first enterprise network domain112. However, in other embodiments, the sub-federation grouping could be maintained by the policy server118, perhaps based on metadata or maintained by another entity (like a trade group, a government etc.). For example, the first enterprise network domain112may provide access to its network equipment to any users from enterprises network domains that belong to a certain roaming consortium. In these instances, the administrator of the first enterprise network domain112only needs to set a policy for a particular group, without having to consider or determine membership.

Although not shown, the techniques presented herein may be used for an identity service for traditional IT enterprises as well as for Internet of Things (IoT) environments and more generally IoE environments. In order to extrapolate the techniques presented herein to the full reach of IoE, a public key infrastructure (PKI) may be utilized in order to scale the techniques presented herein to an IoE environment. The PKI infrastructure, while not mandatory, may enable “things” in an IoE or IoT environment to belong to a domain, so that the “things” may have a certificate representing a domain as part of its identity and a trust relationship can be established with the policy server118for the “things.”

There are several advantages to the techniques presented herein. As an example, centralizing the identity establishment/enrollment at a policy server may serve to reduce the number of peering policies that an enterprise management by a magnitude of 100 or more (i.e., if the enterprise has 100 or more partners) since, as mentioned, centralizing the authentication changes the total number of policies from a N*M problem to an N+M problem (where N is the number of partners and M is the number of policies). Moreover, techniques presented may remove the need to maintain (and subsequently delete) specific accounts for guest users in an enterprise system and/or the need add guest users to an enterprise's identity system (which duplicates a portion of the user's home enterprise identity system). Instead, an enterprise can determine policies to apply to a wide variety of roles and the centralized policy server can apply the policies accordingly, thereby removing a large burden from an enterprise administrator. Techniques provided herein may also limit the risk traditionally associated with opening access to an identity server (i.e., a RADIUS-server) for a large number of machines.

In addition, compared to conventional techniques used by roaming consortia, which only determine if a user is “in or out of the club” before enabling access, techniques presented herein allow fine-grained control over business relations between any two peers by allowing trust relationships to be established at any level of granularity. Furthermore, techniques provided herein are simple to use and easily scalable at least because the policy server can generate sub-federations, recursive federations, and federations based on metadata, among other aspects. The techniques presented herein can also be easily extended in an IoT/IoE world to determine the trust between two devices (or entities) and the data exchange can be limited through policy enforcement. More generally, techniques presented herein solve a problem unique to enterprise computing environments by providing technology that can leverage a centralized trust to establish cross-domain relationships and control access to enterprise resources.

To summarize, in one form, a method is provided comprising: at a policy server having connectivity to a network, establishing a trust relationship with a first enterprise network domain and a second enterprise network domain; receiving one or more criterion from a server in the first enterprise network domain; establishing a federation relationship between at least a portion of the first enterprise network domain and one or more entities in the second enterprise network domain based on the one or more criterion; and enabling the one or more entities in the second enterprise network domain to access the at least a portion of the first enterprise network domain based on the federation relationship.

In another form, a system is provided comprising: a first enterprise network domain having connectivity to a network; a second enterprise network domain having connectivity to the network; a policy server having connectivity to the first enterprise network and the second enterprise network via the network, the policy server being configured to: establish a trust relationship with the first enterprise network domain and the second enterprise network domain; receive one or more criterion from a server in the first enterprise network domain; establish a federation relationship between at least a portion of the first enterprise network domain and one or more entities in the second enterprise network domain based on the one or more criterion; and enable the one or more entities in the second enterprise network domain to access the at least a portion of the first enterprise network domain based on the federation relationship.

In yet another form, a non-transitory computer-readable storage media encoded with software is provided comprising computer executable instructions and when the software is executed operable to: establish a trust relationship with a first enterprise network domain and a second enterprise network domain; receive one or more criterion from a server in the first enterprise network domain; establish a federation relationship between at least a portion of the first enterprise network domain and one or more entities in the second enterprise network domain based on the one or more criterion; and enable the one or more entities in the second enterprise network domain to access the at least a portion of the first enterprise network domain based on the federation relationship.