|
Oracle® Application Server Portal User's Guide
10g Release 2 (10.1.4) B13809-04 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal User's Guide
10g Release 2 (10.1.4) B13809-04 |
|
|
Previous |
Next |
OracleAS Portal uses privileges to control access to portal objects, such as pages, tabs, items, templates, and styles. Administrators can delegate the assignment of privileges to other users and groups. Privilege assignments enable users and groups to access, personalize, or modify the object. Administrators can also grant global privileges on all objects of a given type.
Figure 18-1 Set Access Rules to Protect Content
This chapter contains information on how to use privileges to control who may view and interact with objects in your portal. It includes the following sections:
Intended Audience
This chapter is intended for users who want to understand how security operates within OracleAS Portal. The privilege required to perform the actions discussed in this chapter vary according to the type of action. Each section provides information about required privileges. For more information about privileges, see Appendix B, "Page Group Object Privileges".
OracleAS Portal provides privilege levels to allow increasing degrees of protection for your data. To determine a user or group's access to an object, OracleAS Portal synthesizes the answers to the following questions:
Has the user or group been granted an explicit privilege on the object?
Has the user or group been granted a global privilege on the object type?
Does the user or group belong to a special group created by OracleAS Portal?
This section explores the underlying meaning of these questions.
Is the object public, or is it restricted to certain users?
All objects in OracleAS Portal are either public or restricted. Restrictions are controlled by an access list. Anyone can see a public object—even users who do not log on. When an object is restricted by an access list, only users on the list can see the object. The access list states the extent to which specified users and groups can interact with the object. The list is created through the granting of privileges to users and groups.
You can explicitly make pages and tabs available to public users (on the Access tab of page or tab properties). By extension, a public page or tab's content is also public.
Has the user or group been granted an explicit privilege on the object?
If an object is not public, it is controlled by an access list. The object's creator—or a user with the Manage privilege on the object—uses this list to explicitly grant privileges to other users and groups.
Different levels of privilege allow for greater or lesser levels of access. For example, one group might be able to see the object, but not change it. Another group might be able to add, edit, hide, or delete the object.
When an access privilege on an object is granted to a group, all group members have the same level of access to the object. That is, you cannot grant access to most members of a group, excluding one or two members.
You can grant a greater level of privilege to a user who is also a member of a group. For example, the group Accounting has the View privilege on a page. The user Jane Doe, who is also a member of the Accounting group, can be granted additional privileges (as an individual user), such as Manage Content.
Has the user or group been granted a global privilege on the object type?
A global privilege applies to all objects of a given type. For example, if you have the global privilege Manage on the object type All Styles, you can create, edit, or delete any style in OracleAS Portal, no matter which page group owns the style. Apply global privileges to both users and groups.
Use global privileges as a means of implicitly granting access to an object. Compare this to the object's access list, through which privileges are explicitly granted.
Does the user or group belong to a special group created by OracleAS Portal?
When your user account is created, the portal administrator decides if you are allowed to log on. If you can log on, you are an authenticated user. If you cannot log on, you are a public user. Users who can log on belong to the Authenticated Users group, one of the default groups provided with OracleAS Portal out of the box. The Authenticated Users group has the Create global privilege on the object types All Pages and All Styles.
Users with the global privilege Create on the object type All Pages can create sub-pages in any page group provided they also have the page privilege Manage on the parent page under which sub-pages will be created.
Users with the global privilege Create on the object type All Styles can create styles in any page group on which they also have the page group privilege Manage Styles.
Each of the default groups provided by OracleAS Portal is granted its own set of global privileges. For more information, see Oracle Application Server Portal Configuration Guide.
In a large enterprise, the portal administrator should consider delegating the power to assign privileges. The range of privileges extends from portal-wide to item-specific. A lone portal administrator handling all privilege assignments could easily be overwhelmed by access requests.
Typically, a privilege that provides total control over an object—from a page group to an item—also provides the power to assign equal or subordinate access privileges to other users. For example, a page group administrator—that is, a user with the page group privilege Manage All on a page group—can assign the page privilege Manage to users and groups. Among other things, this privilege enables users to create sub-pages under the page on which they have the privilege. A user with the page privilege Manage can enable item level security and assign item-level access privileges.
Table 18-1 lists the privileges that include the power of privilege assignment and the types of privileges that can be assigned.
Table 18-1 Privileges that Include the Assignment of Privileges
For a list and description of all privileges, from page groups to items, see Appendix B, "Page Group Object Privileges".
Users or groups who create page groups must have at least the global privilege Create on the object type All Page Groups. Portal administrators are usually the ones to grant such high-level privileges.
Use global privileges to grant a user or group a certain level of privileges on all objects of a particular type, on portal database providers, and on tasks pertaining to portal administration.
|
Note: Global privileges confer a great deal of power on the user or group to whom they are granted. As a result, such privileges should be granted very cautiously and only to users or groups who truly require them. There should be only a small number of users with global privileges. |
Grant global privileges to users in the Portal User Profile portlet. Grant global privileges to groups in the Portal Group Profile portlet. In a default installation of OracleAS Portal, both of these portlets are located on the Portal sub-tab of the Administer tab of the Portal Builder page.
This section describes how to assign global privileges to a user or a group. It contains the following sub-sections:
To grant global privileges to a user:
Log in to OracleAS Portal.
Click the Administer tab to bring it forward.
Click the Portal sub-tab.
In the Name field of the Portal User Profile portlet, enter the name of the user to whom to grant global privileges.
Optionally, click the Browse Users icon to select a user from a list.
By default, the Portal User Profile portlet is located on the Portal sub-tab of the Administer tab on the Portal Builder page. If you do not find it there, speak to the person who installed your portal.
|
Note: The Portal User Profile portlet is visible only to users with global privilege Manage or Edit on the object type All User Profiles. |
Click the Edit button.
Click the Privileges tab to bring it forward.
Grant privileges relating to page groups, portal database providers, and portal administration.
Users or groups who create page groups must have at least the global privilege Create on the object type All Page Groups.
Click Apply to save your changes and remain on the Privileges tab, or click OK to save your changes and return to the Portal User Profile portlet.
For more information about global privileges, see Oracle Application Server Portal Configuration Guide.
To grant global privileges to a user:
Log in to OracleAS Portal.
Click the Administer tab to bring it forward.
Click the Portal sub-tab.
In the Name field of the Portal Group Profile portlet, enter the name of the group to whom to grant global privileges.
Optionally, click the Browse Groups icon to select a group from a list.
By default, the Portal Group Profile portlet is located on the Portal sub-tab of the Administer tab on the Portal Builder page. If you do not find it there, speak to the person who installed your portal.
|
Note: The Portal Group Profile portlet is displayed to all users, but only the owner of a group or users with the global privilege Manage or Edit on the object type All Group Profiles can edit a group profile. |
Click the Edit button.
Click the Privileges tab to bring it forward.
Grant privileges relating to page groups, portal database providers, and portal administration.
Users or groups who create page groups must have at least the global privilege Create on the object type All Page Groups.
Click Apply to save your changes and remain on the Privileges tab, or click OK to save your changes and return to the Portal Group Profile portlet.
For more information on global privileges, see Oracle Application Server Portal Configuration Guide.
Page group privileges are granted on the Access tab of page group properties.
To grant privileges on a page group:
Log in to OracleAS Portal.
Click the Build tab to bring it forward.
From the Page Groups portlet Work In drop-down list, select the page group on which to grant privileges.
Click the Configure link.
On the resulting page, click the Access tab to bring it forward.
In the Grantee field, enter the name of a user or group.
Optionally, click the Browse Users or Browse Groups icon to select a user or group from a list.
Select a privilege from the drop-down list. Choose from:
Manage All
Manage Classifications
Manage Templates
Manage Styles
View
These privileges are described in detail in Appendix B, "Page Group Object Privileges".
Though you cannot select multiple privileges to grant at one time, after you click Add, you can repeat the process, select the same user or group, and grant another privilege. In this way, you can grant a general privilege, such as View, to a group, then a higher-level privilege, such as Manage All, to a user who is also a member of the group.
Click Add.
The assignment displays in the Change Access section, where you can revise the grant to a greater or lesser privilege level, or remove the grant entirely.
|
Note: When you change access privileges, click the Clear Cache link at the bottom of the Access tab to make such changes take effect immediately. |
When you want users to have privileges on pages, it sometimes takes more than granting a specific privilege. For example, users may have the page privilege Manage Style, but they cannot apply styles to pages unless the page group option Allow Privileged Users To Manage Page Style is also selected.
This section guides you through the process of granting privileges on pages. It includes the following sub-sections:
By making a page public, you allow all users to view your page, even users who are not logged on. Users who are not logged on are called public users. If you do not make your page available to everyone, only users with the page privilege View or higher are able to view the page.
Making a page available to public users enables public as well as privileged users to view the page. If you want to enable users and groups to manage, personalize, or add content to the page, you must grant them additional privileges.
To make a page available to everyone:
Log in to OracleAS Portal.
Go to the page to be made public.
For information on locating a page, see Section 9.1, "Locating Pages in OracleAS Portal".
Switch to Edit mode.
Click the Page: Properties link in the page toolbar.
Click the Access tab to bring it forward.
Select Display Page To Public Users.
For this option to display, page access must be set to Specify Access Settings. If page access is set to Inherit Access Settings from Page <page_group_name>, you do not see the option Display Page To Public Users.
|
Note: Any page with the option Display Page To Public Users enabled becomes a crawlable data source for Oracle Ultra Search. See also Oracle Application Server Portal Configuration Guide. |
Click OK to save your change and return to the page.
Changing the access settings of a Portal Template affects all pages that are based on that template, unless the template allows different access settings. This means that when you set access on a Portal Template for pages to public, all pages based on the template are public, unless the template allows the pages based on it to have their own access settings. The control for allowing different access settings for pages that are based on a template is on the Access tab of the template's Properties page: Enable Pages To Have Different Access.
You can specify who has access to a page and how much access they have. Access privileges work incrementally, starting at the global privilege level. For example, you can grant the global privilege View on the object type All Pages to group A, then explicitly grant the Manage privilege on a particular page to user A3. All members of group A can see the page, but the only group A member who can do everything else to the page is user A3.
With respect to page access and personalization, it may help to consider two versions of a page: an individual user's version, and the version displayed to all users with access. If you manage the page, you control the extent to which other users can personalize the page: whether they can modify the display version, their own private version, or nothing at all.
If a page is based on a template, page managers may not be able to control the access and style of the page. There are two options at the template level that control whether page designers can specify different style and access settings for pages based on the template: Enable Pages To Have Different Access and Enable Pages To Use Different Style. These must be selected; otherwise, the page access and style settings cannot be changed.
To control access to a page:
Log in to OracleAS Portal.
Go to the page where you will control access.
For information on locating a page, see Section 9.1, "Locating Pages in OracleAS Portal".
Switch to Edit mode.
Click the Page: Properties link in the page toolbar.
Click the Access tab to bring it forward.
Select Enable Item Level Security to allow item creators to specify access control for individual items in the page.
If you select this check box, item creators have the choice of inheriting access control from the page, or specifying access control for individual items.
If you do not select this check box, all the items on the page inherit access control from the page.
This option is available only if the page is a Standard page, or is a custom page that is based on the Standard page type.
For more information, see Section 18.9.1.1, "Understanding Item Level Security"
To explicitly grant privileges to users or groups:
In the Grantee field, enter the name of the user or group to whom to grant page access.
Optionally, click the Users or Groups icon, and select from the list provided.
|
Note: OracleAS Portal uses the Oracle Internet Directory for identity management, serving as the repository for users and groups. In the Oracle Internet Directory, groups are uniquely identified by their distinguished name (DN). Each group has a unique DN, though many groups can share a common name, in the same way that two people can share a common name, yet have completely different lineage (for example, John Smith and John Doe). When working within the portal, groups created from within that portal are displayed simply with their common names. However, when the portal references a group from some other location in the Oracle Internet Directory—such as a group from some other portal associated with the same Identity Management Infrastructure—the DN of the group is displayed to distinguish it from the portal's locally defined groups. |
Choose a privilege level from the list.
|
Note: For a list and description of page privileges, see Appendix B, "Page Group Object Privileges". The order of the list of privileges is irrelevant. Privileges higher on the list are not necessarily more or less powerful. |
Click Add.
Though you cannot select multiple privileges to grant at one time, after you click Add, you can repeat the process, select the same user or group, and grant another privilege. In this way, you can grant a general privilege, such as View, to a group, then a higher-level privilege, such as Manage All, to a user who is also a member of the group.
To clear all the Web Cache entries for the page, click Clear Cache.
The next time the page is requested, it is retrieved from the database, not the cache.
For example, if you revoke a user's privileges on the page, the user will still be able to access the page if it is in the cache. If you want to make sure that your changes are applied immediately, clear the page from the cache by clicking this link.
Click OK to save your changes and return to the Page.
Use the Privilege list under Change Access to change a user or group's privilege level. Click the Delete icon to remove the user's or group's privileges entirely.
Changing the access settings of a Portal Template affects all pages that are based on that template, unless the template allows page designers to use different access settings for the pages that are based on it. The control to allow pages to have different access is on the Access tab of the template's Properties page: Enable Pages To Have Different Access.
The option you select for page, portlet, or template caching can have security implications. Any option that includes caching at the system level retrieves the same data from a single cache source for all users. For this reason, everything on the page (that is not hidden) is displayed to all users who are authorized to view the page. This includes links normally viewed only by users authorized to view the link. However, users can still perform only those actions for which they have the appropriate access privileges. When they click a link to a page, tab, item, or task which they are not authorized to view or to execute, they see an error message and cannot open the link's target or execute the link's action.
Portlets with content that is not generally public that are cached at the system level may not display. For example, objects in the Page Groups portlet typically display according to the privilege-level of the user viewing the portlet. If you did not create a page group and you have no privileges on it, you likely will not see it displayed in the Page Groups portlet. Such objects are not "public." If you cache the Page Groups portlet at the system level, your users are unlikely to see it when the portlet's container page is rendered.
To prevent exposing the access point of sensitive data to unprivileged users, and to avoid the display of portlets without content, consider selecting a page or template caching option that does not include caching at the system level.
This will have performance implications for the speed at which pages are rendered. If you place a high value on performance, consider instead placing such sensitive content on a page with limited access, rather than including sensitive, secure content with more widely accessible content.
For a description of caching options for templates, pages, and portlet instances, see Chapter 22, "Improving Page Performance".
You can secure a tab by granting privileges on it or by locking its regions. Region locking is described in Section 18.8, "Locking Regions". To grant privileges on a tab, you must have at least the tab privilege Manage on the tab. Use tab privileges to control who can access a tab, add content to it, manage the style that is applied to it, or personalize their own view of the tab.
Use tab access privileges to grant a greater level of access to a tab than users or groups may have on the page that hosts the tab. For example, a user may have the page privilege View on a page but the tab privilege Manage on a tab on the page. The user can merely view the page, but can add content, grant access, and perform any other management task on the tab.
To grant privileges on a tab:
Log in to OracleAS Portal.
Go to the page that contains the tab on which to grant access privileges.
For information on how to locate a page, see Section 9.1, "Locating Pages in OracleAS Portal".
Switch to Edit mode.
Click the Edit Tab icon on the tab on which to grant access privileges (Figure 18-2).
Be sure to click the Edit Tab icon on the tab flap and not the one beside the flap.
Click the Access tab to bring it forward.
Under Access Setting, select a means of specifying tab access; choose from:
Inherit Access Settings from the Template—This option displays when the page hosting the tab is based on a template. This selection assigns the tab the same access privileges as are granted on the tab on the template on which this page is based.
If you select this option, go to step 13.
Inherit Access Settings from Page <Page Name>—This selection assigns the tab the same access privileges as are specified for the tab's parent page or a sub-tab's parent (main) tab.
If you select this option, go to step 13.
Specify Access Settings—This selection enables you to specify access settings for the tab. When you select this option, the Access Properties and Grant Access sections display on this page. If these sections do not automatically appear, click Apply.
The rest of this procedure describes the steps you take when you select Specify Access Settings.
Select or clear the Display Tab to Public Users check box.
Select to allow all users, even those who are not logged in, to view this tab.
Clear to limit the display of this tab to authenticated users.
Select or clear the Enable Item Level Security check box.
Select to enable privileged users to define access privileges on individual items on this tab. When item level security is enabled, a user must have at least the item privilege View on the item in order to view it.
Clear to prevent the setting of access privileges on items on this tab.
Under Grant Access, click the Browse Users or Browse Groups icon to select a user or group on whom to grant access privileges on the tab.
|
Note: OracleAS Portal uses the Oracle Internet Directory for identity management, serving as the repository for users and groups. In the Oracle Internet Directory, groups are uniquely identified by their distinguished name (DN). Each group has a unique DN, though many groups can share a common name, in the same way that two people can share a common name, yet have completely different lineage (for example, John Smith and John Doe). When working within the portal, groups created from within that portal are displayed simply with their common names. However, when the portal references a group from some other location in the Oracle Internet Directory—such as a group from some other portal associated with the same Identity Management Infrastructure—the DN of the group is displayed to distinguish it from the portal's locally defined groups. |
Select a privilege from the associated drop-down list.
Choose from:
Manage
Manage Content
Manage Style
Manage Items With Approval
Approvals and notifications must be enabled for the page's page group for the page privilege Manage Items With Approval to display. For more information, see Section 6.4, "Setting Up Approvals".
Personalize Portlets (Full)
Personalize Portlets (Add-Only)
Personalize Portlets (Hide-Show)
Personalize (Style)
View
All of these privileges are explained in detail in Appendix B, "Page Group Object Privileges".
Click Add after defining each user or group's privilege.
Though you cannot select multiple privileges to grant at one time, after you click Add, you can repeat the process, select the same user or group, and grant another privilege. In this way, you can grant a general privilege, such as View, to a group, then a higher-level privilege, such as Manage All, to a user who is also a member of the group.
Once you have granted privileges, click the Clear Cache link.
This will clear away any obsolete privileges on this tab that linger in the cache.
Click OK to save your changes and return to the page.
Portlet security consists of three major areas of functionality:
Authentication
When users first access a secure URL, they must be challenged for information that verifies their identity, such as a user name and password, or a digital certificate.
Authorization
Authorization is the process that allows certain users to access parts of an application. Some parts of an application may have public access while others may be accessible only to a limited number of authenticated users.
Communication Security
Communication security is the means by which OracleAS Portal establishes the authenticity of communications (for example, messages) to and from portlet providers. In a heavily networked environment, it is critical to verify that communications are authenticated.
This section explores portlet security related to authorization. It contains the following subsections:
You will find a more in-depth discussion of portlet security, including Authentication, Authorization, and Communication Security, in Oracle Application Server Portal Configuration Guide.
The procedure for granting global privileges to a user is outlined in Section 18.3.1, "Granting Global Privileges to a User". The procedure for granting global privileges to a group is outlined in Section 18.3.2, "Granting Global Privileges to a Group". This section lists and describes the global privileges relating to portlets. It includes the following subsections:
|
Note: Global privileges confer a great deal of power on the user or group to whom they are granted. As a result, such privileges should be granted very cautiously and only to users or groups who truly require them. There should be only a small number of users with global privileges. |
The portlet-related global privileges that apply to all portlets include:
Execute—Execute any portlet in any provider. Users and groups with this privilege can see all portlets, even when portlet security is enforced. The Show link appears in the Portal Navigator for all portlets. To view portlets through the Portal Navigator, drill down through the providers listed under the Providers tab.
Publish—Publish any page portlet, navigation page, or Portal DB provider portlet to the portal. Publishing a portlet makes it available for adding to pages.
The portlet-related global privileges that apply to providers of portlets include:
Manage—Register, edit, and de-register any provider, as well as display and refresh the Portlet Repository. Users and groups with this privilege are also allowed to grant edit privileges on any provider.
Create—Create portlet providers. Users and groups have the Manage privilege on any provider they create. This means they can perform all manage operations (such as edit and de-register) on any provider they create.
The portlet-related global privileges on all Portal DB providers include:
Manage—Edit, delete, or export any Portal DB provider. Create, edit, delete, or export any portlet in any Portal DB provider. Grant access to any Portal DB provider and any portlet in any Portal DB provider.
Edit Contents—Edit or export any portlet in any Portal DB provider.
View Source—View the PL/SQL package specification and body and run any portlet in any Portal DB provider. This privilege is intended primarily for users or groups who may want to look at a portlet's source to understand how to call it.
Personalize—Personalize any portlet from any Portal DB provider.
Run—Run any portlet in any Portal DB provider.
Create—Create Portal DB providers. Users and groups with this privilege can edit, delete, and export the providers they create, and they can create, edit, delete, and export any portlet in any provider.
Many personalization privileges can be granted on portlets at the global level, the page level, and the tab level. When personalization privileges are granted at the global level, users with such privileges can use them on every portlet in the portal. When personalization privileges are granted at the page level, users with such privileges can use them on every portlet on the page. When personalization privileges are granted at the tab level, users with such privileges can use them on every portlet on the tab, though not on other portlets on the page that contains the tab.
In most cases, personalizations affect only the view of the user who makes them. A portlet must be edited, rather than personalized, before changes display to all users viewing the portlet.
An exception to this is when the portlet instance is shared. Provided users have sufficient privileges to edit a page, they can share a portlet instance to make their view of a portlet, along with all of its personalizations, available to other users. Shared portlet instances are available for selection under the Shared Portlets page in the Portlet Repository. The sharing option is available on pages, though not on pages that are based on Portal Templates. For more information, see Section 16.7, "Sharing a Portlet Across Multiple Pages".
Granting global access privileges on a portal is discussed in Section 18.3, "Granting Global Privileges". Granting access privileges on a page is discussed in Section 18.5, "Securing Pages". Granting access privileges on a tab is discussed in Section 18.6, "Securing Tabs". This section lists and describes portlet-related access privileges for the portal, for pages, and for tabs.
Global-, page-, and tab-related privileges pertaining to portlet personalizations include:
The global privilege Personalize on the object type All Portal DB providers
Users with this privilege can personalize their view of any portlet in the portal.
The page or tab privilege Personalize Portlets (Full)
Users with this privilege can alter their view of the page by adding portlets to the page, and deleting, moving, hiding, or showing any portlet on the page. Additionally, such users can change the style applied to their view of the page. Personalization changes are visible only to the user who makes them. For example, if a user with this privilege deletes a portlet from a page, the portlet will nonetheless continue to display on other users' views of the page. Likewise, if a user with this privilege adds a portlet to a page, only that user sees the portlet; it does not display when other users view the page.
For users with this privilege to change the style applied to their view of a page, the option Allow Privileged Users To Personalize Page Style must be selected for the page group. This option is available on the Main tab of page group properties.
The page or tab privilege Personalize Portlets (Add-Only)
Users with this privilege can alter their view of the page by adding portlets to the page, and removing, hiding, or showing the portlets that they add. Additionally, such users can change the style applied to their view of the page.
For users with this privilege to change the style applied to their view of a page, the option Allow Privileged Users To Personalize Page Style must also be selected for the page group. This option is available on the Main tab of page group properties.
The page or tab privilege Personalize Portlets (Hide-Show)
Users with this privilege can alter their view of the page by hiding, showing, or rearranging any portlet on the page. Additionally, such users can change the style applied to their view of the page. These changes are visible only to the user who made them. For example, if a user with this privilege hides a portlet on a page, that portlet is hidden only for that user; other users still see the portlet.
For users with this privilege to change the style applied to their view of a page, the option Allow Privileged Users To Personalize Page Style must also be selected for the page group. This option is available on the Main tab of page group properties.
Region locking is a way to limit the types of actions users can perform on a region. This section describes the effect of locking a region and how to lock page regions and Portal Template regions. It contains the following subsections:
Once you lock a page region, when users personalize the page they cannot add content to the region or hide, show, delete, or move existing content. When users edit the page, they can still add, hide, show, delete, and move content.
To lock a page region:
Log in to OracleAS Portal.
Click the Build tab to bring it forward.
From the Page Groups portlet Work In drop-down list, select the page group that owns the relevant page.
By default, the Page Groups portlet is located on the Build tab of the Portal Builder page.
Under Pages in the Layout & Appearance section, click the link to the page on which to lock a region.
This opens the page in Edit mode.
Click the Edit Region icon in the region to be locked (Figure 18-3).
On the resulting page, go to the Region Content section, and clear the check box Enable Users To Include Content In This Region.
Click OK to save your changes and return to the page.
When you lock a Portal Template region, no user can change the region content on pages that are based on the template (except through WebDAV; see note). When users edit or personalize a page that is based on a template with locked regions, they will not be able to add content to the region, or hide, show, delete, or move existing content.
To lock a Portal Template region:
Log in to OracleAS Portal.
Click the Build tab to bring it forward.
From the Page Groups portlet Work In drop-down list, select the page group that owns the relevant Portal Template
By default, the Page Groups portlet is located on the Build tab of the Portal Builder page.
Under Portal Templates in the Layout & Appearance section, click the link to the relevant template.
This opens the template in Edit mode.
Click the Edit Region icon in the region to be locked (Figure 18-4).
On the resulting page, go to the Region Content section, and clear the check box Enable Users To Include Content In This Region.
Click OK to save your changes and return to the Portal Template.
OracleAS Portal provides two powerful features for securing items: item level security and approvals. Item level security enables you to shield an item from unprivileged users or to grant higher access privileges on an item than might otherwise be granted on the page or tab that contains the item. Approvals enable you to structure an approval process through which new and revised content must pass before it can be published to your portal.
This section describes item level security and approvals and provides pointers on how to use these features. Additionally, it provides a table that outlines item URL access rules for items in various states, such as Draft, Pending, Unpublished, and so on. It contains the following subsections:
|
Note: To enable item level security, you must have at least the page or tab privilege Manage on the page or tab that contains the item. |
Item level security provides a means of:
Preventing unprivileged users from seeing an item
For example, when item level security is enabled and a user has the page privilege View but no item privileges, the user can view the page but not its items.
Granting a higher level of privilege on the item than is granted on the page
For example, if a user has the page privilege View on a page, but the item privilege Manage on an item on the page, the user can enter page edit mode and perform content management tasks on that specific item. Such a user cannot perform any other editing tasks on the page.
Item level security can be applied to items placed on pages, tabs, and pages that are based on a Portal Template; though it cannot be applied (successfully) to items that are part of the template itself—even when item level security is turned on for the template and the user has privileges on the item.
The following sections further define item level security and describe how to enable it on a page or a tab. It includes the following subsections:
By default, items inherit the access settings that apply to the page or tab that contains the item. Only users or groups who are authorized to access a given page or tab can access its items. When you enable item level security for a page or tab, items initially use the same security settings that are applied to the page or tab. But, using item level security capabilities, you can now grant a higher level of access on individual items.
When item level security is enabled, users with no privileges on the item cannot see the item.
The page privileges Manage and Manage Content override item level security privileges. This means that if you grant the item privilege View to a user who also has the page privilege Manage Content, the user can do anything to the item, more than just viewing it. However, item level security takes precedence over other page-level privileges.
For example, if a user has the page privilege Manage Style on a page, and the item privilege Manage on an item, the user can delete the item from the page, and is not limited to merely changing the page's style.
Item level security can be enabled only on Standard pages and custom pages that are based on the Standard page type.
|
Note: There is no relationship between item level security and item versioning. Item level security has to do with who can access an item, and item versioning has to do with how older versions of an item are handled as newer versions are uploaded. For more information on item versioning, see Section 15.12, "Using Item Version Control".Changes to the access settings of a Portal Template affect all pages that are based on the template, unless the template specifically allows the pages that are based on it to use different access settings. The option to allow pages based on templates to define their own access is located on the Access tab of Portal Template properties. |
To enable item level security on a page:
Log in to OracleAS Portal.
Click the Build tab to bring it forward.
From the Page Group portlet's Work In drop-down list, select the page group that owns the page on which to enable item level security.
In a typical installation, the Page Groups portlet is located on the Build tab of the Portal Builder.
Under the Pages heading in the Layout & Appearance section, click the page on which to enable item level security.
This opens the page in Edit mode.
Click the Access link in the page toolbar.
On the resulting page, go to the Access Properties section and select Enable Item Level Security.
Click OK to return to the page.
This enables item creators to set access controls for individual items on the page. Item creators have the choice of inheriting access controls from the page or setting specific access controls for individual items.
To enable item level security on a tab:
Log in to OracleAS Portal.
Click the Build tab to bring it forward.
From the Page Group portlet's Work In drop-down list, select the page group that owns the tab on which to enable item level security.
In a typical installation, the Page Groups portlet is located on the Build tab of the Portal Builder.
Under the Pages heading in the Layout & Appearance section, click the page that contains the relevant tab.
This opens the page in Edit mode.
Go to the tab on which to enable item level security.
Click the Edit Tab icon (Figure 18-5).
Be sure to click the Edit Tab icon on the tab flap and not the one beside the tab.
On the resulting page, click the Access tab to bring it forward.
Go to the Access Settings section, and select Specify Access Settings.
In the Access Properties section, select Enable Item Level Security.
This enables item creators and item owners to grant access privileges on individual items on the tab. Item creators have the choice of inheriting access controls from the tab or granting access privileges on each item on the tab.
To enable item level security on a Portal Template:
Log in to OracleAS Portal.
Click the Build tab to bring it forward.
From the Page Group portlet's Work In drop-down list, select the page group that owns the Portal Template on which to enable item level security.
In a typical installation, the Page Groups portlet is located on the Build tab of the Portal Builder.
Under the Portal Templates heading in the Layout & Appearance section, click the template on which to enable item level security.
This opens the page in Edit mode.
Click the Access link in the toolbar at the top of the template.
On the resulting page, go to the Access Properties section and select Enable Item Level Security.
Click OK to return to the page.
As a content contributor, you can decide if you want to grant additional access to an item to selected users or groups.You can grant access on one item or on multiple items simultaneously. This section provides information on both actions. It includes the following subsections:
|
Note: To grant access privileges on an item, you must have at least the item privilege Manage on the item. |
To grant access privileges on one item:
Log in to OracleAS Portal.
Click the Build tab to bring it forward.
From the Page Group portlet's Work In drop-down list, select the page group that owns the page that contains the item on which to grant access privileges.
In a typical installation, the Page Groups portlet is located on the Build tab of the Portal Builder.
Under the Pages heading in the Layout & Appearance section, click the page that contains the item on which to grant access privileges.
This opens the page in Edit mode.
Locate the relevant item, and click the Actions icon beside the item (Figure 18-6).
|
Note: For Page Link items, even if users have item level privileges on the item, they will not see the item if they do not have access to the target page. |
On the resulting page, click the Access link.
In the Item Level Security section, select Define Item Level Access Privileges.
Two additional sections display: Grant Access and Change Access. For some older versions of browsers, such as Netscape 4.x browsers, you may have to click Apply to make the additional sections display.
|
Note: If you select Inherit Parent Page Access Privileges, the item has the same access privilege as was set for the parent page.If the item has multiple versions, the access setting is applied to all versions of the item, not just the one that you are editing. |
In the Grant Access section, enter the name of the user or group to whom to assign privileges.
Click the Browse Users icon to display a list of existing users or the Browse Groups icon to display a list of existing groups.
|
Note: Adding a group saves time when you want to grant the same access privilege to multiple users. |
From the privilege drop-down list, select an item level privilege to grant to the specified user or group.
|
Note: For a list and description of item-level privileges, see Appendix B, "Page Group Object Privileges". |
Click Add.
Grantees and their privilege levels display in the Change Access section. In this section, you can choose a different item-level privilege, or revoke item privileges from users or groups.
Repeat steps 8 through 10 for each relevant user or group.
When you are done, click OK.
|
Note: OracleAS Portal uses the Oracle Internet Directory for identity management. The Oracle Internet Directory serves as the repository for users and groups. In the Oracle Internet Directory, groups are uniquely identified by their distinguished name (DN). Each group has a unique DN, though many groups can share a common name, in the same way that two people can share a common name, yet have completely different lineage (such as John Smith and John Doe). When working within the portal, groups created from within that portal are displayed simply with their common names. However, when the portal references a group from some other location in the Oracle Internet Directory—such as a group from some other portal associated with the same Identity Management Infrastructure—the DN of the group is displayed to distinguish it from the portal's locally defined groups.Item level security cannot be disabled for items in the Portlet Repository page group. |
If a user is a member of two different groups with different privileges on the same item, the user is not limited by the lesser privilege. For example, if one group has the item privilege Edit, and another group has the item privilege Manage, and you belong to both groups, you can both view and manage the item.
To revoke the user or group's access, click the Delete icon next to the Grantee Name under Change Access.
Use the Actions list in List view of page Edit mode to change access settings on multiple items simultaneously. For these actions to be taken, item level security must first be enabled on the page, tab, or template where you will perform the action. For more information, see Section 18.9.1, "Using Item Level Security".
To change access settings on multiple items simultaneously:
Log in to OracleAS Portal.
Click the Build tab to bring it forward.
From the Page Group portlet's Work In drop-down list, select the page group that owns the page that contains the items on which to change access privileges.
In a typical installation, the Page Groups portlet is located on the Build tab of the Portal Builder.
Under the Pages heading in the Layout & Appearance section, click the page that contains the items on which to change access privileges.
This opens the page in Edit mode.
Click the List link in the toolbar at the top of the page.
This displays the page in List view of page Edit mode.
Select the check boxes next to the items to be changed.
From the Actions drop-down list, select one of the following options, and click Go:
Modify Item Access Settings
Select this option to modify the access settings of the checked items. Once you click Go, the Bulk Action: Modify Item Access Settings screen displays:
Use the Item Selections section to identify the items on which to modify item access settings.
Select Specified Item Level Access, to act on items that have individually defined access settings. Click the Revoke All link to revoke all access privileges currently applied to these items.
Select Items Inheriting From Parent Page, to act on items that inherit their access settings from the page on which they are placed.
Under Grant Access, assign privileges to the selected items as desired. For more information, see steps 8 through 12 of Section 18.9.1.5.1, "Changing Access on One Item".
Click Close when finished.
Do not Inherit Item Access Settings
Select this option to specify that the specified items do not inherit their access settings from the page or tab on which they are placed. Click Go, then click OK in the resulting confirmation dialog.
Inherit Item Access Settings from Parent
Select this option to specify that the specified items inherit their access settings from the page or tab on which they are placed. Click Go, then click OK in the resulting confirmation dialog.
Approvals enable you to delegate the addition and revision of portal content without relinquishing control over what is actually displayed to your users. Approval-related features of particular interest are:
A defined approval process
The page privilege Manage Items With Approval (or the global privilege of the same name on the object type All Pages)
Item drafts
This section describes these features and points you to relevant information in other chapters in this guide.
For any of these features to be meaningful, you must first enable Approvals and Notifications on the Configure tab of page group properties (see Section 6.4.1, "Enabling Approvals and Notifications for a Page Group"). Once approvals are enabled, you can define an approval process, grant the page privilege Manage Items With Approval, and enable item drafts for a page group or (if allowed) a page.
Approval processes can reduce the costs of a paper-driven office in which hard-copy documents requiring approvals, such as expense reports and travel requests, create bottlenecks for your workers. When you define approval processes, you allow the appropriate people in your organization to receive notification of pending items requiring approval, to review the items, and to approve or reject the items, all from your company's portal.
By default, approval processes are defined at the page group level. If the page group is configured to allow pages to have their own approval processes, approval processes can be defined as well at the page level. Both page groups and pages provide a place to define an approval process on the Approval tab of their properties pages. For more information, see Chapter 21, "Setting Up an Approval Chain".
When a user with the page privilege Manage Items With Approval uploads or revises content, the content is submitted to a defined approval process where it can be reviewed and passed for publication or rejected. Keep in mind, however, if you have users with the page privilege Manage Items with Approval, and no approval process is defined, this privilege is equivalent to the page privilege Manage Content in relation to items. In other words, such users are able to publish items that have not been through an approval process. For information on granting privileges on pages, see Section 18.5.2, "Granting Privileges on a Page". For additional information on approvals, see Chapter 21, "Setting Up an Approval Chain".
You can also configure a page group to support item drafts. When the draft feature is enabled, content developers can upload items to the portal without exposing them until the content developers are ready to submit the items for approval. This is because draft items do not display to most users when a page is viewed. (To find out which users can view items in what state, see Section 18.9.3, "Item URL Security".) When the page is in Edit mode, users can see draft items in Pending Items Preview or List view, where such items are clearly labeled as drafts.
Content developers can upload draft content, placing it where they want it to display on the page, but preventing it from general display until they change its draft status. When the draft is finalized, the contributor can change its status, either to Active or to Pending, depending on whether an approval process is in place and the contributor is required to submit items for approval. Keep in mind that, once enabled, the Draft option cannot be disabled until all draft items are switched to active status or submitted for approval.
The option to enable drafts is located on the Approval tab of page or page group properties. Approvals must be enabled for the draft feature to be enabled, although drafts do not necessarily require approval. Approvals can be enabled without there being a defined approval process. This makes it possible to enable drafts for everyone without ultimately requiring that their finalized content be approved. For information on enabling item drafts, see Chapter 21, "Setting Up an Approval Chain".
Table 18-2 outlines the access rules that apply to URLs for items in various states, such as Draft, Pending, Unpublished, and so on. Additionally, it discusses these states under three scenarios:
Access through the portal
Access through WebDAV
Access through a search
|
Note: In addition to an item's status, and the avenue through which the item is accessed, caching options can affect item access. For more information, see Chapter 22, "Improving Page Performance". |
References to content managers refer to anyone with the appropriate manage privilege when item level security is enabled. Manage privileges can mean:
The global privilege Manage All on the object type All Page Groups
The global privilege Manage on the object type All Pages
The global privilege Manage Content on the object type All Pages
The global privilege Manage Items With Approval on the object type All Pages
The page privilege Manage
The page privilege Manage Content
The page privilege Manage Items With Approval
The item privilege Manage
Table 18-2 Item URL Security
| Item State | Access Through Portal | Access Through WebDAV | Access Through Search |
|---|---|---|---|
|
Content managers and draft creator can access/view the item. |
Users with the page or global privilege Manage Items With Approval can see the item and work on it. Users with the item privilege Manage can see the item with a size of 0 KB. Such users cannot update or view the item. Users with the item privilege View do not see the item. |
Draft items are not returned for any user. Even the Manage Item With Approval users who added the item in Draft mode. |
|
|
Content managers, item creator/updator, and approvers can access/view the item. |
Users with the item privilege Manage can see the pending item with a size of 0 KB. The user who submitted the item can see it with the actual size. Users with the item privilege View can see the pending item with a size of 0 KB. This is to enable a view of the reserved name space. |
Pending items are not returned for any user. |
|
|
Content managers and users with the page or global privilege Manage Items With Approval can access/view the item. If the item uses Item Level Security, users who have the item privilege Manage on the item can access/view the item. |
The item is not visible to users with the item privilege View. Content managers see the item if the option Display Unpublished, Expired, and Deleted Items In Edit Mode is selected in page group properties. |
Unpublished items are not returned for any user. |
|
|
If the item is Active, anyone with privilege to see the page can see the item. If the page is Public, all users can access/view the item through the draft URL. If the item uses Item Level Security, users who have the item privilege Manage on the item can access/view the item. If the item is Expired or Deleted, only the content manager can access/view the noncurrent version. |
The current version is always displayed. |
The current version is always returned. |
|
|
The item is accessible through the item URL by anyone with sufficient privilege to see the page. If the item uses Item Level Security, users who have the item privilege View on the item can access/view the item. If the page is Public, anyone can view the item content. |
The item is not visible to user with the item privilege View. The item is visible to users with the page or global privilege Manage or Manage Items With Approval. |
Hidden items are not returned for any user. |
|
|
Content managers can access/view the expired item. If the item uses Item Level Security, users who have the item privilege Manage on the item can access/view the item. |
The item is not visible to users with the item privilege View. Content managers see the item if the option Display Unpublished, Expired, and Deleted Items In Edit Mode is selected in page group properties. |
Expired items are not returned for any user. |
|
|
Content managers can access/view the deleted item. If the item uses Item Level Security, users who have the item privilege Manage on the item can access/view the item. |
The item is not visible to users with the item privilege View. Content managers can see the item if the option Display Unpublished, Expired, and Deleted Items In Edit Mode is selected in page group properties. |
Deleted items are not returned for any user. |
Style privileges are available at the global level and for page groups, pages, and tabs. Table 18-3 lists and describes the privileges relating to styles at each of these privilege levels.
|
Note: Granting a privilege at the global level is discussed in Section 18.3, "Granting Global Privileges". Granting a privilege at the page group level is discussed in Section 18.4, "Securing Page Groups". Granting a privilege at the page level is discussed in Section 18.5, "Securing Pages". Granting a privilege at the tab level is discussed in Section 18.6, "Securing Tabs". |
Table 18-3 Privileges Relating to Styles
When you grant privileges on a Portal Template for pages, you are controlling access to the pages that are based on the template, rather than on the template itself. When you grant privileges on a Portal Template for items, you are controlling access to the template, its tabs, and its items—depending on the level of security applied.
This section discusses how to grant access privileges on Portal Templates for pages and Portal Templates for items. It also lists and describes the privileges that provide some level of template management access. It includes the following subsections:
To define template access privileges, you must have the global privilege Manage on the object type All Page Groups or the page group privilege Manage Templates or higher on the page group.
Granting access on a Portal Template for pages means setting security controls that affect all pages that are based on the template. For Portal Templates for pages, the Access tab enables you to control access to the pages that are based on this template, but not on the template itself.
You can grant access only on Portal Templates and not on HTML Templates.
|
Note: To grant access privileges on a template, you must have at least the page group privilege Manage Templates on the page group that owns the template.To make a Portal Template available for use in a page group, the option Make available for use in this page group must be selected on the Main tab of template properties. |
To grant access privileges on a Portal Template for pages:
Log in to OracleAS Portal.
Click the Build tab to bring it forward.
From the Page Groups portlet Work In drop-down list, select the page group that owns the template on which to grant access privileges.
In default installations of OracleAS Portal, the Page Groups portlet is located on the Build tab of the Portal Builder page.
Under Portal Templates in the Layout & Appearance section, click the Portal Template on which to grant access.
This opens the template in Edit mode.
Click the Access link in the toolbar at the top of the template.
Select Enable Pages to Have Different Access to enable users with sufficient privileges to choose different access control settings when they create or edit pages that are based on the template.
Clear this check box to prevent users from choosing different access control settings when they create or edit pages that are based on this template. Such pages will always use the template access control settings.
Select Display Page to Public Users to enable all users to view pages that are based on this template—even users who are not logged on.
Clear this check box to limit the display of pages that are based on this template to users who have explicitly been granted access.
Any rendered page with this option enabled becomes a crawlable data source for Oracle Ultra Search. This means if the page that is based on this template uses the template's access settings, and this option is enabled on the template, the page is available for a crawl initiated through Oracle Ultra Search. See also, "Registering OracleAS Portal as a Content Source," in the Oracle Application Server Portal Configuration Guide.
Select Enable Item Level Security to enable item creators to specify access control settings for individual items on pages that are based on this template.
If you select this check box, item creators can choose to inherit access control from the template or specify access control for individual items.
If you do not select this check box, all the items on the template inherit access control from the template.
Under the Grant Access section, define access settings for individual users and groups:
In the Grantee field, select a user or group.
Browse for user or group names by clicking the Browser Users or Browser Groups icons.
|
Note: OracleAS Portal uses the Oracle Internet Directory for identity management. the Oracle Internet Directory serves as the repository for users and groups. In the Oracle Internet Directory, groups are uniquely identified by their distinguished name (DN). Each group has a unique DN, though many groups can share a common name, in the same way that two people can share a common name, yet have completely different lineage (such as John Smith and John Doe). When working within the portal, groups created from within that portal are displayed simply with their common names. However, when the portal references a group from some other location in the Oracle Internet Directory—such as a group from some other portal associated with the same Identity Management Infrastructure—the DN of the group is displayed to distinguish it from the portal's locally defined groups. |
In the next (access privilege) field, select the level of privilege to grant to the user or group selected in the Grantee field.
For an explanation of the listed privileges, see Appendix B, "Page Group Object Privileges".
Click the Add button.
Once you grant a privilege, a Change Access section displays. Use this section to revise or revoke privileges.
If you are changing template access, once you have redefined access privileges click the Clear Cache link in the Cache Invalidation section.
Click the Finish button.
The template displays in Edit mode.
OracleAS Portal provides options for overriding template style and access settings. These are useful for allowing privileged users to select a style or set access rules other than those used by the template for a page that is based on the template.
To use this option for styles, select Enable Pages To Use Different Style on the Style tab of template properties. To use this option for access settings, select Enable Pages to Have Different Access on the Access tab of template properties. This option is available for Portal Templates for pages, but not for Portal Templates for items.
Granting access to a Portal Template for items means setting security controls on the template itself. Portal Templates for items are rendered dynamically when a link to an item that uses the template is clicked, so any access controls you set on the template apply to every rendered version of the template.
To view a page that is dynamically assembled using a Portal Template for items, one of the following conditions must be met:
The template must be public.
The user must have at least the View privilege on the template.
The user must have the page group privilege Manage Template on the page group that owns the template.
To grant access privileges on a Portal Template for items:
Log in to OracleAS Portal.
Click the Build tab to bring it forward.
From the Page Groups portlet Work In drop-down list, select the page group that owns the template on which to grant access privileges.
In default installations of OracleAS Portal, the Page Groups portlet is located on the Build tab of the Portal Builder page.
Under Portal Templates in the Layout & Appearance section, click the Portal Template for items on which to grant access.
This opens the template in Edit mode.
Click the Access link in the toolbar at the top of the template.
Select Display Page to Public Users to enable all users to view this template—even users who are not logged on.
When this option is selected, users can see all template content, provided the content is not further restricted by access rules on template tabs or items. When tabs or items have their own access rules, users will need specific privileges on the template tabs or items.
Clear this check box to limit the display of this template to users who have explicitly been granted access.
Select Enable Item Level Security to enable item creators to specify access control settings for individual items on the template:
If you select this check box, item creators can choose to inherit access control from the template or specify access control for individual items.
If you do not select this check box, all the items on the template inherit access control from the template.
Under the Grant Access section, define access settings for individual users and groups:
In the Grantee field, select a user or group.
Browse for user or group names by clicking the Browser Users or Browser Groups icons.
|
Note: OracleAS Portal uses the Oracle Internet Directory for identity management. the Oracle Internet Directory serves as the repository for users and groups. In the Oracle Internet Directory, groups are uniquely identified by their distinguished name (DN). Each group has a unique DN, though many groups can share a common name, in the same way that two people can share a common name, yet have completely different lineage (such as John Smith and John Doe). When working within the portal, groups created from within that portal are displayed simply with their common names. However, when the portal references a group from some other location in the Oracle Internet Directory—such as a group from some other portal associated with the same Identity Management Infrastructure—the DN of the group is displayed to distinguish it from the portal's locally defined groups. |
In the next (access privilege) field, select the level of privilege to grant to the user or group selected in the Grantee field.
For an explanation of the listed privileges, see Appendix B, "Page Group Object Privileges".
Click the Add button.
Once you grant a privilege, a Change Access section displays. Use this section to revise or revoke privileges.
If you are changing template access, once you have redefined access privileges click the Clear Cache link in the Cache Invalidation section.
Click the Finish button.
The template displays in Edit mode.
For information about setting access privileges on tabs, see Section 18.6, "Securing Tabs". For information about setting access privileges on items, see Section 18.9, "Securing Items".
You can grant privileges related to templates at the global level, the page group level, and the page level. Such privileges apply to both Portal Templates and HTML templates. This section lists and describes these privileges.
|
Note: For information about granting privileges at the global level, see Section 18.3, "Granting Global Privileges". For information about granting privileges at the page group level, see Section 18.4, "Securing Page Groups".For more information about templates, see Chapter 13, "Providing a Standard Look and Feel". |
Table 18-4 lists and describes the types of privileges that provide access to templates.
Table 18-4 Privileges Relating to Templates
| Privilege | Description |
|---|---|
|
The global privilege Manage All on the object type All Page Groups |
Perform any task on any page group. This privilege supersedes any other privilege in the other page group global privileges. For example, this also allows managing of any page. This user is the manager for all page groups, and by extension, the manager of all templates. |
|
The global privilege Manage Templates on the object type All Page Groups |
Create, edit, and delete any Portal Template or HTML template in any page group. Grant access to any template. |
|
The global privilege Manage Classifications on the object type All Page Groups |
Create, edit, and delete any category, perspective, custom attribute, custom page type, or custom item type in any page group. |
|
Create, edit, personalize, or delete any page in any page group. Grant access to any page in any page group. This privilege includes the ability to apply templates to all pages. |
|
|
Create sub-pages in any page group. Users and groups with this privilege can also edit and delete the sub-pages they create. To use this privilege to create sub-pages, a user must have the page privilege Manage on the parent page under which sub-pages are created. This privilege includes the ability to apply templates to pages the user creates. |
|
|
A user with this privilege can perform any task within the page group. The Manage All privilege includes all other page group privileges: Manage Classifications, Manage Templates, Manage Styles, and View. A user with this privilege is called the page group administrator. |
|
|
A user with this privilege can create, edit, and delete any category, perspective, attribute, custom item type, and custom page type in the page group. |
|
|
A user with this privilege can create, edit, and delete any template in the page group. A user with this privilege must also have the page group privilege View to view pages in this page group. A user with this privilege can delete a tab on a template only if other users have not placed their own content on it on pages that are based on the template or if the user also has content management privileges on the pages that are based on the template. |
|
|
This privilege enables users to apply a template to the page(s) they manage. This privilege carries with it many other capabilities. For more information, see Appendix B, "Page Group Object Privileges". |
Content attribution includes page group objects such as:
Categories
Perspectives
Item Types
Page Types
Attributes
You can find privileges for creating or taking action on these objects at the global and page group levels. At more focussed levels, such as page, tab, and item, you can use these objects—for example, you can apply a category to a page—but you cannot act on them.
This section provides information about the privileges that carry with them the power to act on objects related to content attribution.
|
Note: For information on granting privileges at the global level, see Section 18.3, "Granting Global Privileges". For information on granting privileges at the page group level, see Section 18.4, "Securing Page Groups". |
Table 18-5 lists and describes the privileges relating to content attribution.
Table 18-5 Privileges Relating to Content Attribution (Categories, Perspectives, Object Types, and so on)
The Privileges tab does not display on the Edit Portal Users Profile page
The portal administrator may have run the script serlacl.sql to enforce role-based security. Role-based security limits privilege grantees to groups; users cannot be selected for privilege assignment. The script does not affect privileges granted to users before it was run, only after. You may also note that the Browse Users icon does not appear next to the Grantee field on Access tabs.
For more information, see Oracle Application Server Portal Configuration Guide.
The Browse Users icon does not display on the Access tab
I have the page privilege Manage Style, but I cannot apply a style.
It is not enough to have the Manage Style privilege on a page. The page group option Allow Privileged Users To Manage Page Style must also be selected for the page's page group. For more information, see Section 4.3.2, "Controlling Who Can Apply a Different Style to a Page".
I tried to disable item drafts, but could not.
Once enabled, the Draft option cannot be disabled until all draft items are switched to active status or submitted for approval.
The Style tab does not display.
If the page is based on a template, and template access is set up to prevent users from applying styles to pages that are based on the template, the Style tab cannot be accessed in the page properties of pages based on the template.
