...

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 BEA Oracle WebLogic Platform v8.1 and above.

...

WebLogic's security can be extended by creating WebLogic Security Plugins, which uses BEAOracle's Security Services Provider Interface (SSPI). Ceptor provides plugins that integrates with these plugins.
BEA Oracle provides documentation on their plugins at http://e-docs.bea.com – 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.

...

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 BEAOracle's documentation for details about the format of the WebLogic resources.

...

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.
Similar files are support for WebLogic 11, which also works with WebLogic 12.

...

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 BEA 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.

...