ALES is itself secured using the same policy model used to secure other applications. This chapter explains the default policies controlling administrative access to ALES. Information is provided in the following sections.
Note: | Many tasks described in the document are performed using the ALES Administration Console. For more information about using the console, access the console’s help system. |
Installing ALES provides a number of objects that collectively define access to ALES components. This provides rudimentary security at startup; you can use the Administration Console to more completely define administrative access.
The default objects are listed below and are more fully described in sections that follow.
A representation of ALES components is defined in a separate tree under a root resource named ASI. Policies can be assigned to a resource representing an ALES component and thereby define access to that component. For more information, see ALES Resources.
|
|
A number of users, groups, and roles that reflect usage of ALES are provided. In particular, a user named
system is set up as having complete administrative rights. For more information, see ALES Identities.
|
|
A number of role mapping policies are provided that assign some of the default roles to users/groups. For more information, see Role Mapping Policies.
|
|
A number of authorization policies are provided that assign privileges to roles/groups/users on specific resources in the ASI resource tree. For more information, see Authorization Policies.
|
By default, ALES provides a single administrative user identity named system
having complete administrative rights. In a production environment, you should remove this administrative user and replace it with one or more other user identities. This section describes how to create a new administrative user named myadmin
, replacing the system
user:
myadmin
.myadmin
user to the Admin role.myadmin
by selecting myadmin
and clicking Edit > Set password.system
user from the Admin role.BEA_HOME/ales30-admin/config/WLESWebLogic.conf
so that under “Java Additional Parameters” this line reads:wrapper.java.additional.15=-Dwles.user.alias=myadmin
wrapper.java.additional.15=-Dwles.user.alias=system
myadmin
user, using the asipassword
utility. Execute:BEA_HOME/ales30-admin
/bin/asipassword.bat myadmin ../ssl/password.xml ../ssl/password.key
and supply the password for myadmin
.
WLESWebLogic.bat console
. You can now log in as myadmin
with the password you set.
ALES components are represented under the ASI resource tree, as shown in the figure below.
Table 9-2 describes resource objects that define the administrative operations that are performed using the Administration Console. By default, these resources are contained within //app/policy/ASI/admin
.
Table 9-3 lists and describes the default privileges that may be assigned.
Context attributes can be used to provide fine-grained protection of policy operations. For example, when creating a privilege, the name of the privilege can be supplied as an attribute and used to control access to a single unique privilege.
Table 9-4 describes the default context attributes.
A list of deleted engines.1
|
||
1The term engine refers to an ASI Authorization provider and ASI Role Mapper provider that are configured to operate in conjunction with one another, also referred to as the ARME. This combination of providers are configured to manage your authorization and role mapping policies. |
The evaluation functions listed in Table 9-5 are provided for writing custom administration policies. They may be used in the constraint portion of policies to limit the applicability of the policy based on contextual information.
Table 9-6 describes when contextual data is used to define administrative access. This data that may be referenced when writing policies to protect the administration console.
Table 9-7 lists the name of each enumerated type used in controlling administrative access.
Table 9-8 shows the default ALES roles, users, and groups and some of their administrative rights as determined by existing policies.
The default role mapping policies are described in Table 9-9 below. There are two ways they can be viewed in the Administration Console:
Of particular note, one of the role mapping policies assigns the Admin role to the user named System. This is the only administrative user provided when ALES is installed.
A number of authorization policies are provided that define access to ALES components. Some of the more important default authorization policies are described in the table below.
ALES allows you to set up application-level administrators who are responsible for managing the security for a specific application. An application-level administrator will be able to manage the policies protecting resources belonging to that application, but no others.
The basic procedure described here for setting up application-level administrators is to create a parent application resource that will contain the application resource to be secured and then define policies that will allow the administrators to manage those resources.
Using the Administration Console to create a resource that serves as the application resource parent involves the following steps:
Policy
resource at the top of the tree and select select Add Resource.Once the application parent resource is defined, you can define policies that apply to resources under the parent resource. Here are two examples:
Note: | A comprehensive understanding of these policies can be obtained by examining the policies already in place for ALES components. |
The following policy assigns the Admin
role to Joe
only for managing resources in the Petstore application.
grant(//role/Admin, //app/policy/ASI/admin/Resource, //user/asi/Joe/) if resource_is_child(resource, //app/policy/Petstore, no);
The following policy assigns Bob
to the Admin
role only for Petstore resources:
grant(//role/Admin, //app/policy/ASI/admin, //user/asi/Bob/) if sys_defined(resource) and resource_is_child(resource, //app/policy/Petstore, no);