Increasingly enterprises are faced with numerous internal users having different access requirements that span a large number of applications, networks, and systems. Maintaining the security of such modern dynamic enterprises is a critical and challenging task. In some industries, such as banking, the federal government has promulgated rules and regulations that require a certain degree of security. Thus, enterprises are not only concerned with their reputation but face potential civil liability for security breaches. The challenge lies in efficiently and securely provisioning system access to reflect constantly changing user responsibilities and computing environments.
Historic methods of manually granting individual user access on a resource by resource basis long ago proved administratively infeasible for organizations of even moderate size. Role Based Access Control (RBAC) systems advanced the art by attempting to secure and streamline user administration via constructing and maintaining a formal model of user privileges grouped into roles.
However, such models have scaled poorly because many users are unique; thus, resulting in role proliferation. For example, user diversity is often represented using new applications, departments, or systems, which are added to the enterprise security model. Where fine-grain role approaches are required, the number of roles may equal the number of users (or even exceed the number of user if users have many roles); therefore, the advantage of grouping is often lost. Application of policy rules as a complement to roles has allowed for greater flexibility and fewer generalized static role definitions. Nonetheless, the combination of increasingly complex Information Technology (IT) infrastructures, more diversified users requiring fine granularity access privileges, and growing numbers of users (including employees, subcontractors, partners, vendors, etc.) have shown that these conventional tools and processes to manage security are breaking down.
Consequently, what was considered a valuable security model for an enterprise has now become an administration and maintenance challenge.
Also problematic is the task of converting an enterprise to a role management system in the first place. Traditional role management systems are not conducive to the integration of existing systems to use roles nor do they provide the mechanisms necessary to allow multiple, disparate systems that are related only by the role definitions to add role functionality without affecting other applications using the role management system.
Accordingly, what is needed are mechanisms to better provision fine-grained role extensions without impacting existing role management systems.
In various embodiments, techniques for role management systems are provided. More specifically, and in an embodiment, a method is provided for extending a generalized role definition. A role request and role assignment are received. The role request identifies a principal and a Policy Enforcement Point (PEP) service that acts on behalf of the principal. The role assignment represents permissible roles of the principal. Next, a resource association is evaluated in response to the role request and in response to the role assignment in order to identify a resource profile. One or more resource decorations are applied in response to the identified resource profile. The modified role assignment is sent to the PEP service for enforcement.
The term “resource” as used herein refers to an electronic entity, an application or set of applications, a data store, a proxy, a directory, a service, or physical devices such as computers or peripherals etc. Resources may represent physical or logical entities.
A “principal” is a type of resource designation identifying a resource that requests access to or communicates with other resources. For example, a principal may be a user, an automated application, or an automated service that attempts to access another resource, such as a website, etc.
In various embodiments of the invention, the term “identity” is used. An identity refers to an electronic identifier, attribute, or representation for a resource (e.g., physical and logical). An identity may be assigned to a resource after authentication. An identity is authenticated via various techniques (e.g., challenge and response interaction, cookies, assertions, etc.) that use various identifying information (e.g., identifiers with passwords, biometric data, digital certificates, digital signatures, etc.). A “true identity” is one that is unique to a resource across any context that the resource may engage in over a network (e.g., Internet, Intranet, etc.). However, each resource may have and manage a variety of identities, where each of these identities may only be unique within a given context (given service interaction, given processing environment, given virtual processing environment, etc.).
“Role Based Access Control” (RBAC) is a technique that specifies role relations, interactions, and restrictions as a part of a role object model. Stated another way, RBAC is a security model to administer system access rights based on role assignments and rules (role policy).
As used herein, a “Role Config” is a data store or data structure having a collection of role definitions and which may also include specification information, separation of duties, rights, and privileges, inheritance specification, hierarchical location etc. Sometimes, role definitions include privileges associated with their hierarchical subordinates.
A “Policy Enforcement Point” (PEP) service is a module that dynamically enforces policy, including access restrictions and permissions, for resources within its purview. Policy decisions may be provided from a Policy Distribution Point (PDP) or decided by the PEP itself. Additionally, PEP modules submit access requests on behalf of principals or resources to a Role Calculation Engine (RCE).
A “PEP Config” is a data store or data structure that provides a PDP with PEP specific processing context information. This may include proxy, connection state, IP subnet, domain information, etc.
A PDP service supplies role policy and specifications associated with a resource to a RCE or PEP service. A PDP may also deliver this same information to an augmentation service.
“Role Policy” defines the relationship between a resource and one or more roles. Role Policy may augment the use of a generic role by specifying activation, deactivation, and/or usage restraints. For example, role policy may dictate that a particular role may only be assigned to a principal if specific conditions are met (e.g., time of day (temporal restraint), subnet (network constraints), memory or processor capacity (hardware configuration), etc.).
A “Resource Decoration” defines a processing context to an augmentation service. The processing context may include additional access restrictions or permissions, formatting and syntax requirements (i.e. to accommodate legacy applications).
A “Resource Association” defines and identifies relationships between resources, including role requests and role assignments, and maps particular relationships to resource profiles. The profiles map to context specific access permissions or restrictions.
A “Resource Config” includes one or more resource profiles or specifications. Each resource profile identifies one or more resource decorations that may be applied to a given role assignment or resource association. In other words, the resource config details the restrictions that may be imposed on a particular resource or processing context for that resource.
An “Augmentation service” is used as an augmentation calculator that accepts as inputs one or more roles, policies associated with those roles, role requests, or role assignments supplied by a PDP service or RCE and uses the identified resource associations in connection with the resource config to select a resource profile and acquire the appropriate resource decorations. Another way to view the operation of the augmentation service is that, as will be described in greater detail below, it essentially permits more granular (fine-grain) roles to be realized by further adding access restrictions or permissions being calculated for a given role assignment. The output of the augmentation service is in the same or similar format as the inputs supplied by the PDP service or RCE, such that multiple instances of the augmentation service can be chained together based on configuration setups to further granularize the access permissions and restrictions. The augmentation calculation module may be a generalized, reusable module or logic specific to a given application.
Finally, the “Role Calculator” associates one or more roles to a requesting resource and evaluates access requests for the resource by application of role policy to that resource's role assignments. The Role Calculator is part of the Role Calculation Engine (RCE).
As used below, the terms role, decoration, association, and interaction may refer to specific instances, patterns, or templates.
Various embodiments of this invention can be implemented in existing network architectures and RBAC systems. For example, in some embodiments the techniques presented herein are implemented in whole or in part in the Novelle® network, proxy server products, operating system products, data center products, and/or directory services products distributed by Novelle®, Inc. of Provo, Utah. More specifically, embodiments of the invention may be implemented in the Novelle® Access Manager, Identity Manager, and Bandit products among others.
Of course, the embodiments of the invention can be implemented in a variety of architectural platforms, operating and server systems, devices, systems, or applications. Any particular architectural layout or implementation presented herein is provided for purposes of illustration and comprehension only and is not intended to limit aspects of the invention.
It is within this context, that various embodiments of the invention are now presented with reference to the
As will be more fully described herein and below, the role extension service permits a generic role assignment to be modified with access permissions or restrictions specific to a given PEP, application, and/or principal via an augmentation service. The phrase “decorating a role assignment” is synonymous with modifying the access permissions of a given role assignment.
At 110, the role extension service receives a role request and role assignment. The role request identifies a requesting PEP service and the principal that the PEP service is representing. The role assignment represents one or more permissible roles of the principal. A role request represents a principal's desire to access one or more resources. In some situations, it may be necessary that a principal be assigned more than one role to receive access to a particular resource. According to an embodiment, the role request and role assignment are sent from a RCE that previously made the role assignment in response to the role request. More than one role assignment may be associated with a given role request. The role extension service may receive the role request and role assignment by “intercepting” a transmission originally intended for a PEP service. Where an application makes a role request on behalf of a principal the role request may include information identifying the application and principal. Optionally, at 111, the role extension service identifies the requesting principal and/or an application being used by the principal.
At 120, the role extension service evaluates a resource association in response to the role request and role assignment to identify a resource profile within the resource config module. To evaluate a resource association the augmentation processing may consider the identified relationship between one or more of the following: the true identity of the principal, the role request, the role assignment, the PEP service, the application, membership inheritance requirements, dynamic membership exclusions based on temporal restraints, etc. After selecting the resource profile at 120, the role extension service applies the resource decorations identified in the selected resource profile to the role assignment at 130. In this manner, generalized role definitions may be modified and extended through decorating a role assignment without burdening the generic role specification. One result is that fine-grain security requirements for specific applications, PEPs, and principals may now be resolved without affecting other uses of a security management system. Further, specific roles and role hierarchies may be decorated or associations specified that are meaningful to the application but not generally applicable to a general role specification case.
By way of example, resource decorations may implement the limitation that membership inheritance from the role hierarchy for a given application be restricted to only one level whereas another application must inherit from each available level. Such a situation may arise where manager A, a second level manager, supervises first level managers B and C. Manager B oversees only regular salaried employees and manager C oversees outside contract workers. Manager A, in her role as second level manager, should be able to access all the information about manager B, manager C, and the subordinates of manager C (all regular salaried employees) but not the confidential information relating to the outside contract workers that manger B supervises.
Returning to the discussion of the
At 140, the role extension service sends the modified role assignments to the PEP service for enforcement against subsequent processing actions of the requesting principal.
In this way, a coarse-grain role definition may be extended to create one or more fine-grain role extensions and without affecting how other applications, services, systems, and resources use the coarse-grain role.
At 210, the proxy service receives a role request from a first resource on behalf of a second resource. It may also be the case, at 211, that the proxy service recognizes the first resource as a PEP service and the second resource as a principal. The role request may be sent from a PEP service directly or arrive at the proxy service indirectly.
At 220, the proxy service acquires a response that associates one or more roles with the second resource. The response may be acquired from a role calculator. The roles, which are associated with the second resource, may include each available role or may include just a subset of roles of the second resource's permissible roles, depending on the access rights sought by the second resource. Environmental conditions such as hardware limitations, network constraints, software configurations, time of day, location, etc. may also determine which roles are associated with the second resource. For example, some roles may not be accessible to the second resource if the second resource is requesting access in a remote physical environment, such as through a virtual connection. Alternatively, at 221 the proxy service may generate the response itself by dynamically associating one or more roles with the second resource.
The proxy service forwards the role request and the response to an augmentation service at 230. Optionally, at 231, the augmentation service selects resource decorations according to a resource profile, in a manner similar to the detailed description provided at 120 above with respect to method 100 of the
At 240, the proxy service receives a modified response from the augmentation service. The modified response is customized for the second resource by application of resource decorations to the original response. This may include changing access permissions and/or restrictions of the active roles associated with the second resource. Additionally, the customization may include altering the format and syntax of the response.
At 250, the proxy service sends the modified response to the first resource. The first resource enforces the access permissions and restrictions contained in the response against the second resource.
In one embodiment, at 251, the method 200 may be implemented as a plug-in to a RCE. In another embodiment, at 252, the method 200 may be implemented as modifications within an RCE. According to yet another embodiment, at 253 the method 200 may by implemented as a proxy service that interacts with a RCE and PEP service.
At 310, the PEP service receives a role request from an application on behalf of a principal. The same PEP service may administer service dispositions for more than one application or principal.
At 320, the PEP service forwards the role request to a RCE. An RCE generates a response by assigning one or more roles associated with the principal or with the application and forwards the response to an augmentation service for customization. Alternatively, the RCE may forward the response to another PEP service and the response may be “intercepted” by an augmentation service.
Two or more augmentation services may be “chained” together via their augmentation calculators. Optionally, at 321, the RCE response may be forwarded from one augmentation service to another augmentation service as necessary for customization. Some augmentation services may be logic specific for particular applications.
According to an embodiment, consumer and maintenance Application Programming Interfaces (API) are associated with the PEPservice. Further flexibility is created by allowing applications to change PEP services and PEP chaining associated with API and management functions. For example, this allows an application to specify that, after a particular application decoration has been associated with a role, the role may not be further modified without the PEP service that represents the application ensuring that the modification is acceptable.
Continuing with the discussion of the
At 330, the PEP service receives a modified response from the augmentation service. The augmentation service has already customized the RCE response, as described in detail above, for the application and the principal by applying resource decorations. At 340, the PEP service enforces the access rights and/or restrictions contained in the modified response against the application and principal. In this manner, fine-grain access restrictions may be realized. Such grainular security may even be used to ensure governmental regulations are being satisfied with respect to security.
The role extension system 400 includes a PEP service 420 and an augmentation service 440; each of which are discussed in more detail below. In some cases, the role extension system 400 may also include one or more resources 410, a RCE 430, and additional augmentation services 450.
The PEP service 420 was described in detail above, especially with reference to the method 200 of the
The augmentation service 440 was described in detail above, especially with reference to role extension service represented by the method 100 of the
The augmentation service 440 is adapted to customize an RCE response for the PEP service 420, for resources 410, or for other applications or principals. The augmentation calculator modifies the role response according to the resource decorations, resource associations, and resource profiles that form part of the augmentation service. The augmentation service 440 customizes the response for the requesting resource, adjusting access permissions and restrictions as necessary and may also apply a processing context to the response to fulfill formatting or syntax requirements of the requesting resource (e.g. to accommodate a legacy application, etc.).
The augmentation service 440 is further adapted to send the customized response to the PEP service 420. Thus, because the customized response need not pass back through the RCE, it is possible to configure the augmentation service, including the resource decorations, resource associations, and resource profiles, to allow multiple, disparate systems/services that are related by the role specifications to add role functionality without affecting other systems/services using a role management system/service.
One or more augmentation services 450 may be connected to the augmentation service 440. Augmentation services 450 operate in a manner similar to that described above with respect to augmentation service 440. The augmentation services 440, 450 may send responses to and receive responses from one another or from other augmentation services (not shown in
The character A represents the transmission of a role request from PEP X on behalf of application 2 to the RCE where one or more roles are assigned. The RCE transmits the role request and role assignments via channel B to an augmentation module for modification. The modified response is sent over C to the requesting PEP, in this case PEP X. Optionally, the augmentation calculator may pass the response via D to another augmentation module before the response is returned to PEP X. The response may be further transmitted via E to additional augmentation modules.
The techniques presented herein provide mechanisms necessary to allow multiple, disparate systems that are related only by the role specifications to add role functionality without affecting other applications, services, or systems using a role management system/service. The methods and systems described above provide PEP and application specific role extensions to coarse-grain role definitions that leave the general role definition intact. Among other benefits, enterprises may now more easily convert to a role management system/service in and better administer role management systems/services as user diversity is exposed by new applications, departments, or users being added to the enterprise. Thus, provisioning fine-grained access permissions, which reflect constantly changing user responsibilities within a more manageable processing environment.
The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
The Abstract is provided to comply with 37 C.F.R. §1.72(b) and will allow the reader to quickly ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.
In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.
The present Application is co-pending with, is a Continuation of, and claims Priority to U.S. patent application Ser. No. 11/621,762, entitled: “Role Policy Management,” filed on Jan. 10, 2007, and which presently stands allowed; and the disclosure of which is incorporated by reference herein in its entirety. The invention relates generally to security and more particularly to administering resource access using role policy management techniques.
Number | Date | Country | |
---|---|---|---|
Parent | 11621762 | Jan 2007 | US |
Child | 13222258 | US |