Adding Security to Java Portlets

Oracle9iAS Portal Developer Kit
Adding Portlet Security to Java Portlets

PDK Release 2 (9.0.2 and later) - Java

In previous articles, you learned how to use the PDK Framework to render portlet content for various render modes and how to implement features such as customization and session storage. This article shows you how to implement security services for your portlet. You have already learned that to generate visual content a portlet employs a controller object, a PortletRenderer. To implement security services, a portlet employs another controller object - a PortletSecurityManager.

In this article, you employ a PortletSecurityManager to secure access to the Java portlet you created in the article How to Build a Java Portlet. Once you have completed this article, you will understand how to add security services to any Java portlet declaratively. For more detailed information about the PDK classes referred to in this article, please refer to the Javadoc.

ASSUMPTIONS

You have followed through and understood the article How to Build a Java Portlet.
All the assumptions in the above article apply here too.

UNDERSTANDING PORTLET SECURITY MANAGERS

The PDK class oracle.portal.provider.v2.security.PortletSecurityManager defines a contract to which all PortletSecurityManagers must adhere. Two method implementations must be supplied, they are:-

```
public boolean hasAccess(ProviderInstance pi, PortletDefinition def, ProviderUser user)
```
This overload allows access rights to be checked at the PortletDefinition level, i.e. when there is no PortletInstance object present in the context of the method call. This would be the case, for example, when browsing the portlet repository to decide which portlets to add to a page.
```
public Boolean hasAccess(PortletReference ref, ProviderUser user)
```
This overload allows access rights to be checked for a particular user viewing a particular PortletInstance, i.e. a portlet that has been added to a Portal page.

Such security managers may be called at any time to check whether or not a particular user is allowed access to a particular portlet. If a portlet is declared to have a security manager, the PDK runtime will check access before performing operations such as PortletInstance.register() (when a user attempts to add a portlet instance to a page) and PortletInstance.copy() (when a user attempts to copy a portlet instance). Furthermore, if the portlet uses the flexible RenderManager sub-framework, access rights are automatically checked before any ManagedRenderers are invoked to generate portlet content.

The PDK supplies two implementations of PortletSecurityManager in the security package: AuthLevelSecurityManager and DenyAllSecurityManager. You may utilize these security managers or develop your own if you have specific needs. The latter of these two implementations simply denies access to all users and is useful for testing out security features.

In this example you will use AuthLevelSecurityManager to deny access to your Java portlet to all but strongly authenticated Portal users, i.e. only those users who are logged in to Portal in the current session are permitted to view the portlet contents. AuthLevelSecurityManager, in the oracle.portal.provider.v2.security package, decides access rights based on how the user in context has been authenticated by the Single Sign-On (SSO) server associated with the Portal instance. It understands the following levels of authentication:-

Strongly authenticated.

The user has been authenticated by the SSO server in the current Portal session, i.e. the user has logged into the Portal instance with a valid username/password combination, and is calling the portlet in the context of that session.
Weakly authenticated.

A previously strongly authenticated user returns to view a Portal page without having an active Portal session. A persistent cookie (persisted by the user's browser) indicates to Portal that in some previous session the user had logged on by supplying a valid username/password combination.
Not-authenticated.

The user has not logged in within the context of the current Portal session, or doesn't have a persistent cookie to indicate that such a state previously existed.

To incorporate these security services into your Java portlet, you simply need to update the XML provider definition.

UPDATING THE XML PROVIDER DEFINITION

Incorporating a security manager into a portlet is a simple, declarative process. You just need to add a new 'controller' element for the portlet in question:

Using your favorite text editor, open the XML provider definition you created in the article How to Build a Java Portlet.

Add a securityManager element whose class attribute is oracle.portal.provider.v2.security.AuthLevelSecurityManager.

This security manager expects a child element called securityLevel to be set to either strong, weak or public. For this example, set it to strong. The additions to the XML provider definition are shown in bold below.

<?xml version="1.0" encoding="IS0-8859-1" standalone="yes"?>
<?providerDefinition version="3.1"?>
<provider class="oracle.portal.provider.v2.DefaultProviderDefinition">
  <session>true</session>
  <portlet class="oracle.portal.provider.v2.DefaultPortletDefinition">
    <id>1</id>
    <name>MyFirstPortlet</name>
    <title>My First Portlet</title>
    <shortTitle>MyFirstPortlet</shortTitle>
    <description>My first ever portlet, using my own custom renderer</description>
    <timeout>10</timeout>
    <timeoutMessage>Timed out waiting for MyFirstPortlet</timeoutMessage>
    <renderer class="oracle.portal.provider.v2.render.RenderManager">
      <showPage class="MyCustomRenderer"/>
    </renderer>
    <securityManager class="oracle.portal.provider.v2.security.AuthLevelSecurityManager">
      <securityLevel>strong</securityLevel>
    </securityManager>
  </portlet>
</provider>

Save the updated XML provider definition file.
Restart your Webserver and re-access the provider's test page.
If you can view the test page, the XML syntax is correct.

Next you can demonstrate the new security features of your Java portlet.

VIEWING THE PORTLET

To demonstrate the behavior of the security manager added to MyFirstPortlet, follow these steps:

Ensure you are logged in to an Oracle9iAS Portal instance with privileges to create pages and add portlets to a page.
Create a new Portal page, ensuring it is displayable to 'PUBLIC' (if you are using Oracle9iAS Portal version 9.0.2, you may need to create a page group first).
Add the portlet MyFirstPortlet to the page.
Make a note of the direct URL to your new Portal page.
Now log out of the Portal instance by clicking the Logout link.
Directly access the Portal page by entering the URL noted in Step 4 into your browser's address bar.

You will see the Portal page created in Step 2 but not the portlet added in Step 3. When you added the portlet to the page, you were logged in and hence strongly authenticated. The PDK runtime detected this and allowed you to add the portlet. When you logged out and viewed the page, you were no longer strongly authenticated and hence the PDK Framework did not allow rendering of the portlet's contents.

If you login to the Portal instance again and view the page, you will see that the portlet is still there!

IMPLEMENTING YOUR OWN SECURITY MANAGER

If your portlet requires special security arrangements which are not provided by the implementations shipped with the PDK, you will need to supply your own custom PortletSecurityManager controller class. To do this, simply extend the oracle.portal.provider.v2.security.PortletSecurityManager class and supply implementations for the two methods that the contract specifies. Then simply replace the class attribute of the securityManager controller element in the XML provider definition with you new class name and configure child elements appropriately.

Revision History:

January 21st, 2002
April 24, 2002.