Introduction

Ceptor is an entire security solution that protects portals and application servers, regardless of the communication type used, be it JSP, Servlets, EJB or other type of communication. Ceptor can provide Authentication and Authorization checking on all resources, as well as provide secure communication clients and servers.
Any number of web servers, application servers or other types of servers can be integrated, and used to create personalized content and session sharing between all applications, so users experience single signon with access (depending on authorization of course) to all applications available in your portal.
This document describes how to integrate Ceptor with Oracle WebLogic Platform v8.1 and above.

Overview

WebLogic's security can be extended by creating WebLogic Security Plugins, which uses Oracle's Security Services Provider Interface (SSPI). Ceptor provides plugins that integrates with these plugins.
Oracle provides documentation on their plugins in their WebLogic documentation – there you can find additional detail about the possibilities with them.
Ceptor implements several types of plugins, including Authentication, Authorization, RoleMapper and Adjudicator. Not all plugins need to be used, typically only the Authentication plugin is required.

Authentication Provider (All versions)

The Authentication provider provides authentication only – it is meant to be used in connection with the Ceptor Gateway. The gateway then inserts the session ID in an authorization http header, and WebLogic will then provide the Ceptors session ID to the plugin as userid, and the plugin will then use it for authenticating the user.

Identity Provider (All versions)

The Identity provider works together with the Authentication Provider, and picks up Ceptor's session ID from the request attributes.

Authorization Provider (WebLogic 8, 10, 11)

Ceptor's Authorization provider can make authorization decisions if the default J2EE way of authorizing based on deployment descriptors and roles is not sufficient. Any ACL defined in Ceptor will be checked against the corresponding WebLogic resource, which includes JNDI, EJB, JDBC and portlets. Please consult Oracle's documentation for details about the format of the WebLogic resources.

RoleMapper (WebLogic 8, 10, 11)

The RoleMapper is able to provide mapping between users and roles – this information is then used in e.g. HttpServletRequest.isUserInRole() calls by WebLogic. Ceptor will map group names directly to role names, if this plugin is installed.

Adjudicator (WebLogic 8, 10, 11)

The Adjudicator plugin is only required if multiple authorization plugins are installed, and decisions made by Ceptor's authorization plugin should be favoured above decisions made by other authorization plugins.

Installation of Security Providers

WebLogic 10/11

Installation is relatively straightforward, just copy the file wlPPSecurityProviders.jar to the directory /bea/weblogic81/server/lib/mbeantypes (or equivalent for your version) directory – there WebLogic will be able to see the new security providers.
Then, add the file wlPPprincipal.jar to the system classpath of this and all other weblogic instances that this weblogic server shares trust with. It contains a principal class that weblogic will serialize and send to other weblogic servers that it shares trust with.
Make sure that you also have CeptorAgent.jar, and log4j.jar in your classpath, or you will get a ClassNotFoundException when attempting to add the authenticator.

Note for WebLogic 10 and newer: Oracle WebLogic 10 is not compatible with earlier versions, so you need to use wl10PPSecurityProviders.jar instead of wlPPSecurityProviders.jar it has the same functionality for WebLogic 10.
For WebLogic 11, use wl11PPSecurityProviders.jar

In addition, you need to install the agent - an easy way is to copy these files into the domain lib directory:

CeptorAgent.jar
reload4j-1.2.20.jar
wlPPprincipal.jar
logback-core-1.2.10.jar
logback-classic-1.2.10.jar
slf4j-api-1.7.36.jar

WebLogic 12/14

The major difference between 12/14 and the earlier versions is that logging no longer requires log4j, but it uses SLF4j - same as the Ceptor Agent - and in addition a newer version of the SSPI interface is supported.
The authorization, rolemapper and adjudicator plugins are no longer present - instead, authorization relies solely on user/group membership supplied by Ceptor and is used with standard authorization plugins.

Copy the file wlPPSecurityProviders12.jar or wlPPSecurityProviders14.jar to the directory server/lib/mbeantypes directory – there WebLogic will be able to see the new security providers.
Then, add the file wlPPprincipal.jar to the system classpath of this and all other weblogic instances that this weblogic server shares trust with. It contains a principal class that weblogic will serialize and send to other weblogic servers that it shares trust with.

