# Oracle9iAS Portal Developer Kit (PDK)
An Overview of Portlet Security

Creation Date: | August 15, 2002
Status: | Production
Version: | PDK Release 2, (9.0.2 and later)

## Introduction

This article provides an overview of portlet security in the Portal Developers kit. It describe security terminology and the components/techniques that are available to secure providers (version 9.0.2).

Portlet Security features can be grouped into the following categories:

- Authentication
- Authorization
- Communication security

#### Authentication

When a user first accesses a secure url they must be challenged for a username and password to verify their identity before they are allowed access. This process is called Authentication.

#### Authorization

Authorization is the process that will allow certain users access to parts of an application. Some parts of an application may have public access and other parts may be only accessed only by a limited number of authenticated users.

#### Communication security

The means by which the communication are made secure.

In order to make your web provider truly secure, you need to make sure that your providers is secured in each of the above areas. If you only implement security features that cover 2 out of the 3, then your provider cannot be considered secure. Obviously, the effort you expend to secure a web provider should be proportional to the confidentiality of the data the provider exposes.

## Portlet Security Features

This section describes the various security features that are available to secure your providers.

### Authentication

When a user first logs in to a Portal instance they must enter their password to verify their identity before they are allowed access. This is done by the SSO server and is covered in the Single Sign On section.

### Authorization

The purpose of "authorization" is to determine if a particular user should be able to view or interact with a portlet. There are two types of Authorization check:

- Portal Access Control Lists (ACLs)
- Programmatic Portlet Security

#### Portal Access Control Lists (ACLs)

When you log into a Portal instance, you are authenticated by an Oracle Single Sign-On server instance. Once you are authenticated, Oracle Portal uses Access Control Lists (ACLs) to grant users privileges to perform actions on portal objects such as folders and portlets. The actions may range from simply being able to view an object to performing administrative functions. If you do not belong to a group that has been granted a specific privilege, Oracle Portal prevents you from performing the actions associated with that privilege.

#### Programmatic Portlet Security

The PDK-Java lets includes APIs that are called to determine if a particular user is authorized to view a portlet. You can use these APIs to implement authorization logic that augments the Portal ACL security.

These methods do not check the authenticity of messages being received by a provider and so are not suitable on their own for securing access to a provider.

### Communication

So far we have covered user authentication and authorization. This category concentrates on securing the communication between the portal and a web provider. These methods do not apply to database providers, which execute within the portal database. If the communication is not secured, it is possible for someone to imitate a portal and fool the web provider into returning sensitive information. There are 3 types of communication security:

- Portal Server Authentication
- Message Authentication
- Message Encryption

Portal Server Authentication and Message Authentication help to verify that messages being received by a provider come from a valid source but do not prevent the data being intercepted and read. Message Encryption prevents the contents of a message from

#### Portal Server Authentication

Portal Server Authentication restricts access to a provider to a small number of recognized machines. This method compares the IP address or the host name of an incoming HTTP message with a list of "trusted" hosts. If the IP address or host name is in the list, the message is passed to the provider. If not, it is rejected before reaching the provider.

#### Message Authentication

Message authentication works by appending a checksum based on a shared key to provider messages. When a message is received by the provider, the authenticity of the message is confirmed by calculating the expected value of the checksum and comparing it with the actual value received. If the values are the same, the message is accepted. If they are different the message is rejected without further processing. The checksum includes a time stamp to reduce the chance of a message being illegally recorded in transit and resent later

#### Message encryption

Message Encryption relies on the use of the HTTPS protocol for portal/provider communication. Messages are strongly encrypted to protect the data therein. Encryption provides a high level of security, but there is a performance penalty.

The table below summarizes the various security features and the category

| Security Feature
Single Sign-On | Portal ACLs | Programmatic Portlet Security | Portal Server Authentication | Message Authentication | HTTPS Communication
Authentication | x |  |  |  |  |
Authorization |  | x | x |  |  |
Communication | Portal Server Authentication |  |  |  | x | x |
Message Authentication |  |  |  |  | x |
Message encryption |  |  |  |  |  | x

.

## Single Sign On

Portlets act as windows into an application, display summary information, and provide a way to access the full functionality of the application. Portlets expose application functionality directly in the portal or provide “deep links” that take you to the application itself to perform a task.

