E-PORTAL: How To Restrict UserID To A Specific Portal? (Doc ID 974517.1)

Last updated on FEBRUARY 06, 2017

Applies to:

PeopleSoft Enterprise PT PeopleTools - Version 8.48 to 8.51 [Release 8.4]
Information in this document applies to any platform.
Checked for relevance on 12-04-2012


Goal

In current portal technology the portal administrator (but all the rest of other users) can switch between different portal registry by simply changing the portal name in the URL browser address bar - Note that this switch is by design and cannot be prevented -

Anyhow we don't foresee any issues here, as far the component (not portal cref) security should always disallow the access to restricted components, based on standard security, the is set trough roles and permission lists and a proper security shoudl be always set regardless the specific Portal where these components are finally registered.

Note that the simpler Portal registry security cannot prevent the access to certain components, even these would not be registered in any portal registry, while only the standard (component) security can control this.

Note as well that for certain custom purposes, some individuals would need to be granted in PS with multiple userID's having different roles if external security access is a matter of concern (e.g. one user with no admins roles for certain "supplier" or  "Self service" activities, and an additional "admin user" when working as an PS admin)

Some customers implementing different Portals for various specific business purposes are asking how can a specific User ID be restricted to accessing a specific Portal Registry, such as locking a vendor ID into the SUPPLIER registry?



EXAMPLE:

---------------
This solution applies to several situations:
  1. A customer wants Internet Users to access only a subset of the menu (Self Service) and Intranet Users to have access to a full menu.
  2. A customer wants a user population to access it's own Portal and menu items (Suppliers, Vendors, Customers) instead of getting the default Employee Portal.
  3. Customers want to setup multiple Employee populations that shouldn't overlap.
  4. Customers wish to have a registry for "Power Users" and a registry for "Self Service Users" with their own menu structure.
In all of these cases, it may be possible to setup a custom solution to prevent a pool of users access to various registries by blocking an IP range at a Firewall, Reverse Proxy or Load Balancer.  This solution doesn't address that situation.  Instead, setting up logical security groups to correspond to the user pool in question is the way to solve the problem using delivered options.  For instance, the Internet User pool above would simply have it's own set of security vs. Intranet and then the Portal security is setup in each separate registry to use one or the other (but not both unless it's an admin ID).
Of course, all of this could be accomplished in the same registry through the same security segmentation - but some customers want to brand a registry differently or simply want something more "concrete" than logical segmentation so that each pool uses a specific URL and admins can focus efforts in a specific registry.

Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms