Integration Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Securing WebLogic Portal Applications

This section covers the following topics:

 


Overview

WebLogic Portal supports an open protection model and therefore requires a different policy model than the one used for other applications where access to a resource is denied unless a policy explicitly grants it. The following access model is enforced:

OES does not replace all of the management functionality provided by the Portal Administration Tools. For example, as shown in Figure 6-1, WebLogic Portal administrative tools are used to manage administrative users and resources associated with Portal Delegated Administration and Portal Content Management.

Figure 6-1 Portal Integration Overview

Portal Integration Overview

 


Use-Case Scenario

The following use-case scenario is supported:

 


Constraints and Limitations

Integration with WebLogic Portal has the following constraints and limitations:

 


Prerequisites

This chapter assumes the following:

 


Integration Tasks

The major tasks performed are:

  1. Define the security providers as described in Define the Security Providers.
  2. Define the Portal identities in OES as described in Define Portal Identities in OES.
  3. Define the Portal resources in OES as described in Define Portal Resources in OES.
  4. Define the policies that secure Portal resources as described in Define Policies.
  5. Distribute the policies to the SSM.

 


Define the Security Providers

Note: Providers for WebLogic 9.x/10.0 are defined using the WebLogic console. For details, “WebLogic 9.x/10.0 Security Providers” on page 3-4.

The following providers are recommended for use in securing Portal resources:

The following table provides information about each provider. For set-by-step instructions, see Configuring Security Providers in the Administration Console’s help system.

Table 6-1 Security Providers Used with Web Server SSMs
Provider
Setting
ASI Authorization
(Required) See Configuring an ASI Authorization Provider in the console’s help system for information on configuring this provider.
Any field that this provider and the ASI Role Mapping provider have in common must be set to the same value.
XACML
This is the default WebLogic authorization provider.
ASI Role Mapping
(Required) See Configuring an ASI Role Mapping Provider in the console’s help system for information on configuring this provider.
Any field that this provider and the ASI Role Mapping provider have in common must be set to the same value.
Log4 Auditor (Optional)
See Configuring a Log4j Audit Channel Provider in the console’s help system for information on configuring this provider.
ASI Adjudicator
See Configuring an ASI Adjudication Provider in the console’s help system for information on configuring this provider.
Make sure the Require Unanimous Permit checkbox is not selected.
WebLogic Authenticator
Perform the following steps:
  1. In the Portal Administration console, go to Service Administration.
  2. Select Authentication Hierarchy Service.
  3. Add WebLogicAuthenticator to the Authentication Providers to Build list.

 


Define Portal Identities in OES

Note: To implement the use-case scenario described in Use-Case Scenario, you must use identities described in this section.

To create the Identity directory and users using the OES administration console:

  1. In the left pane, select Identity and click New.
  2. On the Create Directory dialog box, enter myusers as the name and click OK. The myusers directory appears in the list of Identity directories.
  3. In the left pane, select Users and click New at the bottom of the right pane.
  4. Create the users that will visit your portal application.
  5. If you are using the WLS SSM (for WebLogic 9.x/10.0), create a user with the Admin role to access the WebLogic Server Administration Console. The default WebLogic Server Admin user and password is weblogic/weblogic.

 


Define Portal Resources in OES

When defining Portal resources in OES, keep in mind that OES does not deny access to a portal resource if it is not defined in OES and is accessible by anonymous access. In these cases, OES returns abstain, instead of true or false. This is an important difference in the way that OES makes decisions about other application resources where access is denied unless it is explicitly granted. This means that you do not have to define any resources in OES that you want to leave unprotected.

The instructions below describe how to define the resources belonging to the sample portal application to be secured by OES.

Note: To implement the use-case scenario described in Use-Case Scenario, you must use the resources described in this section.

Realm Resource

