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:: 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/

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.

Java CodeSource Based Security Model

We have shipped JBoss Application Server v5.0 based on VFS (Virtual File System) semantics in the microcontainer. To get the Application Server to run under a Java Security Manager while trying to retain the default policy implementation in the JDK, I went through a lot of troubling times as evident from this design forum thread. There was a lot of finger pointing, crying and swearing in public involved. Equally there were enough emails flying across in internal mailing list(s) with the designers of the JBoss microcontainer.

Well some of the issues are being described by my friend, Dennis Pilipchuck (Enterprise Security Architect at BEA/Oracle) in his java.net article titled:
"Pitfalls of the Java Permissions Model"

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

Pitfalls of the Java Permissions Model by Denis Pilipchuk -- Is Java a good choice for creating applications with configurable security? Denis Pilipchuk argues that Java's permissions-based security model is a relic of its browser days and lacks the configurability, expressiveness, and efficiency that enterprise Java developers need. In this article, he looks at the problems of the permissions model and considers some alternatives.

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

The CodeSource URL based Java Security Model is outdated. It has never been updated since the browser-applet security days. Li Gong architected the model, then moved to Microsoft and then eventually to Mozilla Foundation (his journey has taken a decade - but the Java permissions model has neither seen any updates nor seen any desire for alternatives). So this article from Dennis seems like a coincidence in blessing. So we are not alone.

We were able to ship JBoss Application Server v5.0.0.GA to run under a security manager with the following security manager policy as a template.
Java Security Manager Policy

What were our options?
a) Write a new policy provider - this would mean a new configuration format for the permissions and would actually shoo away any rare souls who want to run the application server under a security manager.
b) Try to somehow get the default jdk policy provider to recognize or tolerate vfs urls. We ended up with this option of having dummy URL protocol handlers in the JBoss AS bootstrap and at the time of policy enforcement, we would get the real vfs codesource urls read in as the vfs protocol handlers were in place.
c) Update the VFSClassLoaderPolicy implementation to return real urls of the code jars rather than the vfs urls. We do this now by default. It avoids the issues we had with the default policyfile implementation not understanding vfs urls. But we have kind of disabled the superior vfs urls for consideration by the security manager.

Complaints with the Java Permissions based Security Model:
1) CodeSource takes an URL instance and not URI.
2) No negative permissions that can be declaratively defined (Dennis talks about this too). JACC 1.1 has a work around in the actions of WebResourcePermission for "excluded" security constraints with a "!" prefix.
3) Stack frame checking across the call path is performance intensive. Privileged blocks in the source code mitigate the walking penalties but are so poorly understood (or avoided) by developers that an introduction can accidently be the source of security holes.

We really need updates to the Java Policy class/interface with alternative mechanisms and a need to foster usage of policy.implies (after the alternatives have been identified) in the enterprise source code before embarking on sensitive operations such as using reflection, getting the classloader etc.

I wonder about the following:
a) How many enterprise deployments run under a Java Security Manager? If not, without explicit policy.implies checks, everything is open.
b) How well Java privileged blocks are understood and adopted by enterprise developers and Framework writers?

JBoss portal previously attempted to define their access model based on JACC. They had to define their own permission classes and got it working. The developers found it extremely cumbersome. Currently they are working on adopting an XACML based approach using JBossXACML. In JBoss AS5, we provide a pluggable access control model where in you can plug and play access control stacks based on JACC, XACML or your custom implementation.

Related References:
Ted Neward's White Paper: http://www.tedneward.com/files/Papers/JavaPolicy/JavaPolicy.pdf

Additionally, improving the Java Security Model is not the responsibility of Sun alone. It has to be pushed for by the other VM vendors (IBM, BEA/JRockit etc) also. Maybe Dennis can ping his own JRockit folks?

JBoss AS 5.0 and Security

As you may already noticed, JBoss Application Server v5.0 was released a week ago. It is a Java EE 5.0 certified application server as shown from the compatibility page at JavaEE Compatibility.

JBoss AS 5 has many security enhancements that the community will benefit from.

Apart from the JBoss Microcontainer integration, the security layer has pluggable authorization stacks, auditing and simplified configuration.

To achieve the highest form of security for your applications running on the JBoss Application Server, it is recommended to run the application server under a Java Security Manager. You can configure your permissions assigned to your applications using the following security manager policy as a template.

http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_5_0_0_GA/testsuite/src/resources/securitymgr/server.policy

Look for my blog posts on JBossAS5 security here.

AS5: Fine Grained Authorization using Oasis XACML (Part 1)

Access Control is one of my favourite topics in security. There are two aspects to it - coarse grained and fine grained access control. The JavaEE specifications typically mandate container based authorization which tend to be coarse grained.

For Web Applications, there is enforcement on web resources (via URLs) using roles. The beauty of container based security is that user applications can delegate authentication, authorization and auditing to the container.

But coarse grained authorization may not solve all user applications' access control needs. You may have some fine grained use cases or context based use cases such as the following:

"Allow access to this part of the web applications for users who are 18 years and older"
"Only managers can update the payroll of their subordinates"
"Allow access to this section of the web application to users who are employed, accessing from the US, between 9am-5pm on Monday-Thursday"

These cannot be catered to by the access control mechanism in the Servlet specification, for example. You can turn off container security and try to do this yourself via servlet filters. What is the problem in doing this? Each time the requirements change, you have a code change.

How nice will it be if you could externalize the policy infrastructure from your code? JACC does do it with PolicyConfiguration etc. But it is not as extensive as Oasis XACML specification.

