|
|
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 actions 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 actions the users are to have on the resources.
There are two types of policies: authorization policies and role mapping policies. Each type has different functions:
The policy evaluation strategy imposes a closed-world security environment. This means that all actions on all protected resources are implicitly denied until authorization policies grant specific actions. In other words, an authorization policy must grant actions on resources before users can do anything. Once access is granted, you must explicitly deny it to revoke that right — and explicit DENY policies cannot be overruled.
This provides security that errs on the side of caution. For example, if you forget to deploy an authorization policy, someone will be denied access. While this is problematic, from a security standpoint it is preferable to inadvertently allowing access to resources that should be protected. Users who are denied required access will almost certainly ask for corrective action, while users inadvertently granted unauthorized access are unlikely to bring this to the attention of administrators — with potentially disastrous consequences.
All policies follow a specified sentence-like syntax. The ALES Entitlements Administration application provides a graphical interface that facilitates construction of policies. The constraints portion of the policies can be directly entered as described in this guide, however the main part of the policy is constructed via the graphical interface. The ALES Administration Console allows directly entering entire policies, however use of this console to edit policies not suggested post ALES 3.0.
A single policy can have multiple actions, resources, and defined subjects. The general syntax for an AquaLogic Enterprise Security policy is as follows:
Effect (action|role, resource, subject, delegator) IF constraint;
Policies must adhere to the following rules:
A resource is used to represent an underlying application or application component (or any object), 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 (for example, Reports, Transactions, Revenue Charts). Resources may have attributes; for example bank accounts have owners and transfer limits. Resources are hierarchical and child resources inherit the policies and attributes from their parent.
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 actions to users, groups, or roles for the top-level resource and resources on the tree. Hence, defining a resource tree is a necessary prerequisite 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 actions to the TellerApp resource.
Some typical resources that you might want to protect with ALES include:
| Note: | In development mode, you may use the Resource Discovery setting for an SSM 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. Once you configure a resource to allow virtual resources, any of its children are protected by the same policies as the resource, even though they do not appear in the resource tree. For example, if you define resource "/report" to be virtual, any authorization requests for the resource "/report/Monthly/September" would be subject to the policies defined for "/report". This allows you to avoid having to define a specific resource node in the tree for every resource to be protected. For large applications with many hierarchical resources (e.g. web URLs) this can mean a considerably smaller resource tree.
You can associate attributes with resources. An attribute contains information about a characteristic of the resource to which it is associated. 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.
An action group is constructed by grouping multiple actions. An action can belong to more than one action group. In addition to the action groups that are provided in the product, you can define your own with distinct characteristics. Action groups are not used in policies. They are simply a way to organize actions and have no meaning when writing a policy and are only provided to simplify the task of choosing the right action.
It is common to define an action group that applies to a particular application or set of transactions. You can control access to action groups (those provided in the product and those that are user-defined) through delegated administration.
An action represents an activity or task in your business policy that can be executed on a resource. Actions in a policy specify what action is to be granted or denied on a resource. Actions 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 actions 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 actions. 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 actions that are provided in the product, you can define your own actions. You can also organize actions into logical groups for ease of management.
You use actions to write authorization polices as follows:
grant(action, 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 action and a LeadTellers role. Now, to grant LeadTellers (the role) the authority to open an account (the action), 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).
ALES provides the ability to manage identity directories. An identity directory serves as a logical container for a collection of users and groups, and possibly identity attributes. 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 its 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. 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 actions 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.
In order to use Identity Attributes in authorization or role mapping policies you must configure ALESIdentityAttributeRetriever for ASI Authorization Provider. See ALES Identity Attribute Retrievers for details.
A group is 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 actions to the group, the members of subgroups will have the same actions. 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. Policies can be written specifically for individual users, but 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 techniques.
To specify the access control requirements for your resources you write a set of policies that may include role mapping policies and authorization policies.
The following topics describe the different types of policies:
Roles provide a useful abstraction from Users or Groups. For example the Accounting Manager role may be assigned to a specific Group of individuals but only in the context of the Payroll application. In another context or application, the same User or Group does not have that role. Roles in ALES are defined by Role Mapping Policies which have the same construct and follow the same syntax and ALES Access Policies. Roles are created in a hierarchy. Users who are granted actions based on a child Role inherit the actions from that Role's parents. Users that are denied actions based on a Parent role are also denied actions for that role's children.
Separation of Duties enables the ALES administer to exclude users from a specified role if they are members of another specified role. For example, an administrator may prevent users mapped to the Traders role from also being mapped to the Trade Approvers role.
Roles can have attributes. Role attribute inheritance follows the same logic as Role inheritance.
Role definitions are governed by an underlying Role mapping policies that define when 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.
For example, the following policy grants the accountants role to the user Bill on the payroll resource:
GRANT(//role/accountants, //app/policy/acme/payroll, //user/acme/Bill/);
At runtime, user access actions 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, Role Mapping Policy 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 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(action, resource, subjects[users, groups, roles]) IF constraints;
Where the grant|deny portion is the policy effect and either allows or prohibits the action to the subject for the given resource, the action defines the action, resource defines the application or application component of the action, subjects specify which users, groups, and roles are granted the action, and constraints defines any conditions that apply to the action.
For example, this policy grants any actions supported by the acme payroll application (the resource) to the user agarcia in the acme directory:
GRANT(//priv/any, //app/policy/acme/payroll, //user/acme/agarcia/);
The policy grants any actions 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 action:
GRANT(//priv/any, //app/policy/acme/payroll, //role/accountants/);
Therefore, before anyone can gain this action, 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 action, 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, it 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, this policy denies the view action related to the acme payroll application to everyone belonging to the group named receptionist in the acme directory:
DENY (//priv/view, //app/policy/acme/payroll, //sgrp/acme/receptionist/);
Delegation allows you to share the actions of one user with other users and/or groups.
DELEGATE (action|role, resource, subject, delegator) IF constraint;
A DELEGATE policy that delegates a action allows you to share the actions of one user with other users and/or groups. 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 actions that larry (the delegator) 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 delegator) to joe at runtime if the current mouth is December.
| Note: | Before a delegator’s action can be delegated, the ARME must verify that the delegator has the action 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 three 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.
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, manage delegated administration, or used in forming policy as part of the policy constraint.
Attributes must have a defined type that denotes the range of legal values it may have. A number of predefined types exist, such as string, integer, date, time, and IP address. You can also use custom 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.
|