17.5 Securing Pages

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:

17.5.1 Making a Page Available to Everyone

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.

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.

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.

17.5.2 Granting Privileges on a Page

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.

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:

Oracle 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.

17.5.3 Caching and Security

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.