Tip: Interpretation of missing EJB Method Permissions in JBoss

The EJB 2.1 specs on this case says:

"It is possible that some methods are not assigned to any security roles nor contained in the exclude-list element. In this case, it is the responsibility of the Deployer to assign method permissions for all of the unspecified methods, either by assigning them to security roles, or by marking them as unchecked."

What this basically means is that if you have not specifically assigned method permissions or made them "unchecked", then it is left to the vendor's interpretation.

Default interpretation of missing method permissions in JBoss is "excluded" mode.


Based on JBAS-2471, we have incorporated a jboss.xml setting that will provide the appropriate interpretation of missing method permissions - whether to interpret them as "exclude" or "unchecked".

=======================================

<!-- The missing-method-permissions-excluded-mode determines the treatment
of missing method-permission mappings in the ejb-jar descriptor. The ejb 2.1
spec states: "It is possible that some methods are not assigned to any security
roles nor contained in the exclude-list element. In this case, it is the
responsibility of the Deployer to assign method permissions for all of the
unspecified methods, either by assigning them to security roles, or by marking
them as unchecked." The missing-method-permissions-excluded-mode is a boolean
that allows the deployer to globally indicate that all methods without a
method-permission element should be treated as excluded(= true and the default),
or that methods without a method-permission element should be treated as
unchecked(= false)

<missing-method-permissions-excluded-mode>true</missing-method-permissions-excluded-mode>
<missing-method-permissions-excluded-mode>false</missing-method-permissions-excluded-mode>

