| Oracle® Fusion Middleware Security Guide for Oracle WebLogic Portal 10g Release 3 (10.3.5) Part Number E14251-07 |
|
|
View PDF |
| Oracle® Fusion Middleware Security Guide for Oracle WebLogic Portal 10g Release 3 (10.3.5) Part Number E14251-07 |
|
|
View PDF |
Developing a plan to implement security features can save you time during later phases in the portal life cycle.
This chapter includes the following sections:
Use the following guidelines to plan your security strategy:
Determine which authentication providers to use.
You can use multiple WebLogic and custom authentication providers. If a security realm has multiple authentication providers configured, JAAS control flags determine the order of execution of the authentication providers, as described in "Setting the JAAS Control Flag Option" in Oracle Fusion Middleware Securing Oracle WebLogic Server. For information on choosing authentication providers, see Section 2.2, "Choosing WebLogic and Custom Authentication Providers." For information on configuring authentication providers in the WebLogic Portal Administration Console, see Chapter 6, "Managing Security Providers.".
Determine the structure of your users and groups.
If the user store you are accessing already has users organized into groups, you can build a hierarchical tree in the WebLogic Portal Administration Console that matches the existing group structure. If you are using the default WebLogic authentication provider, you do not need to build a group hierarchy tree.
If you are creating new groups, you can structure your users into groups and subgroups that look like your organization, which makes it easier to manage users. A group can be a related collection of users, such as a department, team, or regional office. A user can belong to more than one group, and groups can belong to other groups. For more information on users and groups, see the Oracle Fusion Middleware User Management Guide for Oracle WebLogic Portal.
After you determine your group structure, you can create, modify, and delete groups using Oracle Enterprise Pack for Eclipse (OEPE) or WebLogic Portal Administration Console.
You can later associate groups with delegated administration roles, to control administrator access to portal resources, and visitor entitlement roles, to control the visitor experience in your portal applications.
Determine if you want to collect and store information about users (user profile properties) and if you want to be able to edit those properties.
You can use user profile information to target users with personalized content, e-mails, and pre-populated forms based on the rules you set up. For more information, see the Oracle Fusion Middleware User Management Guide for Oracle WebLogic Portal.
Create a unified user profile (UUP) to retrieve additional user profile information from other user stores to define rules for personalization, delegated administration, and visitor entitlement.
For more information, see the Oracle Fusion Middleware User Management Guide for Oracle WebLogic Portal.
Create delegated administration and visitor entitlement roles using the WebLogic Portal Administration Console.
When you create a role policy for delegated administration and visitor entitlement roles, you can associate users and groups with the role. You can also create a regular expression that enables you to specify date, time, user, and HTTP session and request characteristics for the role. For high level tasks associated with creating delegated administration and visitor entitlement roles, see Section 2.3, "Setting Up Role-Based Authorization."
Create security policies to protect specific portal resources or types of portal resources. You do this by associating a role policy with the resource or resource type.
Oracle recommends basing security policies on roles rather than users or groups. Basing security policies on roles enables you to manage access based on a role that a user or group is granted, which is a more flexible method of management. Your user and group structure is usually static (especially in organizations where control of the user store is centralized), while the roles that users and groups belong to can be more dynamic.
For information on creating security policies for portal administrators, see Chapter 7, "Configuring Delegated Administration.". For information on creating security policies for portal visitors, see Chapter 8, "Configuring Visitor Entitlements.". For information on available authentication techniques you can use to perform access checks at runtime in your portal applications (for example to determine if a user is assigned a specific role) see Chapter 10, "Implementing Authorization Programmatically.".
The default authentication provider for WebLogic Portal is the WebLogic SQL Authenticator, which has a Derby RDBMS as its demonstration user store. You can use another RDBMS, another WebLogic provider (such as the WebLogic LDAP provider), or you can use a custom authentication provider not supplied by WebLogic Server. Once you connect a custom authentication provider to WebLogic Server, the users in the custom provider user store can log into your portal.
Note:
Do not use the WebLogic LDAP provider if you have a large numbers of users and groups. The WebLogic LDAP user store is only sufficient for storing a small number of users and groups.
The default authentication provider for WebLogic Portal is the WebLogic SQL Authenticator. During installation, demonstration users accounts and data are created in the default Derby RDBMS that ships with the WebLogic SQL Authenticator.
In most production environments, you must configure the SQL Authenticator to use your own RDBMS user store rather than the Derby demonstration RDBMS. Scripts are available in <WLPORTAL_HOME>/p13n/db/rdbms_name to configure each supported RDBMS as a user store.
Previous releases of WebLogic Portal included a WebLogic Portal-specific RDBMS Authenticator. This has been deprecated. If you are upgrading from a previous release, you can choose whether to change your default authentication provider using the WebLogic Upgrade Wizard during the domain upgrade. For information on how to upgrade your user store manually or using the WebLogic Upgrade Wizard, see the Oracle Fusion Middleware Upgrade Guide for Oracle WebLogic Portal.
You can also use the WebLogic LDAP Authenticator, which is the default authentication provider for WebLogic Server, as a user store. Due to performance limitations, only use the LDAP Authenticator if you have a small number of users and groups, or if you are in a staging, rather than production, environment. For information on configuring the WebLogic LDAP provider, see "Managing the Embedded LDAP Server" in Oracle Fusion Middleware Securing Oracle WebLogic Server.
Tip:
The default role mapping provider is the WebLogic XACML role mapping provider, which stores role policies separately in the RDBMS security store. The WebLogic XACML role mapping provider is required for WebLogic Portal, and suitable for most needs. It is unlikely that you will need to configure a custom role mapping provider.
If you are using a custom authentication provider, you can connect that provider to WebLogic Server (assuming it is a supported type), so that the users in that custom provider can log in to your portal applications. This user store can contain users, passwords, and user properties; it may or may not contain group information.
Develop custom authentication providers according to the guidelines in "How to Develop a Custom Authentication Provider" in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server. You can add users to a custom authentication provider using Oracle Enterprise Pack for Eclipse, the WebLogic Portal Administration Console, or by adding a user directly through the authentication provider. For more information, see the Oracle Fusion Middleware User Management Guide for Oracle WebLogic Portal.
The users in that custom provider can then log in to your portals.
In addition to the default WebLogic SQL Authenticator, WebLogic Portal supports the use of multiple authentication providers, once they have been configured to work with WebLogic Server. If you have users and groups stored in more than one custom authentication provider, you may want to access the user stores for each of these providers.
Using multiple authentication providers, you can:
Allow users in each authentication provider to log into your portal applications.
Provide personalized applications to users in each authentication provider. You can define personalization rules based on the roles the users or groups have been assigned.
Entitle users in each authentication provider to visitor access to portal application resources based on the visitor entitlement roles the users or groups have been assigned.
Give users in each authentication provider administrative access to portal application resources. You can define delegated administration roles based on the users or groups have been assigned.
Note:
If your external user store contains additional properties for users and groups (for example, e-mail and phone numbers), accessing those properties involves separate development steps to create a UUP. For more information, see the Oracle Fusion Middleware User Management Guide for Oracle WebLogic Portal.
It is possible (but not recommended) to store an identical user name or group name in more than one authentication provider. For example, user foo can reside in the embedded LDAP server and in an RDBMS user store. In that case, WebLogic Portal uses only one user profile for user foo.
If you are using an RDBMS user store, be aware of case sensitivity when entering names for users and groups. For example, user Bob is different from user bob.
The following high-level steps guide you through the process of setting up multiple authentication providers for use with WebLogic Portal. Perform these steps for each authentication provider:
If you are using any custom authentication providers, develop them according to the guidelines in "How to Develop a Custom Authentication Provider" in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server.
Configure each authentication provider to be used with WebLogic Server. For information on how to modify configuration settings in the WebLogic Server Administration Console, see "Configuring Authentication Providers" in Oracle Fusion Middleware Securing Oracle WebLogic Server. This section also lists the authentication providers included with WebLogic Server.
In the WebLogic Server Administration Console, connect to each authentication provider.
Each authentication provider you connect to WebLogic Server also becomes visible in drop-down lists in Oracle Enterprise Pack for Eclipse and the WebLogic Portal Administration Console, as shown in Figure 2-1.
Figure 2-1 Choose the Authentication Provider to Use
You can view and administer external users and groups in the WebLogic Portal Administration Console or by accessing the external user store directly.
If you want to be able to edit information about users and groups in an external user store, you must develop your custom authentication provider to allow write access. If the provider is writable, you can create and modify users, groups, and user profiles that are stored in that provider. For instructions on setting up custom authentication providers and making them writable, see "Configuring Security Providers" in Oracle Fusion Middleware Securing Oracle WebLogic Server.
The default configuration for supported custom authentication providers is read-only access to users and groups from the WebLogic Portal Administration Console and the WebLogic Server Administration Console. If the authentication provider is read-only, you can view the users, groups, and user profiles that are stored in that provider, but you cannot change them.
The WebLogic SQL Authenticator and the WebLogic LDAP Authenticator provide write access by default.
A security role is a privilege granted to users or groups based on specific conditions. Roles are the basis for access control in WebLogic Portal. Administrators can create roles, assign users and groups to roles, and define access control to protected resources based on roles.
Roles can sometimes be mapped directly to groups. The difference between groups and roles is that group membership is statically assigned by a server administrator, while role membership is dynamically determined based on information including the user name, group membership, user profile property values, session and request attributes, and date and time functions. Roles can also be scoped to specific WebLogic resources within a single application in a WebLogic Server domain, while groups are always scoped to an entire WebLogic Server domain.
A role policy consists of a role name and role definition. Once you create a role policy, you define an association between the role and a WebLogic resource. This association, called a security policy, specifies who has what access to the WebLogic resource. The default role mapping provider is the WebLogic XACML provider, which uses the RDBMS security store to store role policies.
Note:
The WebLogic XACML role mapping provider is required for WebLogic Portal, and suitable for most needs. It is unlikely that you will need to configure a custom role mapping provider.
Roles can be scoped to any resource in an application. A role that applies to all resources deployed within a security realm (the entire WebLogic Server domain) is called a global role. A role that applies to a specific instance of a resource deployed in a security realm (such as a portal-specific resource) is called a scoped role. You can combine role types when creating security policies for WebLogic resources.
Global roles are roles that apply to all WebLogic resources in a security realm. You administer global roles using the WebLogic Server Administration Console.
WebLogic Server automatically creates certain default global roles, with default privileges and group assignments for each role. When a user is added to one of these groups, that user is automatically granted the global role. All the global roles defined in the security realm are shown in the WebLogic Server Administration Console Global Roles page. For more information, see "Default Global Roles" in Oracle Fusion Middleware Securing Resources Using Roles and Policies for Oracle WebLogic Server.
Scoped roles apply to a specific WebLogic resource. Scoped roles can be used for visitor entitlements and delegated administration.
Delegated administration roles are enterprise-application scoped. This is because it is desirable to have one administration role for all the web applications (each of which contains one or more portals). You must carefully consider your security requirements when setting up delegated administration roles.
Visitor entitlement roles on portal resources can be web-application scoped or enterprise-application scoped. If each web application has different requirements for constraints on visitor access, you should typically use web-application scoped roles. However, if you want to use the same roles in multiple web applications within an enterprise application, you can use enterprise-application scoped roles.
Using the WebLogic Portal Administration Console, you can configure a scoped role for portal resources in the resource library or in a specific desktop.
To protect all instances of a specific book, page, or portlet, or all books, pages, or portlets, set the security policies for the resource or resource type in the portal resource library. The library contains the master versions of all portal resources, and the security policies set in the library apply to a resource wherever it appears in the desktop (Portals node).
You can also set security policies for a desktop resource, such as a book, page, or portlet, in the desktop. If you set security policies for a resource in a desktop (and not in the resource library), they are only enforced for that instance in that desktop. You can also set security policies on an entire desktop.
Note:
If you set a security policy on a specific resource in a desktop (for example, a portlet) it applies only to that instance of the resource. Therefore, if you do not secure a resource within the resource library, you must secure each instance of the resource, wherever it appears in the hierarchy of books and pages in the desktop.
Use visitor entitlement roles to enable customization and personalization in your portal applications, as well as to control visitor access to your portal. Visitor entitlements control visitor access to portal resources, groups, and content management resources.
Visitor entitlement roles dynamically determine what access privileges a portal visitor has based on user name, group membership, profile, session and request attributes, and date and time functions. Security policies determine what capabilities for a given resource are available to a given role. Entitlement capabilities differ by resource, as described in Chapter 8, "Configuring Visitor Entitlements."
Tip:
Resources without entitlements placed on them are available to everyone.
Visitor access is based on the visitor entitlement roles you create in the WebLogic Portal Administration Console.
You can create entitlements to control visitor access to the following types of portal resources:
Library
Desktops
Books
Pages
Communities
Templates
Look and feels
Portlet categories
Portlets
Depending on the resource, you can set visitor entitlements in the resource library or the desktop. Within a given desktop, you can entitle specific resources in the desktop such as pages, books, and portlets. Within the library, you can entitle specific books, pages, and portlets, or all resources in one of these categories.
Visitor entitlements in the resource library apply to all instances of the resource in portal applications. However, they do not bar you from setting more local policies in the desktop.
When a request is made by a portal visitor for access to a resource, access checks are performed in the following order:
Security policies for that resource in the desktop are enforced.
Security policies for that resource in the resource library are enforced.
Security policies for that resource type in the library are enforced.
Note:
If you only set protection for resources in the desktop, they are only enforced in the desktop. To protect the resource globally, you must set entitlements on the resource in the library.
To configure visitor entitlements on portal resources:
Make sure users and groups are configured in your user store. For information about creating users and managing user profiles and groups, see the Oracle Fusion Middleware User Management Guide for Oracle WebLogic Portal.
Create a visitor entitlement role if one with the appropriate settings does not exist, as described in Section 8.1, "Creating Visitor Entitlement Roles."
Assign users, groups, or conditions to the visitor entitlement role, as described in Section 8.2, "Adding Users, Groups, and Conditions in Visitor Entitlement Roles."
Create security policies to determine what capabilities your role has for a given portal resource, as described in Section 8.11, "Setting Visitor Entitlements on Portal Resources in the Library" and Section 8.12, "Setting Visitor Entitlements on Portal Resources in the Desktop."
For information on creating, viewing, and modifying visitor entitlement roles, see Chapter 8, "Configuring Visitor Entitlements."
You can create entitlements to control access to the following types of content management resources:
Repositories
Content
Content types
Workflows
Each has visitor capabilities that are based on the type of resource.
Community creators and owners can invite others to join the Community. Visitor entitlements determine whether a creator or owner can view potential members using the Browse options when selecting who to invite. See also Oracle Fusion Middleware Communities Guide for Oracle WebLogic Portal.
The only visitor capability for groups is View access to the group, which determines whether the community owner or creator can see the group and the users in the group.
Delegated administration roles allow you to determine what actions various administrators can take using administrative tools on different resources. Delegated administration roles are mapped to administrative functions using security policies. You can create and maintain separate administration capabilities depending on your organizational needs. For example, you can create separate administrators for your company's Human Resources and Accounts Payable departments. The portal resources associated with each department can only be managed by the administrators you specify.
WebLogic Portal includes a default system administrator, PortalSystemDelegator, which is the role where the hierarchical delegation starts. By default, all members of the Administrators group are assigned the PortalSystemDelegator role. Anyone assigned the PortalSystemDelegator role has unlimited access to administrative tasks anywhere in the enterprise portal application. You can create as many different administrators as you need by creating administrator roles and then assigning specific users, groups, or conditions to those roles.
You can use delegated administration to propagate access privileges within a hierarchy of roles that define the structure for delegated administration. You have flexibility in the way you set up your administration hierarchy and assign privileges to your administrators. You can create different levels of administrators, each with varying degrees of access, as described in Section 2.3.3.1, "Example Role Hierarchy." You can also create administrators that can, in turn, delegate administration tasks to other administrators.
Note:
If you are using more than one authentication provider, you can have a group in one provider with a name that is the same as a group in another provider. When you set delegated administration on a group, an administrator in that delegated administration role can manage that group in all providers that contain that group (if the administrator has delegated administration privileges for all the providers).
A role hierarchy enables you to keep a tight control on how delegation happens and who can delegate to whom. In the WebLogic Portal Administration Console, one administrator (mapping to a role) might want to create sub-roles for other administrators with limited administration privileges.
A child role has a subordinate relationship to its parent role. A role can delegate only to its sub-roles, thus restricting delegated administration. The following is an example hierarchy.
RoleA can delegate to:
Role1
Role2
Role3 can delegate to:
Role 3.1
Role 3.2
RoleB can delegate to:
Role4
Role5
Role6
The user assigned RoleA cannot delegate to the sub-roles of RoleB as a peer role. RoleA can delegate to any of its descendants.
Child roles do not inherit the privileges of the parent role. If you delete a child role, you are removing it from the system.
Note:
Child roles within a delegated administration role must be uniquely named. For example, you cannot have a delegated administration role called RoleA with a child role called RoleB if you already have a child role called RoleB elsewhere in the hierarchy.
You can create delegated administration roles at any time after you have determined your role strategy:
Before the portals are assembled
While assembling and designing a portal in an interactively
After the portal has been assembled
The following steps ensure that your administrators are set up correctly:
Model your delegated administration hierarchy to fit the needs of your organization.
Create a role for each administrator type.
Define role policies in any of the following ways:
Add one or more users to a role
Add one or more groups to a role
Add users using expressions (user profile properties, session and request attributes, and date and time functions)
Define security policies by assigning delegated administration privileges to various resources, including:
Groups
Portal resources
Interaction management objects
Content management objects
Authentication providers
Visitor entitlements
For more information, see Chapter 7, "Configuring Delegated Administration."
Plan and create your groups according to the roles you will create. If you do not consider roles in your group planning, you might have to modify your groups to accommodate roles. For more information on groups, see the Oracle Fusion Middleware User Management Guide for Oracle WebLogic Portal.
For more efficient management, grant roles to groups rather than to individual users.
Note:
Do not use the WebLogic LDAP provider to store large numbers of users and groups. The WebLogic LDAP user store is only sufficient for storing a small number of users and policies for roles and entitlements.
For information on designing visitor entitlements for performance, see Section 8.18, "Designing Visitor Entitlements for Performance."
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
