WebLogic Server v8.1 Installation
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
This section covers the following topics:
Integrating WebLogic Enterprise Security with WebLogic Portal server and portal application results in an enhanced set of security services for use in protecting WebLogic Portal (see Figure 5-1). WebLogic Enterprise Security participates in the authoring and management of policy for WebLogic Portal resources. Once WebLogic Enterprise Security is integrated with WebLogic Portal, you use WebLogic Enterprise Security Administration Application to manage resources related to portal desktops, books, pages, and portlets.
Therefore, the intent is that you use WebLogic Enterprise Security for authorization of the resources associated with a portal application as well as standard WebLogic Server J2EE resources. The benefit of using WebLogic Enterprise Security to manage visitor entitlements is that it offers fine-grained, dynamic role-based authorization. Additionally, WebLogic Enterprise Security allows you to have common security policies for a heterogeneous environment. For example, you may have a single security infrastructure that supports WebLogic Portal, WebLogic Server, and custom applications.
The WebLogic Enterprise Security security service does not replace all of the management functionality provided by the Portal Administration Tools. For example, as shown in Figure 5-1, WebLogic Enterprise Security is not used to manage administrative users and resources associated with Portal Delegated Administration and Portal Content Management; use the Portal Administration Tools for those management tasks.
Figure 5-1 Portal Integration Overview
WebLogic Enterprise Security enables you to write, deploy, and manage fine-grained policy for the authorization of WebLogic Portal application resources. You can use WebLogic Enterprise Security to protect portal desktops, books, pages, portlets, and application look and feels.
For more information, see the following topics:
WebLogic Enterprise Security can be used with either WebLogic Server 8.1 Service Pack 3 or Service Pack 4. While several different security providers can be used with WebLogic Portal, the following security providers include enhanced WebLogic portal support:
Note: Use of the Database Authentication provider with WebLogic Portal is not mandatory. You may use other authentication providers as well.
The following use-case scenario is supported when you integrate WebLogic Enterprise Security with WebLogic Portal:
Note: To implement this use case scenario, you must define the security configuration as specified in Creating the Portal Application Security Configuration.
When integrated with WebLogic Enterprise Security, WebLogic Portal has the following constraints and limitations:
Use of WebLogic Enterprise Security with a Portal application implies that an administrator will not use the Portal Administration Tools to create "Visitor Entitlements" on portal desktops, books, pages, and portlets. Managing visitor entitlements from the Portal Administration Tools is not a supported use case.
WebLogic Enterprise Security does not to support the migration of visitor entitlements policy for existing portal applications. There are no facilities for migrating any information from the WebLogic Server embedded LDAP store.
Before you begin, you must ensure that the following pre-requisites are satisfied:
This section describes how to integrate WebLogic Enterprise Security with WebLogic Portal. Once integrated, you can use the WebLogic Enterprise Security Administration Console to write and deploy security policy to protect WebLogic Portal application resources.
Note: While the instructions provided is this section use a WebLogic Portal server and the sample portal application that ships with the WebLogic Platform 8.1 software distribution, you can use this procedure to integrate WebLogic Enterprise Security with your WebLogic Portal server and portal application.
To integrate WebLogic Enterprise Security with WebLogic Portal, perform the following tasks:
This section describes how to create a new security configuration named myrealm
. A security configuration defines the set of security providers to use for adjudication, authentication, auditing, authorization, role mapping, and credential mapping services. The security configuration named myrealm
matches the default security configuration for the WebLogic Portal sample portal application.
Note: To implement the use-case scenario described in Supported Use-case Scenario, you are required to defined the security configuration as described in this section. This security configuration is a requirement; it is not optional.
Refer to Table 5-1 and use the WebLogic Enterprise Security Administration Application to configure the security providers listed there. Set the Configuration ID to myrealm
. For instructions on creating a security configuration, see Configuring a Security Service Module in the Administration Application Guide and the Console Help.
Uncheck the Require Unanimous Permit check box, and click Create. |
|
Set the Control Flag to Note: Even though you set the Identity Scope to |
|
Set the Control Flag to Note: Make sure the authentication providers are configured in the following order: 1) Database Authenticator and 2) WebLogic Authenticator. Note: The WebLogic Authentication provider can be replaced with another authentication provider that supports write access to users and groups. |
|
On the General tab, accept the default settings, and click Create. On the Details tab, set the Identity Scope to |
|
Uncheck the Policy Deployment Enabled check box, and click Create. |
|
Uncheck the Credential Mapping Deployment Enabled check box, and click Create. |
|
On the General tab, accept the default settings, and click Create. On the Details tab, set the Identity Scope to |
|
Uncheck the Role Deployment Enabled check box, and click Create. |
The security configuration must be bound to a Service Control Manager.
To bind the myrealm
security configuration, see Binding a Security Service Module to a Service Control Manager in the Administration Application Guide and the Console Help
The myrealm
security configuration must be distributed.
To distribute the myrealm
security configuration, see Distributing Configuration in the Administration Application Guide and the Console Help.
Before starting a WebLogic Server Security Service Module, you must first create an instance of the WebLogic Server 8.1 Security Service Module using the Create New Instance Wizard.
To create an instance of a WebLogic Server 8.1 Security Service Module, see Creating an Instance of the WebLogic 8.1 Security Service Module.
You must have the Administration Server running prior to enrolling the Security Service Module.
Note: While you can use the demonstration digital certificate in a development environment, you should never use it in a production environment.
To enroll a security service module, see Enrolling the Instance of the Security Service Module.
Before you can start a WebLogic Portal server that uses BEA WebLogic Enterprise Security, you must modify the startWeblogic
file that is located in the WebLogic Portal domain that you are using for you WebLogic Portal server. These modifications are needed so that portal connects the WebLogic Portal domain to the distributed myrealm
security configuration on startup.
The startWeblogic
file for the WebLogic Portal domain named portalDomain
is located at: BEA_HOME\user_projects\domains\portalDomain
To edit the startWeblogic
file, perform the steps:
Note: This procedure assumes a Windows installation of WebLogic Portal in the directory c:\bea
with an WebLogic Server 8.1 Security Service Module instance named portalInstance
.
startWeblogic.cmd
to startWeblogic.cmd.original
.set-wls-env.bat
. For example, add it below the line: set SAVE_JAVA_OPTIONS=
call "c:\bea\wles42-ssm\wls-ssm\instance\portalInstance\bin\set-wls-env.bat"
classpath
variables to the classpath
. For example, add the following text before the line: echo CLASSPATH=%CLASSPATH%
set CLASSPATH=%WLES_PRE_CLASSPATH%;%CLASSPATH%;%WLES_POST_CLASSPATH%
%WLES_JAVA_OPTIONS%
to the server start command after %JAVA_OPTIONS%
. Listing 5-1 shows, in bold text, where to make this change.Listing 5-1 Adding WLES_JAVA_OPTIONS to the startWebLogic File
if "%WLS_REDIRECT_LOG%"=="" (
echo Starting WLS with line:
echo %JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% %WLES_JAVA_OPTIONS% -Dweblogic.Name=%SERVER_NAME% -Djava.security.policy=%WL_HOME%\server\lib\weblogic.policy %PROXY_SETTINGS% %SERVER_CLASS%
%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% %WLES_JAVA_OPTIONS% -Dweblogic.Name=%SERVER_NAME% -Djava.security.policy=%WL_HOME%\server\lib\weblogic.policy %PROXY_SETTINGS% %SERVER_CLASS%
) else (
echo Redirecting output from WLS window to %WLS_REDIRECT_LOG%
%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% %WLES_JAVA_OPTIONS% -Dweblogic.Name=%SERVER_NAME% -Djava.security.policy=%WL_HOME%\server\lib\weblogic.policy %PROXY_SETTINGS% %SERVER_CLASS% > "%WLS_REDIRECT_LOG%" 2>&1
)
Create a text file named security.properties
and place it in the portal domain directory. You use this file to define the WebLogic Enterprise Security realm and the default realm. Listing 5-2 shows the content of this file for the realm myrealm
.
Listing 5-2 security.properties File
# WebLogic Enterprise Security Configuration File
#
# This file contains WebLogic Enterprise Security configuration
# properties. By default, the WebLogic Enterprise Security runtime
# looks for a property file called 'security.properties' in the
# working directory.
wles.realm=myrealm
wles.default.realm=myrealm
To integrate WebLogic Enterprise Security with WebLogic Portal, you must replace the p13n_ejb.jar
file in the top-level portal application directory with the version of that file that is provided in the WebLogic Enterprise Security software distribution. The WebLogic Enterprise Security version of p13n_ejb.jar
is located in BEA_HOME/wles42-ssm/wls-ssm/lib
directory.
Note: BEA WebLogic Enterprise Security 4.2 SP2 includes two versions of p13n_ejb.jar, the WebLogic Server 8.1 SP3 version: p13n_ejb_81SP3.jar, and the SP4 version: p13n_ejb_81SP4.jar. Be sure to use the correct version.
Note: Because these instructions assume that you are using the sample portal application that ships with WebLogic Portal, this procedure instructs you to replace the p13n_ejb.jar
in the sample portal application. To use a different portal application, replace p13n_ejb.jar
in that application as well.
To replace p13n_ejb.jar
, perform the following steps:
To integrate WebLogic Enterprise Security with WebLogic Portal, you must replace the p13n_system.jar
file in the BEA_HOME/weblogic81/p13n/lib
directory with the version of that file that is provided in the WebLogic Enterprise Security software distribution. The WebLogic Enterprise Security version of this file is located in BEA_HOME/wles42-ssm/wls-ssm/lib
directory.
Note: BEA WebLogic Enterprise Security 4.2 SP2 includes two versions of p13n_system.jar
, the WebLogic Server 8.1 SP3 version: p13n_system_81SP3.jar
, and the SP4 version: p13n_system_81SP4.jar
. Be sure to use the correct version.
Note: Once you replace p13n_system.jar
in the /lib
directory of the WebLogic Platform installation, all portal domains configured for that installation must be WebLogic Enterprise Security enabled.
To replace p13n_system.jar
, perform the following steps:
WebLogic Server 8.1 uses the DefaultAuthorizerInit.ldift
file to establish access controls for J2EE resources. By default, WebLogic Server allows access to all J2EE resources to users in the Everyone
role. To protect these resources, WebLogic Server provides the Administration Console and other tools to define security policies.
When using WebLogic Enterprise Security, there is a need to supersede the WebLogic Server J2EE access controls. The DefaultAuthorizerInit.ldift
file, provided in the WebLogic Enterprise Security 4.2 SP2 for the WebLogic Server 8.1 Security Service Module, is used for this purpose.
To enable the WebLogic Enterprise Security DefaultAuthorizerInit.ldift
file to supersede WebLogic Server access controls for J2EE resources in the sample portal application, perform the following steps:
Note: Because these instructions assume that you are using the sample portal domain that ships with WebLogic Portal, this procedure instructs you to delete the ldap
directory in the portalDomain/portalServer
directory. Repeat the above steps for all WebLogic Enterprise Security enabled portal domains.
Developing a policy typically begins by determining which resources you need to protect. You then create the resources, roles and rules to define which privileges apply to each resource, and under what specific conditions. Next, you create policy rules that control which users and groups belong in these roles, and under what conditions. Later on in this section you are instructed to deploy this policy to the WebLogic Server 8.1 Security Service Module that you use to control access to your portal application resources.
WebLogic Enterprise Security provides two means for configuring portal application policy, the Administration Console and the Policy Import Tool. In this section you are directed to use the Administration Console to configure policy.
For more information on how to use the Administration Console to configure policy, see "Overview" in the Policy Managers Guide and "Policies" in the Console Help.
For instructions on how to use the Policy Import Tool to import policy files, see the Creating Policy Files section in the Policy Managers Guide.
This section covers the following topics:
This section describes how to use the Administration Console to create an identity directory, groups, and users for a portal application.
Note: This procedure uses myusers
as the name of the Identity directory; however, you can use a different name.
To create the Identity directory and users:
This section describes how to use the Administration Console to define the portal application resources that you will protect using WebLogic Enterprise Security.
To configure resources, perform the following tasks:
Note: myrealm
is used is this procedure as the realm name because the WebLogic Portal sample portal application exists in the myrealm
realm. You can choose any realm name for your portal application.
To create a realm resources, perform the following steps:
myrealm
, select Binding
from the Type drop-down list box, and click Ok. The myrealm
resource appears under the Policy node.Figure 5-2 shows the shared resources that you must create.
To create the shared
resources, perform the following steps:
jdbc
, jndi
, and svr
resources as shown in Figure 5-2, repeat steps 5 and 6 for each resource.Figure 5-3 shows the console resources that you must create.
To create the console
resources, perform the following steps:
url
, console
, login
, and bea_logo.gif
resources as shown in Figure 5-3, repeat steps 1 and 2 for each resource.Note: This procedure uses portalApp
as the name of the portal application resource because it is the name of the WebLogic Portal sample portal application. However, you should use the name of your portal application when creating the portal application resource.
Figure 5-4 shows the portalApp
resources that you must create.
Figure 5-4 PortalApp Resources
To create the portalApp
resources, perform the following steps:
ejb
and click Ok. The ejb
resource appears under the portalApp
resource.wlp
and click Ok. The wlp
resource appears under the portalApp
resource. Do not configure the wlp
resource to allow virtual resources.portalappadmin
and click Ok. The portalappadmin
resource appears under the url
.This section describes how to use the Administration Console to define portal application privileges.
To create privileges, perform the following steps:
lookup
and click Ok. The lookup
privilege appears in the list of privileges. This section describes how to use the Administration Console to create roles that will be used to control access to portal application resources.
Table 5-3 lists and describes the role policy that you have to create for the WebLogic Portal domain.
|
Creates the role policy necessary for the Everyone role to be used in the Note: If you do not create the |
To create roles and role policies, refer to Table 5-3 and perform the following steps:
Caution: If you do not create the Everyone
role policy correctly, none of the policy rules defined in Table 5-4 that use the Everyone
role will work properly.
This section describes how to use the Administration Console to create policy rules to protect portal application resources.
Table 5-4 lists and describes the policy rules that you have to create for the WebLogic Portal domain to protect the sample portal application resources.
Perform the following steps create the policy rules listed in Table 5-4.
any
privilege from the Select Privileges from Group list box and add it to the Selected Privileges box. svr
resource from the Child Resource box and add it to the Selected Resources box. Note: If Table 5-4 lists multiple resources for a single privilege and role, you may add all of the resources at once.
Visitor entitlements is a mechanism used by WebLogic Portal for determining who may access the resources in a portal application and what they may do with those resources. WebLogic Enterprise Security provides a means of defining robust role-based policy for portal resources. The resources that can be entitled within a portal application include:
Table 5-5 shows the capabilities of each of these resources:
The capabilities listed in Table 5-5 are defined as follows:
The following topics provide information on how to use WebLogic Enterprise Security to configure portal resources:
A desktop is a view of the portal that the visitor accesses. There can be one or more desktops per portal, so the portal is effectively a container for the desktops. A Desktop is referenced as a resource in WebLogic Enterprise Security in the following manner:
//app/policy/
myrealm
/
portalapp
/wlp/
sampleportal
/com_bea_p13n/Desktop/
samplePortal
myrealm
is the realm in which the portal application is installed
portalapp is the portal application directory
sampleportal
is the name of the sample portal application
samplePortal
is the label definition of the desktop.
If you define policy at the samplePortal
level, you can control access at the samplePortal
desktop level.
Table 5-6 shows a policy that would grant the view
privilege to the samplePortal
desktop for visitors in the SampleVisitor role.
A book is a collection of pages. A book is referenced as a resource in WebLogic Enterprise Security in the following manner:
//app/policy/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/Book/
book_1
where book_1
is the label definition of the book.
If you define policy at the book_1
level, you can control access at the book_1 book level.
Table 5-7 shows a policy that would grant the view
privilege to the book_1 book for visitors in the SampleVisitor role.
A page is the primary holder of individual portal elements such as portlets. A page is referenced as a resource in WebLogic Enterprise Security in the following manner:
//app/policy/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/Page/
page_2
where page_2
is the label definition of the page.
If you define policy at the page_2
level, you can control access at the page_2 page level.
Table 5-8 shows a policy that would grant the view
privilege to the page_2 page for visitors in the SampleVisitor role.
Portlets are the visible components that act as the interface to applications and content. A portlet is referenced as a resource in WebLogic Enterprise Security in the following manner:
//app/policy/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/Portlet/
portlet_login1
where portlet_login
is the label definition of the portlet.
If you define policy at the portlet_login1
level, you can control access at the portlet_login1
Portlet level.
Table 5-9 shows a policy that would grant the view
privilege to the portlet_login1
Portlet for visitors in the SampleVisitor role.
|
A Look and Feel is a selectable combination of skins and skeletons that determine the physical appearance of a portal desktop. A Look and Feel is referenced as a resource in WebLogic Enterprise Security in the following manner:
//app/policy/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/LookAndFeel/
textLookAndFeel
where textLookAndFeel
is the label definition of the Look and Feel.
If you define policy at the textLookAndFeel
level, you can control access at the textLookAndFeel
level.
Table 5-10 shows a policy that would grant the view
privilege to the textLookAndFeel
Look and Feel visitors in the SampleVisitor role.
|
Portlets have a unique instance ID that allows for granular policy definition outside the standard hierarchy of the Desktop->Book->Page->Portlet. To use this in WebLogic Enterprise Security, add a condition statement in the portlet rule that adds the portlet instance ID. For example:
grant( [//priv/maximized,//priv/minimized,//priv/view], //app/policy/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/Portlet
/ortlet_login1
, //role/Operator) if instanceid = "portlet_login1
";
Table 5-11 shows a policy that would grant the view
privilege to the portlet_login1
Portlet for visitors in the Operator role.
|
|
When developing policy for use with a Security Service Module, you can use the discovery mode feature of to WebLogic Enterprise Security Administration Application to help build your policy. Instructions for using discovery mode are provided in the Resource Discovery section in the Policy Managers Guide.
Distribute the policy and security configuration to the WebLogic Server 8.1 Security Service Module.
For information on how to distribute policy and security configuration, see "Deployment in the Administration Application Guide and the Console Help. Be sure to verify the results of your distribution.
To start a WebLogic Portal server, perform the following steps:
To use the WebLogic Authentication provider to manage administrative users for portal administration, perform the following steps:
Before you can use WebLogic Enterprise Security to control access to a portal desktop, you must use WebLogic Portal Administration Tools to create a portal desktop.
To create a portal desktops, perform the following steps:
For instructions on using Portal Administration Tools to create portal desktops, see Create a Desktop in the WebLogic Administration Portal Online Help.
To create a portal desktop for the sample portal application using the Portal Administration Tools, perform the following steps:
portaladmin
, Password: portaladmin
, and click Sign In. The Portal Resources navigation tree appears.myportal
, enter a partial URL for this Portal, for example: myportal
, and click Save. The Available Portals list appears.testportalweb/test.portal
and click Create New Desktop. Desktops contained in Portal myportal
list appear.To access a portal application running on a portal server, open a browser and point it to the desktop URL. For example, if you set up the desktop for the sample portal application as described in Using Portal Administration Tools to Create a Portal Desktop, you can access the sample portal application using the following URL:
http://<
host_name
>:7001/sampleportal/appmanager/myportal/mydesktop
where <host_name
> is the machine on which portal application is running.
![]() ![]() |
![]() |
![]() |