Introduction
Ceptor PortalProtect 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. PortalProtect 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 PortalProtect Ceptor with BEA WebLogic Platform v8.1 and above.
...
WebLogic's security can be extended by creating WebLogic Security Plugins, which uses BEA's Security Services Provider Interface (SSPI). PortalProtect Ceptor provides plugins that integrates with these plugins.
BEA provides documentation on their plugins at http://e-docs.bea.com – there you can find additional detail about the possibilities with them.
PortalProtect 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.
...
The Authentication provider provides authentication only – it is meant to be used in connection with the PortalProtect Tunnel agentCeptor Gateway. The tunnel gateway then inserts the session ID in an authorization http header, and WebLogic will then provide the PortalProtect Ceptors session ID to the plugin as userid, and the plugin will then use it for authenticating the user.
Authorization Provider
PortalProtectCeptor'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 PortalProtect Ceptor will be checked against the corresponding WebLogic resource, which includes JNDI, EJB, JDBC and portlets. Please consult BEA's documentation for details about the format of the WebLogic resources.
...
The RoleMapper is able to provide mapping between users and roles – this information is then used in e.g. HttpServletRequest.isUserInRole() calls by WebLogic. PortalProtect Ceptor will map group names directly to role names, if this plugin is installed.
...
The Adjudicator plugin is only required if multiple authorization plugins are installed, and decisions made by PortalProtectCeptor's authorization plugin should be favoured above decisions made by other authorization plugins.
...
Installation is relatively straightforward, just copy the file wlPPSecurityProviders.jar to the directory /bea/weblogic81/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.
Make sure that you also have PortalProtectAgentCeptorAgent.jar, and log4j.jar in your classpath, or you will get a ClassNotFoundException when attempting to add the authenticator.
Note for WebLogic 10: 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.
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 PortalProtect 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 PortalProtect tunnel 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.
...
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 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 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 PortalProtectCeptor's session cookie, when userid/password login is done programmatically, or using login forms.
For the WebLogic Portal Server to recognize and use PortalProtects 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 PortalProtect 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 PortalProtectCeptor'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 PortalProtectCeptor.
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.