The great thing about Oasis XACML specification is that it is totally tailored towards access control and IT DOES NOTHING ELSE. It defines a language and structures to define your policies/rules and an architecture for a decision point (aka Policy Decision Point, PDP) and one or more Policy Enforcement Points (PEPs).

I am sure you can google XACML and learn more about it.

The good news is that JBoss Application Server v5.0 bundles JBossXACML v2.0.2.SP1. What does this mean? It means that you now have capabilities to extend your container authorization mechanism to include XACML policies shipped with your web/ejb deployments. Apart from this, if you need to do your own security work in your applications and looking for a XACML stack, then you can use the friendly JBossXACML api to create policies, do evaluations etc.

Please wait for Part 2 of this post to read more about using XACML for your web and ejb container authorization.

AS5 : Pluggable Access Control - EJB/Web

The key driver for security for Java EE components such as Web or EJB Components in JBoss Application Server is the concept of a 'security domain'. The security domain is an abstract concept that defines the authentiation, authorization, audit, mapping etc. modules in JBoss Application Server 5.

An user may need to make access control stacks pluggable for a particular component.

You can continue to configure your security domain name in jboss.xml (ejb) or jboss-web.xml (web) deployment descriptors. But there are multiple ways to configure your authorization modules that govern your web and/or ejb components.

1) Change the default authorization policy for all web/ejb components. You can do that by changing the "jboss-web-policy" and "jboss-ejb-policy" in deploy/security/security-policies-jboss-beans.xml

An example is here:
http://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/resources/test-configs/jacc/deploy/security/security-policies-jboss-beans.xml

If you want to retain the normal authorization stack (do not care about JACC, XACML or custom authorization), then make no change and stop reading this blog entry. :)

2) You wish to change the authorization stack for a particular component. Lets say, test.war which has a security domain of "test-domain".

To configure JACC as the authorization stack, either in conf/login-config.xml or in a separate test-war-jboss-beans.xml (the file name should be xxx-jboss-beans.xml where xxx can be anything you desire), define the following.

<?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="test-domain">
     <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>
      <authorization>
         <policy-module code="org.jboss.security.authorization.modules.JACCAuthorizationModule" flag="required"/>
      </authorization>
   </application-policy>  

   <application-policy xmlns="urn:jboss:security-beans:1.0" name="test-domain2" extends="other"> 
      <authorization>
         <policy-module code="org.jboss.security.authorization.modules.XACMLAuthorizationModule" flag="required"/>
      </authorization>
   </application-policy>  

</deployment>

What we have done here is that we have defined "test-domain" to have JACC and test-domain2 to have the same authentication modules as "other" but we have used XACML as the access control stack.

FAQ:
1) What happens when some security domains do not define any authorization modules?
A. In this case, the authorization modules defined in "jboss-web-policy" or "jboss-ejb-policy" in deploy/security/security-policies-jboss-beans.xml kick in.

2) Can I stack access control modes for a particular security domain?
A. Yes, you can use the JAAS way of stacking the authorization modules and also use the flag required,requisite,sufficient, optional} to influence the final decision.

<application-policy xmlns="urn:jboss:security-beans:1.0" name="some-domain">
     <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>
      <authorization>
         <policy-module code="org.jboss.security.authorization.modules.JACCAuthorizationModule" flag="required"/>
         <policy-module code="org.jboss.security.authorization.modules.XACMLAuthorizationModule" flag="optional"/>
      </authorization>
   </application-policy> 

3) What about other components such as Messaging, JCA etc?
A. Patience. We will get there eventually. JACC is not defined for other components. While you can use XACML or write your own custom authorization provider, we have not yet provided the pluggable access control feature for components other than web and ejb. We will get there.

4) I would like to write my own authorization provider. What do I do?
A. What you need to write is a policy module such as the ones we have.
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/tags/2.0.2.SP3/jbosssx/src/main/java/org/jboss/security/authorization/modules/

5) I know that authentication is not tied to any layer such as web, ejb etc; but authorization is always tied to the type of component we are guarding. Your examples do not show it.
A. We respect your smartness. You should start contributing to JBoss Security. We have the concept of delegates within the authorization modules. You can do something like this:

<?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="test-domain2" extends="other"> 
      <authorization>
         <policy-module code="xxx.yyy.MyAwesomeAuthorizationModule" flag="required">
           <module-option name="delegateMap">web=xxxx.yy.mywebauthorizationdelegate,ejb=xxxx.yy.myejbauthorizationdelegate</module-option>
         </policy-module>
      </authorization>
   </application-policy>  

</deployment>

Remember, that your delegates need to be a subclass of AuthorizationModuleDelegate.
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/tags/2.0.2.SP3/jbosssx/src/main/java/org/jboss/security/authorization/modules/AuthorizationModuleDelegate.java

Examples are:
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/tags/2.0.2.SP3/jbosssx/src/main/java/org/jboss/security/authorization/modules/ejb/EJBJACCPolicyModuleDelegate.java

http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/tags/2.0.2.SP3/jbosssx/src/main/java/org/jboss/security/authorization/modules/web/WebJACCPolicyModuleDelegate.java


Read the post here: http://anil-identity.blogspot.com/2008/12/as5-pluggable-access-control-ejbweb.html

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

New deployer mechanism in AS5

If you have not yet had a chance to look at this great blog post by BobMc on deployers in JBoss Application Server 5 (JBAS5), then the time is now. :)
Deployers in JBoss Microcontainer

The deployers are broken into categories that depend on stages - parsing, class loader and real.