Portal Page Security & Dynamic Groups in Portal 10.1.4

An important restriction to the use of dynamic groups in portal is that only 2 caching options can be used for pages in portal. They are 1) Don't cache 2) Cache page definition content for X minutes

The reason for these particular caching options is because portal will invalidate pages when a group or a user that is referenced in that page's Access Control List (ACL) in portal are modified or deleted.

Portal gets this information from OID through the DIP (Directory Integration Provisioning) ; however for dynamic groups there is no such notification. The portal does not have any automated way to know that changes have been done to the dynamic groups.

How to Export & Import Between Development & Production Oracle AS Portal instances?

The following steps provide an overview of the process:

1. Develop page groups, applications, and content on the source system.
2. Identify pages, applications, and content to export, then create transport sets
accordingly and export to the target system.
3. Import the transport sets on the target system, into your portal repository.

I. Exporting Data
To create a transport set for export:
1. Select the objects for export. You can do this from the Navigator as shown below.

2. Click the Export link to display the Transport Set Manager. Make the transport set name as descriptive as possible, and avoid using any special characters at the start of the name. For example, My Company Transport Set 18-JAN-2003.

3. Select the appropriate options under Transport Set Options: 

Export Access Control Lists: Includes access control lists (ACLs) associated with the objects in the transport set. If you select this option, the following happens:

o Users and groups associated with the objects are migrated.

o Privileges attached to the objects are migrated.

o Parameters and events associated with the users are migrated.

Validate System Tables: Enables you to choose if you want to validate system tables before you export.

4. Select either Export Now if you are finished, or Save for Later if you want to add more objects

5. To finalize the transport set, click Export Now. The objects marked for export are copied to the transport tables for migration. These operations happen in the background.
6. Check the log in your transport set manager for any errors by clicking the View Log Of Actions link

7. Next, select an appropriate export script based on your operating system.

8. Right-click the selected script, then click Save Target As.
9. Change the name and remember to include the correct file extension, .csh for UNIX or .cmd for NT. For example, MyScript.csh.
10. Save the file to the directory on your file system where you want to run the export script. Usually, this directory is where your export portal resides.

For e.g. if the development server name is dev.company.com, then copy the .csh file to a folder called $ORACLE_HOME/ExportImport in dev.company.com

II. Running the Script to Create an Export Dump File
To create a dump file:

Run a script with the parameters shown in the following example. The example assumes that the name of the script is MyScript.csh. The parameters in bold are applicable only for export, and they are mandatory.

Usage: MyScript.csh <-mode export_or_import> <-s portal_schema> <-p portal_password> <-pu portal_username> <-pp portal_userpassword> <-company company_name> <-c connect_string> <-d dump_file_names> <-automatic_merge>

For e.g $ MyScript.csh -mode export -s PORTAL -p F5R46ucd -pu orcladmin -pp welcome1 -company companyname -c ORCL -d FILE1.DMP

Finally, using FTP, transfer your dump file and the Export and Import script to the computer where your target OracleAS Portal schema resides.
For e.g. move the MyScript.sh & FILE1.dmp to $ORACLE_HOME/ExportImport in prod.company.com

III. Running Your Script on the Target System
To import your objects, the contents of the transport set dump file must first be imported to the transport set tables on the target system. This is done by calling the same script (used in the export) with the -mode parameter set to import. The parameters in bold are applicable only for import and are mandatory.

Usage: MyScript.csh <-mode export_or_import> <-s portal_schema> <-portal_password> <-pu portal_username> <-pp portal_userpassword> <-company company_name> <-c connect_string> <-d dump_file_names> <-automatic_merge>
For e.g. MyScript.csh -mode import -s PORTAL -p LR05V0B5 -pu orcladmin -pp prodpassword - company companyname -c MYINFRA -d FILE1.DMP

IV. Importing Data
To import your content: 

11. Locate the Export/Import Transport Set portlet, installed by default on the Administer tab. 12. Select the imported transport set and click Import. The Objects page of the Import Manager is displayed.

13. If you select Replace on Import, then the object is replaced if it is found in the target portal.
14. Click Close to return to the Objects page
15. Click the Main tab.

16. Select either Import Now if you are finished, or Save for Later.

How to Performance Tune OracleAS Portal?

Setting the Number of PPE Fetchers
A request for a portal page originates in the form of a URL sent from a user's browser to the HTTP server. If the request is for a portal page, it is forwarded to the Parallel Page Engine (PPE). The PPE then asks each Web provider that owns a portlet on the page to execute the portlet and return content to the portal page.

