This section covers the following topics:
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. When integrated with ALES, the following access model is enforced:
ALES 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.
The following use-case scenario is supported when you integrate ALES with WebLogic Portal:
When integrated with ALES, WebLogic Portal has the following constraints and limitations:
ALES 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.
This chapter assumes the following:
Note: | For information about installing and configuring the SSM, see the SSM Installation and Configuration Guide. |
The major tasks performed are:
Note: | Providers for WebLogic 9.x/10.0 are defined using the WebLogic console. For details, Define Security Providers for WebLogic 9.x/10.0. |
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.
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 ALES administration console:
myusers
as the name and click OK. The myusers
directory appears in the list of Identity directories.
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
.
When defining Portal resources in ALES, keep in mind that ALES does not deny access to a portal resource if it is not defined in ALES and is accessible by anonymous access. In these cases, ALES returns abstain, instead of true or false. This is an important difference in the way that ALES 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 ALES 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 ALES.
Note: | To implement the use-case scenario described in Use-Case Scenario, you must use the resources described in this section. |
To create a realm resource, perform the following steps:
policy
at the top of the tree and select Add Resource.myrealm
as the realm name and select binding
from the Type dropdown list. Then click Ok. The realm resource appears under the Policy node.myrealm
resource and select Configure Resource. Then select both the Distribution Point and Allow Virtual Resources checkboxes and click Ok.//app/policy/myrealm
from the dropdown list and click Bind.Figure 6-2 shows the shared resources required for securing the sample application.
To create the shared
resources, perform the following steps:
myrealm
resource and select Add Resource.shared
in the Name field and click Ok. The shared
resource appears under myrealm
.shared
resource and select Configure Resource. Then select Allow Virtual Resources and click Ok.shared
resource and click Add Resource.adm
in the Name field and click Ok. The adm
resource appears under the shared
resource.jdbc
, jndi
, and svr
resources shown in Figure 6-2.Figure 6-3 shows the required console resources.
To create the console
resources, perform the following steps:
myrealm
resource and select Add Resource. url
, console
, login
, and bea_logo.gif
resources as shown in Figure 6-3, repeat steps 1 and 2 for each resource.console
or consoleapp
resource directly under myrealm
and select Configure Resource. Then select the Allow Virtual Resources checkbox and click Ok.
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
To create the portalApp
resources, perform the following steps:
myrealm
resource and select Add Resource. portalApp
in the Name field and click Ok. portalApp
resource and click Add Resource. ejb
in the Name field and click Ok. The ejb
resource appears under the portalApp
resource.ejb
resource and select Configure Resource.
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. |
Table 6-2 describes the admin policy for the shared/svr
resource and its children. To create this policy:
Note: | To assign multiple resources to a single privilege and role, specify all of the resources in one authorization policy. |
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.
The policy definition is as follows:
\grant(//role/Everyone, //app/policy/myrealm, //sgrp/myusers/allusers/) if true;
WebLogic Portal uses visitor entitlements to determine who may access portal application resources and what they may do with those resources. ALES 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:
The capabilities listed in Table 6-4 are defined as follows:
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 ALES 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.
A book is referenced as a resource in ALES 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
.
A page is the primary holder of individual portal elements such as portlets. A page is referenced as a resource in ALES 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
.
Portlets are the visible components that act as the interface to applications and content. A portlet is referenced as a resource in ALES 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.
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;
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 ALES 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 textLookAndFeel
level, you can control access at the textLookAndFeel
level. Table 6-9 shows an authorization policy that allows the SampleVisitor
role to view textLookAndFeel
resource.
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 ALES, 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.