-->
<!ELEMENT missing-method-permissions-excluded-mode (#PCDATA)&rt;
===========================

First Case:
In the first case, if you specify:
<missing-method-permissions-excluded-mode>true</missing-method-permissions-excluded-mode>

in your jboss.xml, then all methods that do not have an associated method-permission are excluded from the deployment.

Second Case:
In the second case, if you specify:
<missing-method-permissions-excluded-mode>false</missing-method-permissions-excluded-mode>
in your jboss.xml. then all methods that do not have an associated method-permission are operating in an unchecked mode.

Reference:
1. Discussion on ejb3 interpretation of this flag. (Under investigation)
2. Default setting in standardjboss.xml

Tip: Role Mapping in JBoss Application Server v5.x

If you are interested in mapping roles at the deployment level (such as EARs, WARs, EJB Jars) to the roles deduced at the security domain level, then you should read this article: http://community.jboss.org/wiki/MappingRolesinJBossApplicationServerv5x

Note the use of org.jboss.security.mapping.providers.DeploymentRolesMappingProvider

Note: This is an additional forced interpretation of role mapping for the containers when our normal regular interpretation is deployment roles for addition into a RunAs identity.

Tip:: Use of "Java:/jaas" prefix in security-domain element

As of JBoss AS 5.0.0, the security domain configuration in jboss.xml and jboss-web.xml can just be the name of the security domain and the "java:/jaas" prefix is optional.

So the following:
================
<jboss>
<security­domain>java:/jaas/test-domain</security­domain>
</jboss>
===========

can be simplified as:
================
<jboss>
<security­domain>test-domain</security­domain>
</jboss>
===========

If there are issues, tell us via user forums.

TIP:: Souce code for JBoss AS Security

If you are wondering where the source code for the security subsystem in JBoss AS 5.x (and also EAP 5.x) is, then you will need to look at the following locations:

Security Integration Code:
1. security module of the JBoss AS workspace.
2. Security SPI
3. JBossSX

The location of the source can be found from:
JBoss AS workspace:
http://anonsvn.jboss.org/repos/jbossas/

Security SPI:
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-spi/tags/2.0.4.SP3/

JBossSX:

http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/tags/2.0.4.SP3/


Additional Note:
There are two security projects integrated into JBAS5/EAP5.x, namely JBossXACML and JBoss Negotiation.

You can get their source from here:
JBossXACML: http://anonsvn.jboss.org/repos/jbossas/projects/security/security-xacml/tags/2.0.4/
JBoss Negotiation: http://anonsvn.jboss.org/repos/jbossas/projects/security/security-negotiation/tags/security-negotiation-2.0.3.SP1/

TIP::JBossXACML Logging

If you are interested in seeing the trace messages of the PDP engine in JBossXACML, you will need to add the following line to the logging.properties file in use for your setup.

# Set the default logging level for the logger named org.jboss
org.jboss.security.xacml.sunxacml.level = FINEST


If you are running it in Apache Tomcat, then the file is in conf directory.
In JBoss Application Server, you should just add a trace category in the conf/jboss-log4j.xml


The trace messages will be found in the logs of your server.

HTTPOnly Cookies in Tomcat/JBoss

There are concerns that client side scripts should not be able to access the cookies sent by the server. Toward this, the HTTPOnly cookie was invented by Microsoft Internet Explorer and has been reasonably adopted by other browsers and the public.

Read more about it at the OWASP site: http://www.owasp.org/index.php/HTTPOnly

Tomcat has a flag on the Context element which you can either place it in WEB-INF/context.xml (JBoss) or META-INF/context.xml (Tomcat) to utilize this feature.

Reference: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

So look for examples of context.xml by google search and then add the "useHttpOnly=true" to the context element.

Jazoon09: Secure Middleware with JBossAS5.x

I have had the privilege of presenting at Jazoon 2009 in Zurich. My presentation ended a couple of hours ago.

My presentation slides are here.

Please refer to the reference urls in the slides to get more details.

At this moment, I am sitting in the presentation by Dimitris on "JBoss AS5 and Beyond". I am sure you can get more information from his blog.

JBoss AS 5.1 Security Features

Now that the JBoss AS 5.1 has been released to the community, it is time to talk more about the exciting new Security features available. Toward this end, I have written the following DZone Articles that will be published over the month of June.



1. Security Features of JBoss AS 5.1.0 - Part 1 - Simplified Security Domain Configuration
2. Security Features of JBoss AS 5.1.0 - Part 2 - Masking Passwords in the Configuration File
3. Security Features of JBoss AS 5.1.0 - Part 3 - XACML Authorization for EJB Applications
4. Security Features of JBoss AS 5.1.0 - Part 4 - XACML Authorization for WEB Applications
5. Security Features of JBoss AS 5.1.0 - Part 5 - Instance Based Authorization

So if you are interested in XACML, Instance Based Security with JBoss or want to mask passwords in the xml configuration files, read these articles.

Also Security Auditing Feature in AS5 is:
http://server.dzone.com/articles/security-auditing-jboss

AS5: Specifying Security Domain Configuration

Historically, JBoss AS has provided the DynamicLoginConfig service to specify your security domain configuration (JAAS login modules). Starting JBoss AS 5.0, we provide a simplified xml version of that as follows:

You will need to create a xxx-jboss-beans.xml file and then you can define your login modules as follows:
===================================
<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns="urn:jboss:bean-deployer:2.0">

<application-policy xmlns="urn:jboss:security-beans:1.0" name="web-test">
<authentication>
<login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name = "unauthenticatedIdentity">anonymous</module-option>
<module-option name="usersProperties">u.properties</module-option>
<module-option name="rolesProperties">r.properties</module-option>
</login-module>
</authentication>
</application-policy>

<application-policy xmlns="urn:jboss:security-beans:1.0" name="ejb-test">
<authentication>
<login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name = "unauthenticatedIdentity">anonymous</module-option>
<module-option name="usersProperties">u.properties</module-option>
<module-option name="rolesProperties">r.properties</module-option>
</login-module>
</authentication>
</application-policy>

</deployment>


==================================

We still support the DynamicLoginConfig mbean definition approach also. But the afore mentioned approach is simpler.

DZone Article: http://server.dzone.com/articles/security-features-jboss-510

Frequently Asked Questions:
1. Where do I place the xxx.properties files for the UsersRolesLoginModule?
You can place them under the conf directory.

AS5.1: Specifying custom call back handler

In JBoss Application Server v5.1, you can specify a custom call back handler to be used in authentication in any of the following 3 ways:

1) Specify an attribute "CallbackHandlerClassName" in the JaasSecurityManagerService mbean definition in conf/jboss-service.xml