To create a realm resource, perform the following steps:

  1. Select Resources in the left pane.
  2. In the right pane, right-click policy at the top of the tree and select Add Resource.
  3. On the Create Resource dialog box enter myrealm as the realm name and select binding from the Type dropdown list. Then click Ok. The realm resource appears under the Policy node.
  4. Right-click the myrealm resource and select Configure Resource. Then select both the Distribution Point and Allow Virtual Resources checkboxes and click Ok.
  5. Return to the left pane, expand the SSM configuration containing the defined security providers, and select the ASIAuthorizer. Then open the Bindings tab in the right pane.
  6. Select //app/policy/myrealm from the dropdown list and click Bind.

Shared Resources

Figure 6-2 shows the shared resources required for securing the sample application.

Figure 6-2 Shared Resources

Shared Resources

To create the shared resources, perform the following steps:

  1. In the right pane, right-click the myrealm resource and select Add Resource.
  2. On the Create Resource dialog box, enter shared in the Name field and click Ok. The shared resource appears under myrealm.
  3. Right-click the shared resource and select Configure Resource. Then select Allow Virtual Resources and click Ok.
  4. Right-click the shared resource and click Add Resource.
  5. On the Create Resource dialog box, enter adm in the Name field and click Ok. The adm resource appears under the shared resource.
  6. Repeat steps 4 and 5 to create the jdbc, jndi, and svr resources shown in Figure 6-2.

Console Resources

Figure 6-3 shows the required console resources.

Figure 6-3 Console Resources

Console Resources

To create the console resources, perform the following steps:

  1. In the right pane, right-click the myrealm resource and select Add Resource.
  2. On the Create Resource dialog box:
    • For WebLogic Portal 9.2 or 10.0, enter consoleapp in the Name field and click Ok.
    • For WebLogic Portal 8.1, enter console in the Name field and click Ok.
  3. To create the url, console, login, and bea_logo.gif resources as shown in Figure 6-3, repeat steps 1 and 2 for each resource.
  4. Right-click the console or consoleapp resource directly under myrealm and select Configure Resource. Then select the Allow Virtual Resources checkbox and click Ok.

PortalApp Resources

Figure 6-4 shows the required resources. In addition, for WebLogic Portal 9.2, you must create these virtual resources under myrealm:

bea_wls_internal
wl_management_internal1
wl_management_internal2
pf-proliferation-jms

Figure 6-4 PortalApp Resources

PortalApp Resources

To create the portalApp resources, perform the following steps:

  1. Right-click the myrealm resource and select Add Resource.
  2. On the Create Resource dialog box, enter portalApp in the Name field and click Ok.
  3. Right-click the newly created portalApp resource and click Add Resource.
  4. On the Create Resource dialog box, enter ejb in the Name field and click Ok. The ejb resource appears under the portalApp resource.
  5. Right-click the ejb resource and select Configure Resource.
  6. On the Configure Resource dialog box, select Allow Virtual Resources and click Ok.
  7. Define the remaining resources shown in Figure 6-4.

 


Define Policies

Securing the sample application requires the authorization and role mapping policies described in this section.

Note: To implement the use-case scenario described in Use-Case Scenario, you must use the policies described in this section.

Authorization Policies