An application may need to authenticate the user that is accessing the application. These are the possible application authentication

- Partner Application - The Application user is the same authenticated user used by Portal
- External Application - The Portal user is different from the application user but the application username and password are managed by the Portal user.
- None

### Partner Application

A partner application is an application that shares the same Single Sign-On Server as Oracle9iAS Portal for its authentication. This means that when a user is already logged into Oracle Portal, their identity can be asserted to the partner application without them having to log in again.

Partner applications are tightly integrated with the Oracle9iAS Single Sign-On Server. When a user attempts to access a partner application, the partner application delegates the authentication of the user to the Oracle9iAS Single Sign-On Server. Once a user is authenticated (i.e. has provided a valid username and password) for one partner application, the user does not need to provide a username or password when accessing other partner applications that share the same Single Sign-On Server instance. The Single Sign-On Server determines that the user was successfully authenticated and indicates successful authentication to the new partner application.

#### Advantages

- Provides the tightest integration with Oracle9iAS Portal and Oracle9iAS Single Sign-On Server.
- Provides the best Single Sign-on experience to users.
- Provides the most secure form of integration because usernames and passwords are not transmitted between the portal and the provider.

#### Disadvantages

- The application must share the same user repository as the portal even though the application’s user community
  may be a subset of the portal user community. This is a minor issue because the portal pages that expose the
  application can easily be restricted to the application’s user community.
- The application can only be tightly integrated to one or more Single Sign-On Servers, if they share the same user
  repository.

### External Application

An External Application is an application that uses different Authentication server to Oracle9iAS Portal. The application may use a different instance of Single Sign-On Server used by Oracle9iAS Portal or some other authentication method. However the Single Sign-On Server does store the username and password of the external application for that user. This means that when a user is already logged into Oracle Portal, they will be logged into the external application without having to type in their username or password.

Applications that manage the authentication of users can be loosely integrated with the Oracle9iAS Single Sign-On Server by registering the applications as external applications. When a user who has been previously authenticated by the Single Sign-On Server accesses an external application for the first time, the Single Sign-On Server attempts to authenticate the user with the external application. The authentication is performed by submitting an HTTP request that combines the registration information and the user’s username and password for the application. If the user has not yet registered their username and password for the external application, the Single Sign-On Server prompts the user for the required information before making the authentication request. When a user supplies a username and password for an external application, the Single Sign-On Server maps the new username and password to the user’s portal username and stores them. They will be used the next time the user needs authenticating with the external application.

#### Advantages

- Allows integration with many portals. However, if there is a "preferred" portal, the application could be integrated as a partner application of that portal and an external application of other portals.
- Provides a Single Sign-On experience for users. However, users still need to maintain different usernames and passwords. In addition, the external application username mapping must be maintained.
- Allows integration with multiple portals independent of their user repositories and Single Sign-On Servers.

#### Disadvantages

- External applications do not share the same user repository as the portal. There is additional maintenance of user information.
- The username and password is transmitted to the provider in plain text. This approach is not as secure as a partner application.

### None

In this case the provider trusts the portal sending the requests. The provider can determine if the user is logged in, the portal user name but the application has not authenticated the user.

#### Advantages

- The easiest form of integration and the fastest to implement.

#### Disadvantages

- Provides the weakest integration with Oracle9iAS Portal.

## Portal Access Control Lists (ACLs)

When you log into a Portal instance, you are authenticated by an Oracle Single Sign-On server instance. Having verified your identity during login, Oracle Portal uses Access Control Lists (ACLs) to determine if you are authorized to view each piece of Portal content, including Providers and Portlets. If you do not belong to a group that has been granted a specific privilege, Oracle Portal prevents you from performing the actions associated with that privilege.

Portals ACLs are managed using:

#### Privileges

Privileges define the actions that can be performed onto the object they are granted too. There are several privileges that can be granted such as Managed, Execute, Access and Publish. If any of these privileges are set then the user can access to the portlet.

#### Users

Portal Users are managed on the administer tab of Portal Builder. Users and their privileges can be managed from this page.

#### User Groups

Portal User Groups are managed on the administer tab of Portal Builder. User membership of the group and privileges granted to the group are managed here. A privilege granted to a user group is inherited to all the users of that group.

#### Provider

