| Creation Date: | August 15, 2002 |
| Status: | Production |
| Version: | PDK Release 2, (9.0.2 and later) |
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:
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 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.
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.
This section describes the various security features that are available to secure your providers.
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.
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:
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.
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.
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 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 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 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 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 | ||||||
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
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.
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.
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.
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 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.
Portal Users are managed on the administer tab of Portal Builder. Users and their privileges can be managed from this page.
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.
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.
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.
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
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.
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.
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.
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:
For more information on the wallet manager and configuring Web Cache to use SSL, refer to:
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: |
|
| 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 |