http://www.jboss.org/community/wiki/JaasSecurityManagerService

2) Specify a system property with the fully qualified class name of the call back handler

-Dorg.jboss.security.callbackhandler=org.somefqn

3) Inject an instance of the callback handler into the JNDISecurityManagement bean in the deploy/security/security-jboss-beans.xml

=================================================================================
<bean name="MyCustomCBH" class="fqn of your class" />

<bean name="JNDIBasedSecurityManagement"
class="org.jboss.security.integration.JNDIBasedSecurityManagement">
<property name="callBackHandler">'<inject bean="MyCustomCBH"/></property>
</bean>
=================================================================================

Unfortunately, the custom callback handler feature is broken in JBoss AS5.0, 5.0.1 and was fixed in JBAS-6747
NOTE: JBAS-6747 is fixed.

AS5: JSR-196 Integration: Web Http Basic Auth

Objective: Provide JSR-196 integration for the web layer to do Http Basic Authentication

Step 1: Configure your web.xml for basic authentication. An example:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd">
<security-constraint>
<web-resource-collection>
<web-resource-name>Home</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>architect</role-name>
</auth-constraint>
</security-constraint>

<login-config>
<auth-method>BASIC</auth-method>
<realm-name>JASPI</realm-name>
</login-config>

<security-role>
<role-name>architect</role-name>
</security-role>
</web-app>

Step 2: Configure your-web-app/WEB-INF/context.xml

<Context>
<Valve
className="org.jboss.web.tomcat.security.jaspi.TomcatJASPIAuthenticator" />
</Context>

Step 3: You will need to configure the security domain for your web application in jboss-web.xml

<jboss-web>
<security-domain>java:/jaas/jaspi-test</security-domain>
</jboss-web>


Step 4: Outside of your web application, we will need a xxx-jboss-beans.xml to configure your JSR-196 modules. An example would be jaspi-webbasic-jboss-beans.xml

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns="urn:jboss:bean-deployer:2.0">

<application-policy xmlns="urn:jboss:security-beans:1.0"
name="jaspi-test">
<authentication-jaspi>
<login-module-stack name="lm-stack">

<login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag="required">

</login-module>
</login-module-stack>

<auth-module code="org.jboss.web.tomcat.security.jaspi.modules.HTTPBasicServerAuthModule" login-module-stack-ref="lm-stack"/>
</authentication-jaspi>
</application-policy>

</deployment>

What this does is defines a JASPI configuration block with an ServerAuthModule that is capable of doing tomcat form authentication. In this case, we also define a login context delegation structure called lm-test.

Reference: Test Case : WebJASPIBasicUnitTestCase.java

AS5: JSR-196 Integration: Web Form Auth

Objective: Provide JSR-196 integration for the web layer to do Form Authentication

Step 1: Configure your web.xml for form authentication. An example:

<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd">
<security-constraint>
<web-resource-collection>
<web-resource-name>Home</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>architect</role-name>
</auth-constraint>
</security-constraint>

<login-config>
<auth-method>form</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>

<security-role>
<role-name>architect</role-name>
</security-role>
</web-app>


Step 2: Configure your-web-app/WEB-INF/context.xml

<Context>
<Valve
className="org.jboss.web.tomcat.security.jaspi.TomcatJASPIAuthenticator" />
</Context>

Step 3: You will need to configure the security domain for your web application in jboss-web.xml

<jboss-web>
<security-domain>java:/jaas/jaspi-test</security-domain>
</jboss-web>


Step 4: Outside of your web application, we will need a xxx-jboss-beans.xml to configure your JSR-196 modules. Example would be jaspi-webform-jboss-beans.xml.

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns="urn:jboss:bean-deployer:2.0">

<application-policy xmlns="urn:jboss:security-beans:1.0"
name="jaspi-test">
<authentication-jaspi>
<login-module-stack name="lm-stack">