There are two options available to enable you to increase the concurrency of the PPE:

Option 1: Create a New OC4J Instance to Create Another Set of PPE Threads
Access the Application Server Control Console.
Typically the Application Server Control Console is located at http://hostname:1810

1. Click the link for the application server middle tier where OracleAS Portal is
installed.
2. Click the OC4J_Portal link.
3. Click the Administration link.
4. Click the Server Properties link
5. Under the Multiple VM Configuration section, change the Number of Processes for the default_island to 2.
6. Click Apply.
7. Navigate back to the OC4J_Portal home page.
8. Click Restart, to restart the OC4J_Portal instance.

Alternatively, you can edit the file opmn.xml manually, though the use of Application
Server Control Console is the recommended approach.The parameter to create multiple Oracle Application Server Containers for J2EE instances is called numProcs and is configured in the file ORACLE_HOME/opmn/conf/opmn.xml.

Option 2: Increase the Value of Default Number of Threads
The parameter to tune the number of PPE threads is called poolSize and is configured in
the file 
ORACLE_HOME/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF/web.xml

The default setting is 25. If pool size is too low, the user notices that pages take too long to
draw at peak periods. If pool size is set too high, a possible resource drain may occur
because too many concurrent URL requests can overwhelm the PPE.

How to add Oracle Portal as an External Application in another Oracle Portal?

Assumptions:

First instance of Oracle Portal is accessible as follows:

http://newportal.company.com/pls/portal

Second instance of Oracle Portal is accessible as follows:

http://oldportal.company.com/pls/portal

Each of the instances above, when accessed, authenticate users with thei respective Infrastructure instances.

Description:

The following steps will allow the second instance of Oracle Portal to be added as an External Application in the SSO of first instance.

Step 1:

Login as user with full SSO administrative privileges (orcladmin) in First Instance. Create an External Application with the details as follows:

Application Name: Old Portal (Ext App)

Login URL: http://oldportal.company.com:7778/pls/portal/PORTAL.wwptl_login.login_url

User Name/ID Field Name: ssousername

Password Field Name: password

Type of Authentication Used: POST

In the Additional Fields,

p_requested_url -> http://oldportal.company.com:7778/pls/portal/PORTAL.HOME

p_cancel_url -> http://oldportal.company.com:7778/pls/portal/PORTAL.HOME

Step 2:

Login as user with administrative privileges (Portal)

1. Add the External Applications Portlet to a Portal Page.
   
2. Check to display the newly created External Application to users
   
3. Users with privilege to access the Page/Portlet will now be able to access the second instance from the first instance of Portal.

Where does the partner application details stored in the Metadata Repository Database?

The details are available in ORASSO schema in the following tables,

orasso.wwsso_ls_configuration_info_t

orasso.wwsso_papp_configuration_inf_t

How to create Portal Super User in Oracle Portal 10g (10.1.2) ?

Out of the box, the following users are available for logging into Oracle AS Portal,

• 
  portal
  
• 
  portal_admin
  
• 
  orcladmin
  

‘orcladmin’ user has the maximum privilege who has complete access to portal, OIDDAS & content services. If you would like to grant another new user say "my_portal_admin" who has complete Administrative access to portal, then after creation of user using OID DAS, add the user to the following groups

•   PORTAL_DEVELOPERS,
  
•  PORTAL_ADMINISTRATORS,
  
•  PORTLET_PUBLISHERS,
  
•  RW_ADMINISTRATOR,
  
•  OIP_USER_ADMINS,
  
•  DBA
  

Making the user part of the groups mentioned above will him the access except for the “SSO Server Administration” portlet available in Portal Builder “Administer” tab-> Portal sub-tab.

For granting the access to the above-mentioned portlet, log in to Oracle Directory Manager as root user. Navigate to Entry Management -> cn=OracleContext -> cn=Groups -> cn=iASAdmins . Append the DN of the new user to the list of ‘uniquemember’

What are OracleAS Portal default User Accounts & Groups?

Default OracleAS Portal Users

1. PUBLIC - It is the user account that identifies unauthenticated access to the OracleAS Portal. Once a user logs in, the user name changes from PUBLIC to the user name by which the user is authenticated.
2. PORTAL - It is the super-user for the portal. This user account has the highest privileges because it is granted all the global privileges available in the portal.
3. ORCLADMIN - Similar to PORTAL, this account is granted the highest privileges in OracleAS Portal. This account is created for the Oracle Application Server administrators, and uses the password that is supplied during the Oracle Application Server installation.
4. PORTAL_ADMIN - It is a privileged OracleAS Portal user account with administrative privileges. But this user cannot edit any group or manage privileges on any schema or shared object. This account is typically intended for an administrator who manages pages and provisions user accounts.

