|
|
This section covers the following topics:
AquaLogic Enterprise Security is a fine-grained entitlements engine that allows the user to centrally define and manage a set of policies to control access for both application software components (for example URLs, EJBs, and EJB methods) as well as the application business objects (for example accounts and patient records) that make up the application. A set of access control policies is evaluated and enforced locally in the application container so application context can be included as part of the access control decision. A major benefit of using AquaLogic Enterprise Security to implement access control is that it allows you to remove security logic from the application. This enables you to take access control decisions out of the hands of your developers and define and manage access control consistently across multiple applications.
Policies are statements that work together to define access control for your business resources. A resource is any object that represents an underlying application or application component that needs to be protected from unauthorized access. A well-written set of policies accurately represents the access control requirements for your business, is easy to manage, and is designed for maximum efficiency.
You write separate policies to grant or deny access privileges to your business resources to users, groups, and roles under some set of conditions, or constraints. Therefore, before you begin to write policies, you must know the access control requirements of your business, the resources that are to be protected, who the users are and their responsibilities, and what privileges the users are to have on the resources.
There are three types of policies, authorization policies, role mapping policies, and delegation policies, each type having a different function:
The policy evaluation strategy imposes a closed-world security environment. This means that before you specifically create an authorization policy granting access privileges to specific resources, users, groups, and roles have no privileges. You must grant privileges with an authorization policy before users can do anything. This means that all privileges to all resources protected by a Security Service Module are implicitly denied until authorization policies grant specific privileges.
Thus, the closed-world security environment has the powerful advantage of having your application security err on the side of caution. That is, if you forget to deploy an authorization policy, someone may be denied access rather than be granted access to something to which they should not have access. A user that is denied privileges will usually let you know that there is a problem (and, if they do not, that is probably okay). On the other hand, a user that has been granted privileges they should not have may not tell you, which may have disastrous consequences. Once you grant an access privilege, you must explicitly deny it to revoke that right. Explicit DENY policies cannot be overruled.
All policies follow a specified sentence-like syntax. The structure of a policy is similar to a sentence and the policy elements can be thought of as parts of the sentence.
The general syntax for an AquaLogic Enterprise Security policy is as follows:
Effect (privilege|role, resource, subject, delegator) IF constraint;
A single policy can have multiple privileges, resources, and subjects defined.
The functions of each policy component are as follows:
Policies must adhere to the following rules:
IF indicates a constraint.
A resource is simply an object used to represent an underlying application or application component (or any resource), that can be protected from unauthorized access using authorization policies. Resources are often hierarchical in nature. Resources can be specific application software components managed by the container (for example, URLs, EJBs, JSPs, and so on) or any business object in the application. Resources may have attributes; for example bank accounts have owners and transfer limits. Resources are hierarchical and child resources inherit policies and attributes from their parent in the hierarchy.
When defining resources you start by defining the top-level resource in the resource tree and then define the resources that make up the tree. Once a resource is defined, you can write authorization policies to grant or deny access privileges to users, groups, or roles for the top-level resource and resources on the tree. Hence, defining a resource tree is a necessary prequisite to writing policies. For example, if you define a resource named TellerApp (see Figure 2-1), you can then write an authorization policy that grants or denies access privileges to the TellerApp resource.
Some typical resources that you might want to secure, include:
| Note: | In development mode, you may use the Resource Discovery tool to help define resources for a particular application. For more information, see Resource Discovery. |
For more information about resources, see the following topics:
In addition to the resources that you define in the resource tree, you have the option of defining virtual resources, which do not appear in the resource tree. This feature offers some flexibility as to the levels of resource hierarchy that must be included in the resource tree so that protections can be assigned. Once you configure a resource to allow virtual resources, any resources below it, that is, its child resources, are, in effect, virtual resources and are protected by the same policies as their parent, even though they do not appear in the resource tree. If you configure a resource to allow virtual resources, you enable policies to be evaluated on resources below the resource which are not explicitly defined inside in the resource tree. For example, if a directory is configured in the resource tree to allow virtual resources, the Authorization and Role Mapping Engine (ARME) can process access requests on files in of the directory even if the files are not explicitly listed in the resource tree.
You can associate attributes with resources. An attribute contains information about a characteristic of the resource to which it is associated. Thus, you can use attributes to define additional information about a resource. For example, filetype could be a resource attribute that you use to define an html, image, jsp, or pdf file type. Then, you could grant access to all pdf files in a directory by adding the condition: if filetype = pdf.
A privilege group is constructed by grouping two or more privileges. A privilege can belong to more than one privilege group. In addition to the privilege groups that are provided in the product, you can define your own with distinct characteristics. Privilege groups are not used in policies. They are simply a way to organize privileges and have no meaning when writing a policy and are only provided to simplify the task of choosing the right privilege.
It is common to define a privilege group that applies to a particular application or set of transactions. You can control access to privilege groups (those provided in the product and those that are user-defined) through delegated administration.
A privilege represents an action or task in your business policy that can be executed on a resource. Privileges in a policy specify the actions that are granted or denied on a resource. Privileges can be standard actions associated with specific software components (for example Get and Post for a URL) or a custom action for a business object in an application (for example, transfer for a bank account). The privileges that may be granted or denied on a particular resource are limited by the operations supported by the resource. For example, a simple text file may support Read, Write, Copy, Edit, and Delete operations. Similarly an executable (.exe) may support operations such as Copy, Delete, and Execute. A more complex resource may support far more complex privileges. For example, a checking account application may support operations such as deposit, withdrawal, view account balance, view account history, transfer to savings, and transfer from savings.
In addition to the privileges that are provided in the product, you can define your own privileges. You can also organize privileges into logical groups for ease of management.
You use privileges to write authorization polices as follows:
grant(privilege, resource, subject[users, groups, roles]) IF constraint;
For example, if you have the business security requirement: "Only lead tellers can open an account," you might define an OpenAccount privilege and a LeadTellers role. Now, to grant LeadTellers (the role) the authority to open an account (the privilege), the authorization policy might look like this:
grant(//priv/OpenAccount, //app/policy/TellerApp, //role/LeadTellers)
if time24 in [900..1700] AND
dayofweek in [Monday..Friday];
When this policy is deployed, only tellers who are assigned the LeadTellers role are allowed to used the TellerApp to open an account and they may do so only between the hours of 9:00 AM and 5:00 PM (a time-of-day constraint) on Monday through Friday (a days-of-the-week constraint).
Identity definition includes the definition of directories, users, groups, and roles. An identity directory serves as a logical container for a collection of identity attributes, users, groups, and roles. An identity directory typically represents a set of users, groups, and roles. Therefore, the first step in defining identities is to define the directory. Once you have defined the identity information, you can use it to write authorization policies and role mapping policies. In authorization and role mapping policies, the user identity (users, groups, roles) is defined in the subject element of the policy.
You may define multiple identity directories. The number of directories you define depends on the level of granularity needed to separate your user community. You may want to have one global directory containing all users. In this case, you can populate a single directory using multiple external repositories. Having one directory for all users requires that you have a unique name for each user and group across all of your identity repositories. If you cannot guarantee this when you integrate your identity repositories, then you should probably maintain separate directories. For example, you might have one directory for customers, one for employees, and one for partners.
The following topics describe user identity components:
A user or group can contain attributes that further describe their characteristics—who they are and what they can do; these are referred to as identity attributes. You can use these identity attributes to define dynamic constraints for a role to which a user or group belongs. For example, consider that account balance is an attribute of a user. To allow customers with an account balance over $100,000 to access the premier banking features of your application, you define accountbalance as an attribute and apply it to each customer in the bankusers group (sgrp). Next, you define the premierbanking role and write a role mapping policy that only allows access to the application if the customer is in the premierbanking role. Then you write an authorization policy that defines the privileges you want to allow on the bankapp resource and define the subject as the role premierbanking.
Grant(//role/premierbanking,//app/policy/bankapp, //sgrp/bankusers/customers/) if accountbalance > 100000
This role mapping policy allows customers who are assigned the premierbanking role to access the resource called bankapp if they have an accountbalance of over $100,000.
A group is typically a collection of users that have something in common, such as a department, a job function, or a job title. For example, a group named Accounting might contain users in the accounting department. It is important to realize that this does not directly reflect what access rights they have. A group can contain either users or other groups; users who are assigned to a group are called group members. Nested memberships of groups within a group form a hierarchy. Group membership can be assigned only from within the same directory. Groups have a static identity, or name, which you assign.
If a group has subgroups and an authorization policy grants certain privileges to the group, the members of subgroups will have the same privileges. This is true because each member of a subgroup is by default a member of the parent group.
In addition to managing groups in the policy database, AquaLogic Enterprise Security can use group membership information from a corporate directory. Typically, a group hierarchy is based on an organizational model of the company, although this is not a requirement. For example, the source of your user data might be an employee database, where users belong to four groups: the employee group, the Sales department group, the London office group, and the star-salesmen group.
Thus, you want to create groups of users, whose tasks are related and for whom the policy enforcement is the same. In the following example (see Figure 2-2), Tellers are assigned to the Teller Group.
A user corresponds to an individual who makes a request to access a resource, although a user can also be an automated process that accesses a resource. You can assign users to groups from the same directory. Each user within a directory must have a unique identity or user name. Users can be associated with certain characteristics or attributes that contain information about the user. Keep in mind that it may be more efficient to write policies that apply to a collection of users defined as a role or a group. AquaLogic Enterprise Security supports both.
A role is a set of privileges that can be assigned to a user or group. The actual access privileges assigned to a role are defined by the authorization policy that you write for the role. You write a role mapping policy to assign the role to users and/or groups, thereby granting the access privileges defined by the authorization policy. Once you have written a role mapping policy to assign the role to a user or a group, you can also write a delegation policy to delegate the role from one user to another user or group. Like groups, roles allow you to restrict access to resources for many users or groups at once. However, unlike groups, roles are computed dynamically at runtime based on role mapping policies. Additionally, roles can be associated with specific resources in an application.
To specify the access control requirements for your resources you write a set of policies that may include role mapping policies, authorization policies, and delegation policies.
The following topics describe the different types of policies:
Role mapping policies define when and which to grant roles to users or groups for a particular resource.
The basic format of a role mapping policy is as follows:
grant|deny(role, resource, subjects[users, groups]) IF constraints;
Where the grant|deny portion is the policy effect and either allows or prohibits the role to the subject for the given resource, the role defines the role, the resource is the application or application component to which the role is scoped, subjects specify which users and groups belong to the role, and constraints define any conditions that apply to the role.
GRANT(//role/accountants, //app/policy/acme/payroll, //user/acme/Bill/);
grants the accountants role to the user Bill on the payroll resource.
At runtime, user access privileges are computed based on the roles the user has been assigned—either explicitly or through a role mapping policy—at the time an access request is made. Unlike groups, which are relatively static and persist for duration of the runtime session, roles are highly dynamic and are assigned to users by processing role mapping policies. Role mapping significantly reduces the number of policies required and makes features like role delegation easier to manage.
A role may apply to one or more users and groups and usually refers to some set of related tasks. For example, a group of bank tellers might have access to the same set of applications (resources) to perform specific banking tasks; thus, you might have a role called TellerRole and assign the BankTellers group to that role. Figure 2-3 shows a group of tellers who belong to a Teller group that has membership in the CustomerService role that, in turn, has access to the Teller resource. The privileges, or actions, allowed on that resource are defined by an authorization policy, which you also define. Now, anyone who is not in the CustomerService Role does not have access to the Teller resource. You can also apply restrictions and conditions to limit access to the resource at runtime by defining the constraints such as time-of-day or day-of-the-week on the role mapping policy and/or the authorization policy.
An authorization policy specifies what a user is allowed to do with a resource. The syntax of an authorization policy is as follows:
grant|deny(privilege, resource, subjects[users, groups, roles]) IF constraints;
Where the grant|deny portion is the policy effect and either allows or prohibits the privilege to the subject for the given resource, the privilege defines the privilege, resource defines the application or application component of the privilege, subjects specify which users, groups, and roles are granted the privilege, and constraints defines any conditions that apply to the privilege.
GRANT(//priv/any, //app/policy/acme/payroll, //user/acme/agarcia/);
grants any privileges supported by the acme payroll application (the resource) to the user agarcia in the acme directory. The policy:
GRANT(//priv/any, //app/policy/acme/payroll, //role/accountants/);
grants any privileges supported by the acme payroll application (the resource) to the role accountants so only users and groups who have been granted the accountants role are granted this privilege. Therefore, before anyone can gain this privilege, a role mapping policy has to be written and deployed that grants this role to a user or a group.
It is important to note that by default, all access to a resource is denied until an authorization policy is written and deployed that explicitly grants an access privilege, or an entitlement, on that resource to a user, group, or role. If the authorization policy only grants an entitlement on a resource to a role, then a role mapping policy must be written and deployed that assigns a user or a group the defined role.
If an authorization policy denies a previously granted entitlement, the deny takes precedence over the grant. Explicit DENY authorization policies cannot be overruled. A practical use of a DENY policy is to explicitly deny an entitlement to ensure that a user or group can never gain access to a specific resource. For example, the DENY authorization policy:
DENY (//priv/view, //app/policy/acme/payroll, //sgrp/acme/receptionist/);
denies the view privilege related to the acme payroll application to everyone belonging to the group named receptionist in the acme directory.
The syntax of a delegation policy is as follows
DELEGATE (privilege|role, resource, subject, delegator) IF constraint;
A DELEGATE policy that delegates a privilege allows you to share the privileges of one user with another user, group, or role. You may also add a constraint that restricts this sharing to a certain time of day or day of the week, for example:
DELEGATE (//priv/any, //app/policy/acme, //user/acme/joe/, //user/acme/larry/) if dayofweek in [Monday..Friday];
At runtime, this policy delegates any privileges that larry (the delagator) has on the acme application to joe if the day of the week is Monday, Tuesday, Wednesday, Thursday, or Friday.
A DELEGATE policy that delegates a role allows you to share a role of one user with another user or group. You may also add a constraint that restricts this sharing to a certain time of day or date range, for example:
DELEGATE (//role/accountants, //app/policy/acme, //user/acme/joe/, //user/acme/bill/) IF ThisMonth = December;
delegates the role accountants on the acme application from bill (the delagator) to joe at runtime if the current mouth is December.
| Note: | Before a delegator's privilege or role can be delegated, the ARME must verify that the delegator has the privilege or role to be delegated on the specified resource. To perform the verification, the ARME uses information about the delegator (password, groups, roles) that is stored in the policy database to build a Subject for the delegator. If the database does not contain the required information, the delegation policy will not be executed. |
Table 2-1 summarizes the functions of authorization and role mapping policies and highlights the differences.
A declaration is a variable that represents either a predefined value (for example, days of the week) or a value that is dynamically defined at runtime (the date). You use declarations in policies as attributes. To help you design policies, built-in declarations are pre-defined for your use. You can also define custom declarations to suit your requirements.
You can define four types of declarations:
A constant is a named value or set of values that does not change at runtime. You can reference constants in policies. For example, if you set a constant named Rate to 12, policies can then refer to the constant Rate rather than using its literal value, 12. Using constants in policies makes them more readable and makes changes to values that are used across of set policies easier
Constants are especially useful if the value changes periodically and you use the constant in more than one location. For example, if you enter a rate value 12 into multiple policies, you need to individually change each one. Instead, if you use the constant Rate, you can edit the value once and have it take effect in every policy that refers to the constant.
An enumerated type is a type that consists of a predefined list of values from which you create constants and multi-valued attributes. The product comes with a number of predefined enumerated types and allows you to define your own. For example, you could define the enumerated type "color" with the values of "red", "green", or "blue".
Attributes represent characteristics that define dynamic values, users, groups, and configurations. Attributes may be associated with users or groups (identity attributes), resources (resource attributes), or policy requests (dynamic attributes). Attributes may be descriptive, may be used to configure policy engine behavior or manage delegated administration, or used in forming policy as part of the policy constraint.
Attributes must have a defined type, which denotes the range of legal values that it may have. A number of predefined types exist, such as string, integer, date, time, and IP address. You can also use custom enumerated types. The value of the attribute may be assigned to only one instance of an attribute. An attribute may be a multi-valued list.
An evaluation function is a named function that you can use in a policy constraint to perform more advanced operations. Each function may have a number of parameters and returns a Boolean result of true or false.
AquaLogic Enterprise Security provides a number of predefined evaluation functions and also allows you to declare your own custom evaluation functions. You can use a predefined function in your application by using a plug-in extension that a programmer creates specifically for your application. To use an evaluation function, you must register it as a plug-in with the authorization and role mapping providers used in the Security Service Module (SSM) configuration and declare it in a policy. For information about creating and using plug-in extensions, see Provider Extensions in the Administration Reference.
|