Privileges can be granted to a Provider. By default those privileges apply to the provider and all the portlets in the provider. Provider ACLs are managed on the Provider tab of the navigator.

#### Portlet

Privileges for Portlets can override the privilege set at the Provider of the Portlet. Portlet ACLs are managed on the Provider tab of the navigator. Using the open link for the Provider goes to a page to manage the portlets of the provider.

#### Advantages

- ACLs offer a simple, yet very powerful, mechanism to secure Portal objects.
- Since the management of users and groups is centralized, as the membership of groups changes you do not have to worry about modifying the ACLs associated with each portal object.

#### Disadvantages

- ACLs are applied at the provider or portlet level. You cannot vary the security rules for a portlet depending on the portal page an portlet is placed on.

## Programmatic Portlet Security

These are implemented within a provider and are used to verify that given users may access portlet instances. They work at the portlet level, i.e. each portlet may have its own user access control. By implementing a access control methods in the provider, content may only be retrieved from a portlet if user details are supplied that pass the authorization logic. If no Portlet Security methods are implemented in the provider any username may be passed in, even fictitious names that are not even portal users or have not been authenticated by a portal.

A provider can implement two Portlet Security Methods

- get a list of portlets
- Is portlet accessible

These Portlet Security methods have access to the following information about authorization level.

- Strong - user has been authenticated by the SSO server in the current Portal session, i.e. the user has logged in to the Portal instance with a valid username/password combination, and is calling the portlet in the context of that session.
- Weak - 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 in by supplying a valid username/password combination
- Public - a user has not logged in within the context of the current Portal session, and does not have a persistent cookie to indicate that such a state previously existed.

Portlets also have access to the Portal User privileges and the portal groups the Portal user is a member of. The following information can be used

- The default group that the user belongs too
- The privileges of a user or group
- The highest available privilege of a user across all groups
- The objects the user can access

#### Advantages

- Enables a Portlet to produce different output depending on the level of autherization.

#### Disadvantages

- Most security manager implementations will use the authorization level or some other user specific element in an incoming message. A check of this type could be bypassed by an entity imitating a portal instance.

## Portal Server Authentication

One way to prevent unauthorized access to providers is to restrict access to the provider to known client machines at the server level. This method goes some way towards defending against denial of service attacks.

In the Oracle HTTP Server this is achieved using the allow and deny directives in the httpd.conf file to control access to client machines based on their host names or IP addresses. If host names are used as discriminators the server needs to look them up on its Domain Name Server which will add extra overhead to the processing of each request. Using the IP address will prevent this but the IP address of a remote client may change without warning.

#### Advantages

- Limit the number of hosts that can access the provider to trusted hosts
- Simple to set up

#### Disadvantages

- Webcache does not have IP address checking capability. So if webcache is used in front of a provider there is no protection from a client on any host sending show requests to webcache.
- Restricting access to certain IP addresses and host names may be circumvented by sending messages to a provider containing fake IP addresses and host names. This is tricky to do effectively since return messages go to the machine whose IP address has been copied, but it can still cause problems.

## Message Authentication

The PDK supports message authentication so that access may be limited to a specified provider instance or group of provider instances. A provider is registered with a secret shared key known only to the Portal and provider administrators.

The Portal instance sends a digital signature, calculated using a Hashed Message Authentication Code (HMAC) algorithm, with each message to a provider. A provider may authenticate the message by checking the signature using its own copy of the shared key. This technique may be used in Secure Socket Layer communication with a provider instead of client certificates.

A Portal instance calculates a signature based on user information, a shared key and a time stamp. The signature and time stamp are then sent as part of the SOAP message. The time stamp is based on UTC (coordinated universal time, the scientific name for Greenwich Mean Time) so that timestamps can be used in messages between computers in different timezones.

When the provider receives this message it will generate its own copy of the signature. If the signatures agree, it will then compare the message time stamp with the current time. If the difference between the two is within an acceptable value the message is considered authentic and is processed accordingly.

A single provider instance can not support more than one shared key. This could cause security and administration problems if several clients sharing a provider use the same key. For instance, if one copy of the shared key is compromised in some way the provider administrator has to create a new key and then get it to all of the Portal clients who then have to update their provider definition. The way around this is to deploy different provider services, specifying a unique shared key for each service. Each provider service has its own deployment properties file so that each service is configured independently of the others. The overhead of deploying multiple provider services within the same provider adapter is relatively small.