Some of the Default OracleAS Portal Groups

1. AUTHENTICATED_USERS - It is the group that includes any authenticated, or logged in user.This group is a member of OracleDASCreateGroup.
2. DBA- It is a highly privileged group established for Oracle Application Server administrators. This group is also a member of the PORTAL_ADMINISTRATORS group,& other Oracle Application Server privilege groups such as OracleDASCreateGroup, OracleDASEditUser, OracleDASDeleteUser, OracleDASCreateGroup, OracleDASConfiguration,etc
3. PORTAL_ADMINISTRATORS- It is a highly privileged group established for OracleAS Portal.By default, this group is given the following OracleAS Portal global privileges: Manage All Page Groups, Pages, Providers, Portlets, Execute All transport sets. This group is also a member of the following Oracle Application Server privilege groups such as OracleDASCreateUser,OracleDASEditUser,etc. Members of PORTAL_ADMINISTRATORS do not have the necessary privileges to administerOracleAS Single Sign-On.
4. PORTLET_PUBLISHERS - Is a privileged group established for users who need to publish portlets to other users of the portal.
5. PORTAL_DEVELOPERS - Is a privileged group established for users who are building portlets. The users who are part of this group can Create All Portal DB Providers, Manage All Shared Components
   
6. OIP_USER_ADMINS- It is the group of users who can create Oracle Instant Portals & perform user administration on them. 
7. OIP_AVAILABLE_USERS- It is the group of users who can access Oracle Instant Portals

How to modify or reset an External Applications SSO stored password?

What are External Applications?

External Applications do not delegate the authentication to the SSO server. Instead they display HTML forms that ask for username & passwords. Each External application may require a unique  username & password. 

You can configure SSO server to provide username and password to external applications on user's behalf once the user has logged into the SSO server.

Users have the option of storing external credentials in the SSO database.

Steps to do:

Deleting entry from wwsso_appuserinfo_t table

By removing the wwsso_appuserinfo_t entry for the specific APP_ID and SSO_USERNAME will cause the login page to prompt for a username and password the next time the external application link is used. The login and password are kept in the SSO server table called wwsso_appuserinfo_t. You need to know the sso_username, app_id, and the app_name for the external application whose password needs to be reset.

1. Launch SQLPLUS and connect as the ORASSO user to the metadata repository database. 
2. Execute the following sql statement
select app_id,app_name from wwsso_application_info_t;

This will return all the Registered External Applications.

Usage Example:

APP_ID APP_NAME

----------------------------------------------------- ----------

1BB95C43F626ABDED2496C0212CF7351 Self Service

4B4513196912E8F3B7B34B34CFABC6B5 Crystal New

95920AA96F51B6F81FE5708A8A251B03 Crystal Enterprise 10

E5B57C938938AD0C01A86FBF4E7C2F50 BMCSoftware

3.Execute the following sql statement

select sso_username from wwsso_appuserinfo_t;

This will return the SSO usernames that are registered with SSO.

Usage Example:

SSO_USERNAME

----------------------------------------------------

TESTUSER

USER

4.Execute the following sql statement

delete from wwsso_appuserinfo_t where app_id = <value from step 2> and sso_username= <value from step 3>

commit;

5.Now launch the External Application & you will be prompted to enter username and password.

OracleAS Portal default database Schemas

1. PORTAL schema - Contains the Oracle AS portal database objects & code. To execute Web requested procedures, Portal Services connect to the schema to which the lightweight user accounts are assigned (by default, PORTAL_PUBLIC). Access to the database of the portal user is proxied through the single schema user.
2. PORTAL_PUBLIC schema- It is the schema that all lightweight users are mapped to by default. All procedures publicly accessible through the Web are granted execute to PUBLIC, which makes them accessible through this schema
3. PORTAL_DEMO schema- Is created to hold some demonstration code. The installation of this schema is optional.
4. PORTAL_APP schema - Is used for external JSP application authentication

What is Direct Access URL (path aliasing)?

A direct access URL is an easy to read URL that users can enter to get to a specific item, document, page, category, or perspective in Oracle AS portal.

