| Oracle® Retail Merchandising Security Guide Release 14.1 E55776-01 |
|
 Previous |
 Next |
The chapter provides guidance for administrators to understand, configure, and customize functional security for Application Development Framework (ADF) applications or applications using Fusion Middleware platform security infrastructure like OBIEE.
The following topics are covered in this chapter:
The Oracle Retail Fusion security model is built upon the Oracle Fusion Middleware platform, which incorporates the Java security model. The Java model is a role-based, declarative model that employs container-managed security where resources are protected by roles that are assigned to users. However, extensive knowledge of the Java-based architecture is unnecessary when using the Oracle Fusion Middleware Security model.
The Oracle Fusion Middleware security model depends upon the following key elements in order to provide uniform security and identity management across the enterprise:
Application policy
Application permissions are granted to members of its application roles. In the default security configuration, each application role conveys a predefined set of permissions. Permission grants are defined and managed in an application policy. After an application role is associated with an application policy, that role becomes a Grantee of the policy. An application policy is specific to a particular application.
Application role
After permission grants are defined in an application policy, an application role can be mapped to that policy, and the application role then becomes the mechanism to convey the permissions. In this manner, an application role becomes the container that grants permissions to its members. The permissions become associated with the application role through the relationship between policy and role. After groups are mapped to an application role, the corresponding permissions are granted to all members equally. Membership is defined in the application role definition. Application roles are assigned in accordance with specific conditions and are granted dynamically based on the conditions present at the time authentication occurs. More than one group can be members of the same application role.
Authentication provider
An authentication provider is used to access user and group information and is responsible for authenticating users. An Oracle WebLogic Server authentication provider enables you to manage users and groups in one place.
An identity store contains user name, password, and group membership information. An authentication provider accesses the data in the identity store and authenticates against it. For example, when a user name and password combination is entered at login, the authentication provider searches the identity store to verify the credentials provided. The Oracle Retail Fusion application's default authentication provider authenticates against Oracle Internet Directory (OID).
Users and groups
A user is an entity that can be authenticated. A user can be a person, such as an application user, or a software entity, such as a client application. Every user is given a unique identifier.
Groups are organized collections of users that have something in common. Users should be organized into groups with similar access needs in order to facilitate efficient security management.
Security realm
An Oracle Retail Fusion application is installed on an Oracle WebLogic Server domain, which is created during installation. The Oracle Retail Fusion application security is managed within the security realm for this Oracle WebLogic Server domain. A security realm acts as a scoping mechanism. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies. Only one security realm can be active for the domain. The Oracle Retail Fusion application's authentication is performed by the authentication provider configured for the default security realm for the WebLogic Server domain in which it is installed. Oracle WebLogic Server Administration Console is the administration tool used for managing an Oracle WebLogic Server domain.
Each Oracle Retail Fusion application provides application-specific permissions for accessing different features. Application permissions are typically granted by becoming a member in an application role. Permissions can be granted in two ways - through membership in an application role (direct) and through group and role hierarchies (inheritance). Application role membership can be inherited by nature of the application role hierarchy. In the default security configuration, each application role is pre configured to grant a predefined set of permissions. Groups are mapped to an application role. The mapping of a group to a role conveys the role's permissions to all members of the group. In short, permissions are granted in Oracle Retail Fusion applications by establishing the following relationships:
A group defines a set of users having similar system access requirements. Users are added as members to one or more groups according to the level of access required.
Application roles are defined to represent the role a user typically performs when using the Oracle Retail Fusion application.
The groups of users are mapped to one or more application roles that match the type of access required by the population.
An application role is mapped to the application policy that grants the set of permissions required by the role type (an administrator, an author, a consumer).
Group membership can be inherited by nature of the group hierarchy. Application roles mapped to inherited groups are also inherited, and those permissions are likewise conveyed to the members.
User permissions are determined by the system as follows:
A user enters credentials into a Web browser at login. The user credentials are authenticated by the authentication provider against data contained in the identity store.
After successful authentication, a Java subject and principal combination is issued, which is populated with the user name and a user's groups.
A list of the user's groups is generated and checked against the application roles. A list is created of the application roles that are mapped to each of the user's groups.
A user's permission grants are determined from knowing which application roles the user is a member of.
A user can also be granted permissions if they inherit other application roles. Members of application roles can include other groups and application roles. The result is a hierarchical role structure where permissions can be inherited in addition to being explicitly granted. This hierarchy provides that a group is granted the permissions of the application role for which it is a member, and the permissions granted by all roles descended from that role.
For example, the default security configuration includes several predefined groups and application roles. The default BIAdministrator application role includes the BIAdministrators group, the BIAuthor application role includes the BIAuthors group, and the BIConsumer application role includes the BIConsumers group. The default BIAdministrator application role is a member the BIAuthor application role, and the BIAuthor application role is a member of the BIConsumer application role. The members of these application roles inherit permissions as follows. Members of the BIAdministrators group are granted all the permissions of the BIAdministrator role, the BIAuthor role, and the BIConsumer role. By nature of this role hierarchy, the user who is a member of a particular group is granted permissions both explicitly and through inheritance.
|
Note: By themselves, groups and group hierarchies do not enable any privilege to access resources controlled by an application. Privileges are conveyed by the permission grants defined in an application policy. A group or application role becomes a Grantee of the application policy. The application policy Grantee conveys the permissions and this is done by becoming a member of the Grantee (application role). |
Figure 8-1 shows these relationships between the default groups and application roles.
Table 8-1 summarizes how permissions are granted explicitly or are inherited in the previous example and in Figure 8-1.
Table 8-1 Permissions Granted by the Role Hierarchy Example
| User Name | Group Membership: Explicit/Inherited | Application Role Membership: Explicit/Inherited | Permission Grants: Explicit/Inherited |
|---|---|---|---|
| User1, User2, User3 |
BIConsumers: Explicit |
BIConsumer: Explicit |
Permission A: Explicit |
|
User4, User5 |
BIAuthors: ExplicitBIConsumers: Inherited |
BIAuthor: Explicit BIConsumer: Inherited | Permission B: Explicit Permission A: Inherited |
|
User6, User7 |
BIAdministrators: ExplicitBIAuthors: InheritedBIConsumers: Inherited |
BIAdministrator: ExplicitBIAuthor: InheritedBIConsumer: Inherited |
Permission C: Explicit Permission B: Inherited Permission A: Inherited |
After a user is authenticated, further access to application resources is controlled by the granting of permissions, also known as authorization. The policy store contains the system and application-specific policies and roles required for an application. A policy store can be file-based, LDAP-based or Oracle database and holds the mapping definitions between the default Oracle Retail Fusion Application's application roles, permissions and groups. Oracle Retail Fusion Application's permissions are granted by mapping groups from the identity store to application roles and permission grants located in the policy store. These mapping definitions between groups (identity store) and the application roles (policy store) are also kept in the policy store.
|
Note: The best practice is to map groups instead of individual users to application roles. Controlling membership in a group reduces the complexity of tracking access rights for multiple individual users. Group membership is controlled in the identity store. |
The system-jazn-data.xml file is installed and configured as the default policy store. You can continue to use the default store and modify it as needed for your environment, or you can migrate its data to an Oracle database.
The policy store and credential store must be of the same type in your environment. That is, both must be either filed-based, LDAP-based, or Oracle database.
Permissions must be defined in a manner that the Oracle Retail Fusion Application understands. All valid Oracle Retail Fusion Application permissions are premapped to application policies, which are in turn premapped to the default application roles. You cannot create new permissions in the policy store. However, you can customize the default application policy permission grants and application role mappings as well as create your own.
Launch Fusion Middleware Control by entering its URL into a Web browser. The URL includes the name of the host and the administration port number assigned during the installation. This URL takes the following form: http://hostname:port_number/em. The default port is 7001. For more information about using Fusion Middleware Control, see Oracle Fusion Middleware Administrator's Guide.
Log on to Oracle Enterprise Manager Fusion Middleware Control by entering the URL in a Web browser. For example, http://hostname:7001/em
The Fusion Middleware Control login page is displayed.
Enter the Oracle Retail Fusion Application's administrative user name and password and click Login.
The password is the one you supplied during the installation of Oracle Retail Fusion Application. If these values have been changed, then use the current administrative user name and password combination.
From the target navigation pane, click WebLogic Domain to display APPdomain. Display the Security menu by selecting one of the following methods:
Right click APPdomain to display the Security menu.
Select Security to display a submenu.
From the content pane, go to WebLogic Domain menu and select Security
Select Security to display a submenu.
Use Fusion Middleware Control to manage the Oracle Retail Fusion Application's application policies and application roles maintained in the policy store whether it is filed-based, LDAP-based, or Oracle database.
|
Caution: Oracle recommends you to make a copy of the original system-jazn-data.xml policy file and place it in a safe location. Use the copy of the original file to restore the default policy store configuration, if needed. Changes to the default security configuration may lead to an unwanted state. The default installation location is MW_HOME/user_projects/domain/your_domain/config/fmwconfig. |
The following are common policy store management tasks:
Modifying the membership of an application role. For more information, see Modifying Application Roles Using Fusion Middleware Control section.
Creating a new application role from the beginning. For more information, see To create a new application role section.
Creating a new application role based on an existing application role. For more information, see To create an application role based on an existing one section.
Members can be added or deleted from an application role using Fusion Middleware Control. You must perform these tasks while in the WebLogic Domain that Oracle Retail Fusion Application is installed in.
|
Caution: You need to be careful when changing the permission grants and membership for the default application roles. Changes could result in an unusable system. |
Valid members of an application role are groups, or other application roles. The process of becoming a member of an application role is called mapping. That is, being mapped to an application role is to become a member of an application role. The best practice is to map groups instead of individual users to application roles for easier maintenance.
Log in to Fusion Middleware Control, navigate to Security, then select Application Roles to display the Application Roles page.
For information on navigating to the Security menu, see Accessing Oracle Enterprise Manager Fusion Middleware Control section.
Choose Select Application Stripe to Search, then select the policy stripe name (example, ALC_CORE) from the list.
Click the search icon next to Role Name.
The Oracle Retail Fusion Application's application roles are displayed.
Figure 8-6 displays the default application roles.
Select the cell next to the application role name and click Edit to display the Edit Application Role page.
Figure 8-7 shows ALC_ALLOC_MANAGEMENT_DUTY role is selected.
|
Note: You can add or delete members from the Edit Application Role page. The valid members are application roles, and groups |
Select from the following options:
To delete a member: From Members, select from Name the member to activate the Delete button and click Delete.
To add a member: Click the Add button that corresponds to the member type being added. Select from Add Application Role, Add Group, and Add User.
For adding a member, complete Search and select from the available list and click OK.
Figure 8-8 shows the Add Group dialog and after the BUYER_JOB group has been selected.
The added member displays in the Members column corresponding to the application role modified in the Application Roles page.
Following are the two methods for creating a new application role:
Create New: A new application role is created. Members can be added at the same time or you can save the new role after naming it and add members later.
Copy Existing: A new application role is created by copying an existing application role. The copy contains the same members as the original, and is made a Grantee of the same application policy. You can modify the copy as needed to finish creating the new role.
Log in to Fusion Middleware Control, navigate to Security, then select Application Roles to display the Application Roles page.
For information, see Accessing Oracle Enterprise Manager Fusion Middleware Control section.
Choose Select Application Stripe to Search, and then click the search icon next to Role Name.
The Oracle Retail Fusion Application's application roles displays.
Click Create to display the Create Application Role page. You can enter all information at once or you can enter a Role Name, save it, and complete the remaining fields later.
In the General section, specify the following:
Role Name - Enter the name of the application role.
Display Name - Enter the display name for the application role. This is an optional field.
Description - Enter a description for the application role.This is an optional field.
In the Members section, select the groups, or application roles to be mapped to the application role.
Select Add Application Role or Add Group accordingly.
To search in the dialog box that displays, specify the following:
Enter a name in Name field and click the blue button to search.
Select from the results returned in the Available box.
Click OK to return to the Create Application Role page.
Repeat the steps until all members are added to the application role.
Click OK to return to the Application Roles page.
The application role just created displays in the table at the bottom of the page.
Log in to Fusion Middleware Control, navigate to Security, then select Application Roles to display the Application Roles page.
For more information, see Accessing Oracle Enterprise Manager Fusion Middleware Control section.
Choose Select Application Stripe to Search, and then click the search icon next to Role Name.
The Oracle Retail Fusion Application's application roles is displayed.
Select an application role from the list to enable the action buttons.
Click Create Like to display the Create Application Role Like page.
The Members section is completed with the same application roles, groups that are mapped to the original role.
Complete the Role Name, Display Name, and Description fields.
Example 8-0 shows an application role based upon ALC_ALLOC_MANAGEMENT_DUTY after being named MyNewRole, as an example.
Use Add and Delete to modify the members as appropriate and click OK.
The just created application role displays in the table at the bottom of the page. The following figure shows the example MyNewRole that is based upon the default ALC_ALLOC_MANAGEMENT_DUTY application role.
You can customize the default security configuration in the following ways:
Create new application roles. For more information, see To create a new application role section.
Modifying membership in an Application Role. For more information, see Modifying Application Roles Using Fusion Middleware Control section.
The Fusion Middleware Security model can be customized for your environment by creating your own application roles and modifying membership of application roles. Existing application roles can be modified by adding or removing members as needed. For more information about managing application policies and application roles, see Oracle Fusion Middleware Application Security Guide.
|
Note: Before creating a new application role and adding it to the default Oracle Retail Fusion Application's security configuration, familiarize yourself with how permission and group inheritance works. It is important when constructing a role hierarchy that circular dependencies are not introduced. The best practice is to leave the default security configuration in place and first incorporate your customized application roles in a test environment. For more information, see Permission Grants and Inheritance section. |