In addition, you need to install the Ceptor Agent and its dependencies - an easy way is to copy these files into the domain lib directory (be sure to use the appropriate version that might be different in your Ceptor release):

CeptorAgent.jar
wlPPprincipal.jar
logback-core-1.2.10.jar
logback-classic-1.2.10.jar
slf4j-api-1.7.36.jar

After installation of files is complete

Be sure to also supply the Ceptor Agent configuration - either in system properties or ptserver.properties file available in the classpath.

After restarting WebLogic, go to the administration console and add the authentication provider "PPAuthenticator" – first go to
_Security->Realms->myrealm->Providers->Authentication_
and then click on "Configure a new PPAuthenticator"



After clicking on "Configure a new PPAuthenticator" the following screen comes up, simple click on "Create" and that's it, the new Ceptor authenticator is now installed.

Now, make sure to change the "Control Flag" to "OPTIONAL" on the "DefaultAuthenticator" – otherwise WebLogic won't accept the PP Authenticators login.
In order to use the plugin, you need to configure the Ceptor gateway to add the Authorization header to the HTTP request before sending it to the WebLogic server – this will enable WebLogic to call the PP Authentication provider with the session ID as userid.
The PP Authentication provider will then look at the session, and if the user is authenticated, it will log him into WebLogic as well. Note that WebLogic will only see the user as authenticated, once his PP session is authenticated, so role-checking functions such as isUserInRole() will only work on authenticated users.

Application Requirements

WebLogic has a few bugs or at least odd behaviour related to security.

The most common problem is that unless an URL of an application is protected in its deployment descriptor, the security plugins will not be called at all. This means that the user will not be authenticated, and authorization checks will not be done.
Unfortunately, it also means that WebLogic will not provide information to the application about the authenticated user, even if he has authenticated previously in the same session – calls to getRemoteUser() and getUserPrincipal() will simply return null. This is true for both servlets and EJBs – if the code is not specifically protected in the deployment descriptor, then the security plugins will not get called, and the authentication information will not be available to the application.
This is why it is important for the application to be secured in the deployment descriptor.

Note that the behaviour has changed in WLS 8.1 SP6 – they claim to have it fixed, but in doing so they introduced another serious problem. In SP6 and newer (also Weblogic 12+) you can no longer send credentials to the server (such as sessionid:password) without those resulting in a successful login by the authentication providers. If you try, you will not even get access to unprotected resources, all requests will result in 401 Authentication Required, even if the authentication plugins are configured to be optional and anonymous access is allowed to the given resource. The authentication plugin cannot just login an anonymous user, because when the real user logs in, the auth plugins will not be called again thus weblogic will still believe that a user called "anonymous" or similar is logged in.

The only way around this problem (besides asking Oracle to fix this bug), is to configure the dispatcher to only send the "Authorization:" header to the weblogic server if the user is currently logged in.
Additionally, the weblogic specific deployment descriptor, weblogic.xml, must include the following line:
<auth-filter>dk.itp.portalprotect.wlsspi.PPAuthFilter</auth-filter>
This is required, for the Authentication plugin to get access to Ceptor's session cookie, when userid/password login is done programmatically, or using login forms.

For the WebLogic Portal Server to recognize and use Ceptors Authentication plugins, the following system property must be defined:

com.bea.p13n.usermgmt.AuthenticationProviderName = PPAuthenticator

To define this, add the following line to JAVA_OPTIONS in startWebLogic.sh or startWebLogic.cmd:

-Dcom.bea.p13n.usermgmt.AuthenticationProviderName=PPAuthenticator 

Administration

The Ceptor Authorization provider implements additional WebLogic MBeans for providing administration related information. It is able to list the groups and users defined in PP's database (if supported by Ceptor's own authentication and authorization plugins). Note however that only read-only access is available, users and groups cannot be created within the WebLogic Administration Console, or within the Portal Server Administration Portal – but users and groups and their group members can be listed.
WebLogic only supports viewing user ID or group name, not the other details defined in Ceptor.

Restrictions

The special groups pp_everyone and pp_anonymous cannot be used in the deployment descriptor, since roles/groups for anonymous users will not be visible to WebLogic until the user is authenticated. This is because WebLogic stops calling the authentication plugin after successful authentication, and because the plugin needs to provide the userid of the authenticated user to weblogic, it needs to wait until the user is really logged in.