If you have a page group called mypagegroup. Within that page group you have a page called mypage and that page has a sub-page called mysubpage. If you navigate to mysubpage, the URL in your browser's location field will look something like the following:

http://my.company.com:7778/portal/page?_pageid=91,358983&_dad=portal&_schema=

PORTAL

This is a rather complicated URL to pass on to another user, so instead, you can give the user the page's direct access URL, which will look something like the following:

http://mycompany.com:7778/pls/portal/url/page/myportal/mypage/mysubpage

A direct access URL for a page is as follows

http://<hostname>:<portnumber>/pls/<dad>/url/page/<pagegroupname>/<objectname>

Usage Examples:

To access the root page of a page group called mypagegroup: http://mycompany.com:7778/pls/portal/url/page/mypagegroup

To access a page called mypage at the top level of the mypagegroup page group: http://mycompany.com:7778/pls/portal/url/page/mypagegroup/mypage

To access a page called mysubpage, which is a sub-page of mypage: http://mycompany.com:7778/pls/portal/url/page/mypagegroup/mypage/mysubpage

To access a tab called mytab on the mypage page: http://mycompany.com:7778/pls/portal/url/page/mypagegroup/mypage/mytab

To access categories & sub-categories: http://mycompany.com:7778/pls/portal/url/page/mypagegroup/mycategory

http://mycompany.com:7778/pls/portal/url/page/mypagegroup/mycategory/mysubcategory

To access page templates & navigation pages::

http://mycompany.com:7778/pls/portal/url/page/mypagegroup/mytemplate

http://mycompany.com:7778/pls/portal/url/page/mypagegroup/mynavigationpage

How to configure OracleAS Portal for WebDAV?

WebDAV is a protocol extension to HTTP 1.1 that supports distributed authoring and versioning. With WebDAV, the Internet becomes a transparent read and write medium, where content can be checked out, edited, and checked in to a URL address. mod_dav is an implementation of the WebDAV specification.

The term OraDAV refers to the capabilities available through the mod_oradav module. mod_oradav is the Oracle module that is an extended implementation of mod_dav, and is

integrated with the Oracle HTTP Server. mod_oradav can read and write not only to local files, but

also to an Oracle Database. The Oracle Database must have an OraDAV driver installed.

Similar to the portal DAD configuration file, WebDAV has it own configuration file (ORACLE_HOME/Apache/oradav/conf/oradav.conf) that contains the OraDAV parameters

and start with DAV and DAVParam. These parameters are specified within a "Location"

directive. The oradav.conf file is included in the httpd.conf file in an include statement.

By default, the OracleAS Portal DAV URL is:

http://hostname:portno/dav_portal/portal/

For example:

http://mysite.oracle.com:7777/dav_portal/portal

The dav_portal part of the URL is the default name of a virtual directory used to differentiate between portal access through a WebDAV client and portal access that uses the pls virtual directory. portal is the DAD of the portal installation.

Due to the way some WebDAV clients behave, users might experience authentication requests multiple times. To avoid this, the portal administrator can enable the cookie option by adding the following line to the oradav.conf file:

DAVParam ORACookieMaxAge '<'seconds'>'

where seconds is the amount of time in seconds before the cookie expires.

For example a value of 28800 is 8 hours and means that once a user has logged on through a

WebDAV client, he or she will not be prompted for a user name and password again until 8 hours has passed.

Why should we create a custom Image directory for storing all images in Portal?

To avoid losing custom images stored in the OracleAS Portal images directory (which is

ORACLE_HOME/portal/images by default) during a future upgrade, it is recommended that you create your own images directory and set up an appropriate Oracle HTTP Server alias for this directory.

How to clear the Portal Cache?

To clear the portal cache:Navigate to the portal cache directory. The default path is

$ORACLE_HOME/Apache/modplsql/cache

Perform a recursive delete of all the files under this directory. For example, on UNIX

platforms, issue the following command:

rm -rf *

This command will delete all of the following directories:

/Apache/modplsql/cache/plsql

/Apache/modplsql/cache/session

/Apache/modplsql/cache/pmd

Why should we clear Portal’s modplsql cache?

1. You made changes to a database object and do not see the result instantly on your Portal page
2. You applied a patch and you want to make sure that you see its effect instantly
   

How to set OracleAS Portal homepage as OHS default homepage?

In the directory ORACLE_HOME/Apache/Apache/htdocs/, make a backup copy of the files

index.html.html and index.html.lang, where lang is the language code. For example, index.html.en is the index HTML file for English.

