Computer networks transmit data between the individual components in the network along multiple communication channels. One type of a distributed object system which participates in computer networks is a distributed object system that is defined under the Common Object Request Broker Architecture (CORBA) specification produced by OMG. Distributed object systems may be in the context of an Object Request Broker (ORB) implemented under the CORBA specification from the OMG, Revision 2.0, Revision 2.1, Revision 2.2 and Revision 2.3, all of which are incorporated herein by reference in their entirety. For purposes of this application, programs and communications compliant with CORBA Revision 2.3, 2.2, and 2.1, by definition will be viewed as compliant with CORBA Revision 2.0 and will be referred to simply as CORBA-compliant. Unless otherwise specified, a generic reference to the CORBA Services specification will be presumed to be OMG's CORBA Services Revision 2.0.
The CORBA Resource Access Decision (RAD) Facility is intended to be used by security-aware applications. The facility is a mechanism for obtaining authorization decisions and administering access decision policies. It enables a common way for an application to request and receive an authorization. The CORBA RAD facility is described in the OMG document Resource Access Decision Facility Specification, Version 1.0, which is incorporated herein by reference in its entirety. References herein to requests to or actions taken by CORBA RAD should be understood as referring to a facility complying with the CORBA RAD specifications. Further, while the present disclosure focuses on its preferred embodiment enhancing CORBA RAD, one of skill in the art will recognize that many of the same benefits may be obtained with other types and versions of resource access decision facilities which provide authorization for access to protected resources.
Applications that access sensitive resources can use CORBA RAD to validate a user's authority to retrieve those resources. The service provides administrative tools to establish security policy that defines authorized access to resources. Prior to making calls to the authorization service the user whose authority is being validated must be authenticated. Once authenticated, the user's credentials can be established based on the user's security attributes. User security attributes (userid, organization, roles, groups, domain, and the like) can be stored in a user profile facility and administered via a profile manager interface. Applications can make explicit calls to CORBA RAD, typically using resource, operation, and user credentials as arguments, to determine if a user is authorized to access secured resources. CORBA RAD then returns a Boolean access decision.
Standard CORBA RAD security policy consists of user policy and access policy definitions. User policy comprises a user's security attributes including userid, organization, assigned groups, and roles. These attributes define a user's credentials or granted rights in the system. Access policy comprises resources, resource domains, operations, operation criteria, and access rules that define the required rights and criteria constraints to perform operations on resources. Access decisions are evaluated by comparing the granted rights of a user attempting to access a resource with the rights required to access the resource as defined by the security policy.
The policy contains mechanisms to group users and resources to enable scalable administration. Users can be placed in defined organizational entities or groups of associated users. Resources can be grouped into domains so that policy can be defined at the domain level for a set of resources sharing common policy.
Three types of policy rules are defined in the CORBA RAD access policy: permissive, constraint, and override. Permissive rules define access requirements sufficient to permit access unless additional access requirements are defined by constraint or override rules. Permissive rules are the default rule type. If multiple permissive rules are specified they are evaluated via a logical “or” operator. That is, if any of the permissive policies evaluate “true” then the user is permitted access unless further constrained by constraint or override rules.
If constraint rules are specified, this indicates that there is an access requirement that must be met in addition to those specified by the permissive rules. If multiple constraint rules are specified they are evaluated via a logical “or” operator to determine if the constraint condition is met. That is, if any of the constraint rules evaluate “true” then the additional access requirement is satisfied. A logical “and” operator is used to combine the evaluated constraint and permissive rules. That is, one of the constraint rules must be met and one of the permissive rules must allow access. If no permissive rules exist, the access decision evaluates “false”.
If override rules are specified for resources, these invalidate any permissive or constraint rules that would otherwise permit access. This provides a mechanism to define exceptions to general policy definitions. If multiple override rules are specified they are evaluated via a logical “and” operator. That is, all of the override rules must evaluate “true” for access to be permitted. Any permissive or restraint rules that would otherwise apply are ignored.
In the design of a CORBA RAD-compliant application, authorization logic is encapsulated within an authorization facility that is external to the application. In order to perform an application-level access control, an application requests an authorization decision from such a facility and enforces that decision. The following sequence occurs in the interaction between a client using CORBA RAD and the external authorization facility. First, the application client invokes an operation of the interface provided by a target object. The CORBA object request broker transfers this request to the target object and causes invocation of the appropriate method in the target object. While processing the request, the target object requests an authorization decision from the Access Decision object (ADO) by invoking the access_allowed( ) method of the ADO.
Then, the Access Decision object consults other objects that are internal to the RAD to make an access decision. The access decision is returned to the target object (ADO client) as a Boolean response. The target object, after receiving an authorization decision, is responsible for enforcing the decision. If access was granted by the ADO, the target object performs the requested operation and returns the results. If access to secured resources was denied, the target object may return partial results or raise an exception to the client.
Standard CORBA RAD as specified by OMG contains no single command that retrieves a list of all resources available to a particular user. Similarly, there is no command to retrieve a list of all users who have access to a particular resource. In addition, calling CORBA RAD for every resource request can be time-consuming, especially when multiple, repetitive requests for the same resource are made. It would be desirable to have a cache or similar memory retention mechanism in which authorization decisions received from CORBA RAD can be retained so that subsequent requests for the same authorization decision can be made directly to the cache rather than through CORBA RAD.
USPTO Backgrounds
USPTO Backgrounds