<login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag="required">

</login-module>
</login-module-stack>

<auth-module code="org.jboss.web.tomcat.security.jaspi.modules.HTTPFormServerAuthModule" login-module-stack-ref="lm-stack"/>
</authentication-jaspi>
</application-policy>

</deployment>

What this does is defines a JASPI configuration block with an ServerAuthModule that is capable of doing tomcat form authentication. In this case, we also define a login context delegation structure called lm-test.

Reference: Test Case : WebJASPIFormUnitTestCase.java

Primer on EJB Security

In this blog post, I will try to provide a short primer on security with EJBs.

Client Side:
For EJBs, you can pass the security context from client side in two ways:
a) Username/Password via properties into initial context
Properties p = new Properties();
p.put(Context.SECURITY_PRINCIPAL, "principalName");
p.put(Context.SECURITY_CREDENTIALS, "pass");
Context ic = new InitialContext(p);
Object ejbHome = ic.lookup("someejb");
AccountHome accountHome = (AccountHome)javax.rmi.PortableRemoteObject.narrow(ejbHome, AccountHome.class);

b) Do an explicit JAAS login before doing InitialContext
LoginContext lc = new LoginContext("someconfig");
lc.login();
Context ic = new InitialContext();
Object ejbHome = ic.lookup("someejb");
AccountHome accountHome =(AccountHome)javax.rmi.PortableRemoteObject.narrow(ejbHome, AccountHome.class);

NOTE: Do not forget your try/catch/finally blocks above.

General JNDI security is highlighted here:
http://java.sun.com/products/jndi/tutorial/ldap/security/index.html

Server Side:
On the server side, the EJBs are packaged in a jar file. This jar file can also be packaged in an EAR (Enterprise Archive). For EJB2, the security descriptors go in the ejb-jar.xml via the method permission elements. You define the roles that can access the methods of EJBs. You can also define "run-as-identity" to propagate a role to other deployments.

Do remember to create a jboss.xml to define a security domain.

Programmatic Web Login finds use with an user

I was pointed to the following blog entry by a JBoss user that talks about the painful journey experienced by the user with various versions of JBoss until we added the very useful feature of Programmatic Web Login.

The blog entry from the user is:
Perform a JAAS programmatic login in Jboss - try to solve the “empty” remote user problem

I am all for having an active dialog with JBoss users in the blogosphere.

I invite users to subscribe to the "JBoss Security Beta Program" mailing list which is accessible at the Red Hat mailing lists here. This is a moderated no-spam mailing list, which provides an excellent communication platform between JBoss and its users (as far as security is concerned).

web.xml security constraints help

web.xml security-constraints form the cornerstone of web security for Java Enterprise Applications.

I would like to give out some examples of security-constraints that mean different things:

Excluded Resources:

<security-constraint>
<display-name>excluded</display-name>
<web-resource-collection>
<web-resource-name>No Access</web-resource-name>
<url-pattern>/excluded/*</url-pattern>
<url-pattern>/restricted/get-only/excluded/*</url-pattern>
<url-pattern>/restricted/post-only/excluded/*</url-pattern>
<url-pattern>/restricted/any/excluded/*</url-pattern>
</web-resource-collection>
<web-resource-collection>
<web-resource-name>No Access</web-resource-name>
<url-pattern>/restricted/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>PUT</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint />
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>

In this case, because of the excluding auth-constraint element (shown in BOLD), all the url patterns shown in italics will be excluded from ANY access. Nobody will be able to access these resources.

Unchecked Resources:

<security-constraint>
<web-resource-collection>
<web-resource-name>All Access</web-resource-name>
<url-pattern>/unchecked/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>PUT</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>


In this case, we are saying that the url pattern in italics for the http methods declared (HEAD,GET,POST etc), access should not be checked. The key here is the missing auth-constraint element.

Restricted GET operation:

<security-constraint>
<display-name>Restricted GET</display-name>
<web-resource-collection>
<web-resource-name>Restricted Access - Get Only</web-resource-name>
<url-pattern>/restricted/get-only/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>GetRole</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>

In this case, we declare that the GET operation on the url pattern in italics can be performed only by a caller with "GetRole" role.

Reference: http://java.dzone.com/articles/understanding-web-security

Tip 14: Disable Tomcat/JBossWeb Connectors

The location of the configuration file would be server.xml which would be under the conf directory for tomcat and under deploy/jboss-web.deployer for JBossWeb in JBoss 4.2.0

You will see multiple connector definitions based on protocol. 8080 for HTTP, 8009 for AJP and 8443 for HTTPS. If you want to disable any of these, all you have to do is uncomment the connector element for the relevant port.

When should you disable connectors?
- If Tomcat/JBoss is not fronted with Apache or any Native Web Servers (with mod_jk), then there is no need for the AJP connector. So disable the 8009 port connector by uncommenting it.
- If you do not care for HTTPS, but just want to cater to HTTP, then keep the 8443 connector commented out.

Tip 13: Ensure Just Https works on Tomcat

There may be cases where you want to disable the HTTP 8080 port and enable just the HTTPS or 8443 port in tomcat.

For that to happen, just ensure that you *uncomment* the 8443 port connector on Tomcat 6/JBoss 4.2 in server.xml

Tip 12: Encrypt Datastore Passwords in JBoss JCA

JBoss JCA Encrypt DataStore Password

This wiki gives you the instruction to encrypt the data store password. Please also have a look at http://wiki.jboss.org/wiki/Wiki.jsp?page=EncryptKeystorePasswordInTomcatConnector
for subtle details on PBE (Password Based Encryption) mainly the details on password, salt and IterationCount.

Caveats:
1. Note the Password Based Encryption deals with a tuple (password, salt, iterationcount). So ensure that you use the same salt and iteration count that you used during the opaque password generation in your MBean with JaasSecurityDomain.

Here is an example:

java -cp jbosssx.jar org.jboss.security.plugins.PBEUtils welcometopbe 15 somepassword server.password
Encoded password: E5rtGMKcXPP

Note the encoded password is my own cooked up (so it may not be the result of your command execution).

Now, this is how you configure your MBeans.

<mbean code="org.jboss.security.plugins.JaasSecurityDomain"
name="jboss.security:service=JaasSecurityDomain,domain=ServerMasterPassword">
<constructor>
<arg type="java.lang.String" value="ServerMasterPassword"/>
</constructor>
<attribute name="KeyStorePass">
{CLASS}org.jboss.security.plugins.FilePassword:${jboss.server.home.dir}/conf/server.password</attribute>
<attribute name="Salt">welcometopbe</attribute>
<attribute name="IterationCount">15</attribute>
</mbean>

As you see the salt and interation count in the MBean definition
is exactly the same used in the Password generation.

If you see this error in your log, it means that you are using a
different salt/iterationcount than the one you used during
password generation. Also verify that your DS depends on the MBean defining the JaasSecurityDomain.
java.security.InvalidAlgorithmParameterException:
Parameters missing

2. If JBoss cannot find the password file, then you will see an error such as:
ERROR [org.jboss.security.plugins.FilePassword] Failed to decode password file

Here is an example of a postgres-ds.xml that encrypts the DS password.

<?xml version="1.0" encoding="UTF-8"?>

<!-- ===================================================================== -->
<!--                                                                       -->
<!--  JBoss Server Configuration                                           -->
<!--                                                                       -->
<!-- ===================================================================== -->

<!-- ==================================================================== -->
<!--  Datasource config for Postgres                                      -->
<!-- ==================================================================== -->


<datasources>
  <local-tx-datasource>
    <jndi-name>DefaultDS</jndi-name>
    <connection-url>jdbc:postgresql://localhost:5432/teste</connection-url>
    <driver-class>org.postgresql.Driver</driver-class>

    <security-domain>EncryptedHsqlDbRealm</security-domain>
    <metadata>
         <type-mapping>PostgreSQL 8.0</type-mapping>
    </metadata>
    <depends>jboss.security:service=JaasSecurityDomain,domain=ServerMasterPassword</depends>
  </local-tx-datasource>

  <mbean code="org.jboss.security.plugins.JaasSecurityDomain"
      name="jboss.security:service=JaasSecurityDomain,domain=ServerMasterPassword">
      <constructor>
         <arg type="java.lang.String" value="ServerMasterPassword"/>
      </constructor>
      <attribute name="KeyStorePass">{CLASS}org.jboss.security.plugins.FilePassword:${jboss.server.home.dir}/conf/server.password</attribute>
      <attribute name="Salt">12345678</attribute>
      <attribute name="IterationCount">17</attribute>
   </mbean>
</datasources>

Tip 11: Refresh Security Roles within a Tomcat Session

This long outstanding JIRA issue has been on my mind for a long long time now. The blocking thing for this was always the performance aspect associated with the security roles refresh in the middle of the http session.

The JIRA issue is this:
Need a way to support refreshing security roles within a session

Well, no solution yet for the JBoss 4.2.x series (and for 3.2.x and 4.0.x series also).

But the simplest workaround is to do a full security check (authentication and authorization with each call). This was done anyway by default, except that the Jaas Security Cache in JBoss was pulling the subject out of the cache rather than go through the Jaas authentication process with each call.

Given this, there are 2 steps to perform for the workaround:
1) Disable Jaas Security Cache
- Go to conf/jboss-service.xml and set the "DefaultCacheTimeout" to zero.

  <mbean 
code="org.jboss.security.plugins.JaasSecurityManagerService"
name="jboss.security:service=JaasSecurityManager">
...
     <attribute name="DefaultCacheTimeout">0</attribute>

2) Disable Tomcat caching the principal as part of the session.
NOTE: This is a very important step. If you do not follow it correctly, you will see bad behavior and may lose hair.

Now you will need to figure out, what kind of auth method is used in your web application. How will you know? Look in the web.xml of your web application.

If it is BASIC as in,

   <login-config>
      <auth-method>BASIC</auth-method>
      <realm-name>JBoss JMX Console</realm-name>
   </login-config>

then do the following, in your WEB-INF of your web application, create a context.xml with the following information(remember
org.apache.catalina.authenticator.BasicAuthenticator):

<Context>
 <Valve 
className="org.apache.catalina.authenticator.BasicAuthenticator"
cache="false" />
</Context>

If it is FORM based login, as in

 <login-config>
   <auth-method>FORM</auth-method>
   <realm-name>Tomcat Application</realm-name>
   <form-login-config>
      <form-login-page>/jsp/login.jsp</form-login-page>
      <form-error-page>/jsp/loginerror.jsp</form-error-page>
   </form-login-config>
 </login-config>

then do the following, in your WEB-INF of your web application, create a context.xml with the following information(remember,
org.apache.catalina.authenticator.FormAuthenticator):

<Context>
 <Valve 
className="org.apache.catalina.authenticator.FormAuthenticator"
cache="false" />
</Context>

Similarly, if it is Client-cert, just replace FormAuthenticator with SSLAuthenticator.

Inform me if this does not work. I have done some basic testing with BASIC type of auth.

Motivation for the workaround:
For the web layer, the container security checks happen at the time of the user login. Once his auth and authorization checks are done, they are valid for the entire session. Now for custom requirements such as the roles being refreshed at arbitrary times during the session, there is no decent way of solving it other than
the aforementioned work around. The complexity does arise due to the way tomcat caches principal during the session.

Tip10: Generate GUID or UUID

Stefan and I have been discussing the usage of java.util.UUID to generate a sso identifier similar to that done by tomcat's AuthenticatorBase. Since we wanted to avoid overlap with the random id generated by AuthBase, I suggested the usage of UUID.

So we decided to explore the level1 or time based UUID.

After sometime, Stefan gave up figuring out the way to instantiate level 1 UUID.

We found this mini-FAQ on UUID.

Java UUI Mini FAQ

Level 4 UUID should be sufficient.

An example of UUID usage is here >>>