Edit index.html.lang by replacing the entire contents of the file with the following HTML redirection code:

<HTML> 

<SCRIPT LANGUAGE=JavaScript> document.location="http://host.domain:port/pls/portal" 

</SCRIPT>

How to Simplify Full URL of a Oracle AS Portal Instance?

You can simplify the full URL created by the OracleAS Portal installation to a more memorable or meaningful URL using the Redirect directive. In this way, end users can access OracleAS Portal by entering a simple URL.

By default, the URL for a new OracleAS Portal installation requires you to enter:

http://hostname:portno/pls/dad

You can simplify this URL to:

http://hostname:portno/redirectpath

Steps to do

1. Open the Oracle HTTP Server configuration file, httpd.conf, which is located in

the following directory: $ORACLE_HOME/Apache/Apache/conf/

2. Enter the redirect path as follows:

Redirect /DADnamepath http://:/pls/dad

For e.g.

Redirect /portalhome http://mysite.oracle.com/pls/portal

In this example, end users can enter:

http://mysite. hostname.com/portalhome

to access the full URL, which is:

http://mysite. hostname.com/pls/portal

The example http://mysite.hostname.com/portalhome assumes that the default port 80 is

being used. If the default port is not being used, then the user would have to enter the URL

with the port number, http://mysite. hostname.com:portno/portalhome

Types of Portal Cache

Portal cache consists of two kinds of caches:

Portal Content Cache

The content cache contains user level and system level content generated by OracleAS Portal, which includes page metadata,etc

Portal Session Cache

OracleAS Portal uses session cookies to maintain session details for each portal user. Portal Services decrypts the session cookie once and maintains the relevant cookie details in an in-memory session cache.

Portal content and session cache content resides on the file system, typically under

ORACLE_HOME/Apache/modplsql/cache, and is configured in the file

ORACLE_HOME/Apache/modplsql/conf/cache.conf

How to configure Portal Cache?

Portal cache can be configured by navigating to the home page for OracleAS Portal instance. Click the Administer tab on the Portal Builder page and then click Portal Service Monitoring.

Types of Caching in Oracle AS portal?

OracleAS Portal uses three methods to cache Web pages and content:

Invalidation-based caching is performed using OracleAS Web Cache. An item remains in the cache until some event occurs that requires it to be refreshed. You can set the expiry time for invalidation-based caching.

Validation-based caching is performed using the portal cache. Before an item in the portal cache is used, Portal Services contacts the OracleAS Metadata Repository or a Provider to determine if the cached item is still valid.

Expiry-based caching also uses the portal cache. A retention period for the item specifies how long it is valid in the cache, before a refresh is required. Pages that use expiry-based caching may also be cached in the user's browser.

How is Oracle AS Portal page gets rendered to users?

When a client requests an OracleAS Portal page, many Oracle Application Server components must respond to various parts of the request:

1. The client browser requests a portal page. OracleAS Web Cache receives this request.
2. OracleAS Web Cache forwards the request to the Oracle HTTP Server
   
3. Oracle HTTP Server forwards the request to the Portal Services
4. The PPE (Parallel Page Engine), which is part of the Portal Services, retrieves the portal page definition.The page definition contains information about the portlets on a page and their layout.
5. First, it tries to get the cached copy of the definition from OracleAS Web Cache.
6. If there is a cache miss in OracleAS Web Cache, it checks if the portal cache has a valid cached copy
7. Finally, if no valid cached copy of the definition exists, then the OracleAS Metadata Repository generates a page definition from data in the portal repository
8. The PPE parses the page definition.
9. For each portlet on the page, the PPE checks if a cached copy of the portlet content exists in the portal cache or OracleAS Web Cache and then forwards a request to the appropriate provider, through Oracle AS Web Cache
10. Each provider either validates the cached portlet or generates content for the portlet. Web providers return this directly to the PPE using HTTP/S. Database (DB) providers return the results to the PPE through OracleAS Web Cache, Oracle HTTP Server, and Portal Services, using HTTP/S or SOAP
11. The PPE aggregates the content into a single page. This page is sent to Oracle AS Web Cache.
12. OracleAS Web Cache returns the final page to the client browser.
    

What is Oracle AS Portal?

Enterprise portals are the single entry point to business applications, content, collaborative tools, and Web sites. 

Oracle Portal, which is a component of Oracle Fusion Middleware, let the enterprises develop and deploy enterprise portals that are secure and scalable.