Table 6-2 describes the admin policy for the shared/svr resource and its children. To create this policy:

  1. Expand the Policy node in the left pane and click Authorization Policies under it. Then click New near the bottom of the right pane.
  2. On the Create Authorization Policy dialog box, select the Grant radio button and complete each tab as follows:
  3. Table 6-2 Authorization Policy for Shared/Svr
    Tab
    Description
    Privileges
    Select any privilege in the Select Privileges list and click Add.
    Resources
    Select shared/svr in the Child Resources list and click Add.
    Policy Subjects
    Select Admin role from the Roles List and click Add.

  4. Click OK on the Create Authorization Policy dialog box.
  5. Note: To assign multiple resources to a single privilege and role, specify all of the resources in one authorization policy.
  6. Repeat these steps to define the remaining authorization policies. These are shown in Table 6-3 below.
  7. Table 6-3 Portal Application Authorization Policies 
    Authorization Policies
    Description
    grant(any, //app/policy/myrealm/shared/svr, //role/Admin) if true;
    grant(any, //app/policy/myrealm/shared/adm, //role/Admin) if true;
    Authorization policies for booting the WebLogic Portal server and performing administrative tasks.
    grant(any, //app/policy/myrealm/portalApp/url/
    sampleportal, //role/Everyone) if true;
    grant(any, //app/policy/myrealm/portalApp/url/tutorial, //role/Everyone) if true;
    grant(any, //app/policy/myrealm/portalApp/url/welcome.jsp, //role/Everyone) if true;
    Grants permission to those in the role Everyone (includes the anonymous user) to access all of the tutorial and sample portal url resources. This authorization policy creates Portal open by default orientation for these two sample portals.
    grant(GET, //app/policy/myrealm/portalApp/url/
    portalappadmin/framework,
    //role/Everyone) if true;
    Allows unauthenticated users to access images used on the Administration Portal login page.
    grant(any, //app/policy/myrealm/portalApp/url/
    portalappadmin,
    //role/ PortalSystemAdministrator) if true;
    Grants permission for those is the role PortalSystemAdministrator to access the WebLogic Portal Administration url Portal resources
    grant(lookup, //app/policy/myrealm/shared/jndi, //role/Everyone) if true;
    Grants permission for those is the Everyone role to lookup JNDI resources.
    grant(reserve, //app/policy/myrealm/shared/jdbc, //role/Everyone) if true;
    Grants permission for those is the Everyone role to reserve JDBC resources.
    grant(any, //app/policy/myrealm/console, //role/Admin) if true;
    Grants permission for those in the Admin role to access the url resources of the WebLogic Server console.
    grant(GET, //app/policy/myrealm/console/url/console/login/bea_logo.gif, //role/Everyone) if true;
    Grants permission for those in the Everyone role to get access to the bea_logo.gif image resource in the WebLogic Server console
    grant(any, //app/policy/myrealm/portalApp/ejb, //role/Everyone)
    Initially allows access to all EJB methods.

Role Mapping Policies

Caution: If this policy is not created exactly as described, the authorization policies defined in Table 6-3 and Table 6-4 that use the Everyone role will not work properly.

Follow these steps to define a role mapping policy that allows the Everyone role to be used in the myrealm Identity directory.

  1. Select Role Mapping Policies under the Policies node and click New at the bottom of the right pane.
  2. Select the Grant radio button and complete the tabs as follows:
  3. Tab
    Description
    Roles
    Select Everyone and click Add.
    Resources
    Select myrealm and click Add.
    Policy Subjects
    Select allusers role and click Add.

The policy definition is as follows:

\grant(//role/Everyone, //app/policy/myrealm, //sgrp/myusers/allusers/) if true;

Policies for Visitor Entitlements

WebLogic Portal uses visitor entitlements to determine who may access portal application resources and what they may do with those resources. OES provides a means of defining role-based policy for portal resources. The resources that can be entitled within a portal application include:

Table 6-4 shows the capabilities of each of these resources:

Table 6-4 Capabilities According to Resource Type 
Resource Type
View
Minimize
Maximize
Edit
Remove
Desktop
x
       
Book
x
x
x
   
Page
x
       
Portlet
x
x
x
x
x
Look & Feel
x
       

The capabilities listed in Table 6-4 are defined as follows:

Policies for Desktops

Because there can be one or more desktops per portal, the portal is effectively a container for the desktops. A desktop is referenced as a resource in OES in the following manner:

//app/policy/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/Desktop/<samplePortal>

where <samplePortal> is the label definition of the desktop.

Authorization policies specifying the samplePortal resource will control access at the samplePortal desktop level. Table 6-5 shows an authorization policy that allows visitors in the SampleVisitor role to view the samplePortal desktop.

Table 6-5 SamplePortal Authorization Policy
Effect
Privilege
Resource
Policy Subject
Grant
view
/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/Desktop/samplePortal
SampleVisitor role

Policies for Books

A book is referenced as a resource in OES 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.

Authorization policies specifying the book_1 resource will control access at the book_1 book level. Table 6-6 shows an authorization policy that allows the SampleVisitor role to view to book_1.

Table 6-6 Book_1 Authorization Policy
Effect
Privilege
Resource
Policy Subject
Grant
view
/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/Book/book_1
SampleVisitor role

Policies for Pages

A page is the primary holder of individual portal elements such as portlets. A page is referenced as a resource in OES in the following manner:

//app/policy/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/Page/<page>

where <page> is the label definition of the page.

Authorization policies specifying the page_2 resource will control access at the page_2 page level. Table 6-7 shows an authorization policy that allows visitors in the SampleVisitor role to view page_2.

Table 6-7 Page_2 Authorization Policy
Effect
Privilege
Resource
Policy Subject
Grant
view
/myrealm/portalapp/wlp/sampleportal/
com_bea_p13n/Page/page_2
SampleVisitor role

Policies for Portlets

Portlets are the visible components that act as the interface to applications and content. A portlet is referenced as a resource in OES in the following manner:

//app/policy/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/Portlet/<portlet_login>

where <portlet_login> is the label definition of the portlet. (The WebLogic Portal name is portlet_login_1. This name is mapped to portlet_login by the WebLogic Portal Resource Converter.)

Authorization policies specifying the portlet_login resource will control access at the portlet_login_1 portlet level. Table 6-8 shows an authorization policy that allows visitors in the SampleVisitor role to view the portlet_login_1 portlet.

Table 6-8 Portlet_login_1 Authorization Policy
Effect
Privilege
Resource
Policy Subject
Grant
view
/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/Portlet/portlet_login
SampleVisitor role

View Access to com_bea_p13n

Unless a policy grants the View privilege to the com_bea_p13n resource, authorization errors will occur when a portlet is accessed. Due to inheritance, assigning this privilege to com_bea_p13n also assigns it to its child resources. If this is not appropriate for the application, define a policy that restricts this inheritance. For example, the following policy prevents the inheritance of the View privilege to child resources of com_bea_p13n:

GRANT(
//priv/view,
//app/policy/someRoot/portalear/wlp/someportal/com_bea_p13n,
//sgrp/Everyone/
) IF sys_obj_q = //app/policy/someRoot/portalear/wlp/someportal/com_bea_p13n;

Policies for Look and Feel

A Look and Feel is a selectable combination of skins and skeletons that determine the physical appearance of a portal desktop. It is referenced as a resource in OES in the following manner:

//app/policy/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/LookAndFeel/<label>

where <label> is the label definition of the Look and Feel.

If you define an authorization policy at the textLookAndFeellevel, you can control access at the textLookAndFeel level. Table 6-9 shows an authorization policy that allows the SampleVisitor role to view textLookAndFeel resource.

Table 6-9 textLookAndFeel Look and Feel Authorization Policy
Effect
Privilege
Resource
Subject
Grant
view
/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/LookAndFeel/textLookAndFeel
SampleVisitor role

Policies for Portlets using Instance ID

Portlets have a unique instance ID that allows for granular authorization policy definition outside the standard hierarchy of the Desktop>Book>Page>Portlet. To use this in OES, 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
/portlet_login, //role/Operator) if instanceid = "portlet_login";

Table 6-10 shows an authorization policy that allows visitors in the Operator role to view the portlet_login_1 portlet.

Table 6-10 Portlet_login_1 Authorization Policy Using Instance ID
Effect
Privilege
Resource
Subject
Condition
Grant
view
/myrealm/portalapp/wlp/sampleportal/com_bea_p13n/Portlet/portlet_login
Operator role
if instanceid = "portlet_login";


  Back to Top       Previous  Next