In a provider which does not have a Web Cache instance in front of it, this use of the same signature cookie over the lifetime of a provider session means there is a trade off between performance in terms of speed and the security provided by authenticating the requests. The signature cookie value is only calculated once after the initial SOAP request establishes the session with the provider. The shorter the provider session timeout, the more often a signature will be calculated providing greater security against a show request being resent illegally. However, the SOAP request required to establish a session between a Portal instance incurs a time penalty.

In a provider which is using Web Cache to cache show request responses, there is a similar trade-off. Cached content is secured in the sense that incoming requests must include the signature cookie to retrieve it but caching content for an extended period of time will leave the provider open to illegal show requests.

While the signature element provides protection against interception and resending of messages it does nothing to prevent interception and reading of message contents. Messages are still transmitted in plain text. If you are concerned about the content of messages being read by unauthorized people, you should use message authentication in conjunction with SSL.

#### Advantages

- Ensures that the message received by a provider comes from a legitimate Portal.

#### Disadvantages

- Can cause administer problems if a provider serves more than one Portal.
- Has a performance implication if made very secure by having a short session timeout.

## HTTPS Communication

Normal communication between a Portal and provider uses HTTP - a network protocol that transmits data as plain text using TCP as the transport layer. It is possible for an unauthorized agent to read an intercepted message. HTTPS uses an extra secured layer (SSL) on top of TCP to secure communication between a client and a server.

Each entity (for example, a Web Cache instance) receiving a communication using SSL has a freely available public key and a private key known only to the entity itself. Any messages sent to an entity are encrypted with its public key. A message encrypted by the public key may only be decrypted by the private key so that even if a message is intercepted by a felonious third party it can not be decrypted.

Certificates are used to sign communications, thereby ensuring that the public key that is used does in fact belong to the correct entity. These are issued by trusted third parties, Certification Authorities (CA), e.g. Verisign. They contain an entity's name, public key and other security credentials and are installed on the server end of a SSL communication to verify the identity of the server. Client certificates may also be installed on the client to verify the identity of a client but this is not supported in Portal 9.0.2. Message authentication may be used instead.

Oracle Wallet Manager is the application used to manage public key security credentials. It is used to generate public/private key pairs, create a certificate request to a CA and then install the certificate on a server.

### Configuration of SSL

When a provider is registered from a Portal instance only one url is entered, so either HTTP or HTTPS may be used, not a combination of both.

Each port on each server that may be used to receive SSL messages must have a server side certificate installed, i.e. the Web Cache instance (if any) in front of the web provider and the server which hosts the provider. The certificate installed on a server port ensures that communication between two points is encrypted but does not authenticate the source of a message. Message authentication should be used as well to fully secure communication between a trusted Portal instance and a provider.

For more details on SSL configuration in the Portal infrastructure refer to:

- Oracle9iAS Portal Configuration Guide

For more information on the wallet manager and configuring Web Cache to use SSL, refer to:

- Oracle Wallet Manager appendix in the Oracle Internet Directory Administrator's Guide (Oracle9i Application Server Documentation Library)
- Oracle9iAS Web Cache Administration and Deployment Guide (Oracle9i Application Server Documentation Library)

#### Advantages

- Encrypts the contents of a Portlet.

#### Disadvantages

- This has a performance impact on Portal.
- If used all portlets from a provider must use HTTPS even if some of the content is public.

## SUMMARY

A number of methods have been described in this document for securing providers, any combination of which may be used depending on the environment in which the web provider is installed. The choice of techniques is affected by a number of factors including the effort required to install and maintain them and any performance overhead that they may impose on a provider.

User authentication and access restriction methods are used to ensure that only authorized users have access to certain portlets. Portal server authentication and message authentication come into play to ensure that a provider only receives messages from trusted sources and that the messages are not resent illegally. Using one or more user authorization techniques in addition to SSL and message authentication provides the greatest level of security.

Revision History: |
Revision No | Last Update
1.0 | August 22, 2002

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065, USA http://www.oracle.com/ | Worldwide Inquiries: 1-800-ORACLE1 Fax 650.506.7200 | Copyright and Corporate Info