Oracle9iAS Portal provides an extensible set of privileges that can be accessed when creating portlets using PDK-Java.  Portlet security refers to the techniques and methods used by portlets to control and grant access to Oracle9iAS Portal users.  Authentication is the process of a user identifying itself to the system and the system verifying that the information given is correct.  Normally, portlets handle security and leave the actual authentication to Oracle9iAS Portal.  Using portlet security, you can specify access controls programmatically using APIs and check for the appropriate privileges at portlet runtime. 

Key Features

Portlet security is handled at two main points in Oracle9iAS Portal.  It is used when a user view the list of portlets available from a provider.  It is also used when rendering the portlet on a portal page.  The two methods used for this type of portlet security is get_portlet and get_portlet_list. To handle security from the provider, PDK-Java provides the following features:

Portlet Display

Before a portlet is displayed on a page, the provider can check to see if the portal user has the specific level of privileges to access a portlet.  To retrict portlet access using PDK-Java, you must implement PortletSecurityManager.  A PortletSecurityManager is the access controller for a portlet. If the Portlet restricts its capabilities in any manner it implements a PortletSecurityManager. The manager is responsible for authorizing (but not authenticating) the user. 

There are two authorization levels. The first level checks whether the user is authorized to use this Portlet. The second level checks whether the user is authorized to use a particular instance of this Portlet.   PDK-Java provides a default implementation of PortletSecurityManager called DefaultSecurityManager.

DefaultSecurityManager is a simple access controller for a portlet that uses a user's authentication level to control access. A user will be granted access to a portlet if his/her authentication level is greater than or equal to the security level that has been specified for the security manager. 

If you do not specify a security level for the security manager, it will default to the most secure level of operation.  

DefaultSecurityManager

The DefaultSecurityManager allows you to set security for a particular portlet.  It allows you to set security levels and check access.  Oracle9iAS Portal providers an extensible set of privileges which are used to define the access control lists.  Privileges are ranted within a given object type and higher privileges subsume all privileges below them.  This hierarchical or cumulative behavior allows the portlet to check whether or not a given user has a high enough level of security to view the portlet.  The following section describes the methods contained within the DefaultSecurityManager.

hasAccess(Portlet p, ProviderUser user)

Verifies that the specified user's authentication level is greater than or equal to the specified security threshold.  This method is called when the before portlet rendering.  

It takes in the portlet we want to authorize and the user requesting authorization.  It returns a boolean value of whether the user is authorized to access this portlet.


hasAccess(PortletRenderence ref, ProviderUser user) throws PortletNotFoundException

Verifies that the specified user's authentication level is greater than or equal to the specified security threshold.  This method is called during rendering of the portlet instance.  

It takes in the portlet instance we want to authorize, the user requesting authorization.  It returns a boolean value of whether the user is authorized to view this portlet instance.

setSecurityLevel(java.lang.String level)

Sets the security threshold for this security manager.  This version of the method is intended for use by Providers that are initialized via the provider.xml file and it supports a reduced subset of the authentication levels for simplicity.  It takes in the following parameters:

STRONG - public static final java.lang.String STRONG

WEAK - public static final java.lang.String WEAK

PUBLIC - public static final java.lang.String PUBLIC

setSecurityLevel(int level) throws java.lang.IllegalStateException

Sets the security threshold for this security manager. This version of the setSecurityLevel method supports the full range of security levels supported by the Portal. It takes in an integer representation of the security level.

Session Management

The HTTP protocol is a stateless protocol.  As a result, anyone developing web-based applications needs to address the issue of how to maintain a persistent state for a given user.  A common approach to address this problem is to use cookies.  Cookies allow you to store and retrieve information about a given user.  Using PDK-Java, you must set cookie information from within the provider.  Currently, the DefaultProvider creates one servlet session.  To create additional sessions or address session management, subclass the DefaultProvider and override the init() method.  Please review, Understanding the Default Provider, for more information on handling sessions.

JDBC 

Portlets using PDK-Java can use JDBC to make connections to the database.  JDBC is not the most common or recommended approach to portlet security, but it is often used when creating portlets that also reside as applications to portal.  Such cases are:  Partner Applications and External Applications.

Partner Applications are applications that have delegated their authentication processing to the Login Server, and enable Single Sign-On with the Login Server by implementing  a specified protocol for obtaining the authentication information.

External Applications are applications that continue to maintain their authentication logic and do not consciously interact with the Login Server.

Both of these types of applications must connect may connect to the database using JDBC to use APIs and procedures of the SSO SDK.  Here is must authenticate with portal from the database level as well as from the user level.

Revision History

• June 4, 2001.