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:
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 . For information on choosing authentication providers, see Choosing WebLogic and Custom Authentication Providers. For information on configuring authentication providers in the WebLogic Portal Administration Console, see Managing Security Providers.
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 .
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.
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 Setting Up Role-Based Authorization.
BEA 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 Configuring Delegated Administration. For information on creating security policies for portal visitors, see 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 Implementing Authorization Programmatically.
The default authentication provider for WebLogic Portal is the WebLogic SQL Authenticator, which has a PointBase 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 PointBase 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 PointBase demonstration RDBMS. Scripts are available in
>/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.
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.
|Tip:||The default role mapping provider is the WebLogic XACML role mapping provider, which stores role policies separately in the embedded WebLogic LDAP server. 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. You can add users to a custom authentication provider using Workshop for WebLogic, the WebLogic Portal Administration Console, or by adding a user directly through the authentication provider. For more information, see the .
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:
|Notes:||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.|
|Note:||It is possible (but not recommended) to store an identical username or group name in more than one authentication provider. For example, user
|Note:||If you are using an RDBMS user store, be aware of case sensitivity when entering names for users and groups. For example, user
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:
Each authentication provider you connect to WebLogic Server also becomes visible in drop-down lists in Workshop for WebLogic and the WebLogic Portal Administration Console, as shown in Figure 2-1.
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.
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 username, 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 embedded LDAP server 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.
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 username, 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 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:
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:
|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:
For information on creating, viewing, and modifying visitor entitlement roles, see Configuring Visitor Entitlements.
You can create entitlements to control access to the following types of content management resources:
Each has visitor capabilities that are based on the type of resource.
GroupSpace and other 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. For more information on GroupSpace and how to use invitations in GroupSpace, see the.
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 Example Role Hierarchy. You can also create administrators that can, in turn, delegate administration tasks to other administrators.
|Notes:||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:
RoleB can delegate to:
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:
The following steps ensure that your administrators are set up correctly:
For more information, see 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.
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 Designing Visitor Entitlements for Performance.