Authentication & Authorization in JBoss

Authentication & Authorization in JBoss

Security is a fundamental part of any enterprise application. You need to be able to restrict who is allowed to access your applications and control what operations application users may perform.

JAAS - Java Authentication and Authorization Service (pure Java)

Pluggable Authentication Module framework: JNDI, UNIX, Windows, Kerberos, Keystore

Support for single sing-on

Role-based access control

Separates business logic from A&A

Declarative (XML-based)

Described in deployment descriptors instead of being hard-coded

Isolate security from business-level code

To enrich your career and become a JBoss professional, visit Tekslate, the global online training platform:" JBoss Training". This course will help you achieve excellence in this field.

For example, consider a bank account application. The security requirements, roles, and permissions will vary depending on how is the bank account accessed:

via the internet (username + password), via an ATM (card + pin), or at a branch (Photo ID + signature).

We benefit by separating the business logic of how bank accounts behave from how bank accounts are accessed.

Securing a Java EE application is based on the specification of the application security requirements via the standard Java EE deployment descriptors.

EJBs and web components in an enterprise application by using the ejb-jar.xml and web.xml deployment descriptors.

Requiring A&A Adding security-constraint in web.xml:

<web-app ...>
...
<security-constraint>
<web-resource-collection>
<web-resource-name>All Resources</web-resource-name>
<description>Protect all content</description>
<url-pattern>/*</url-pattern>
</web-resource-collection>

<auth-constraint>
<role-name>MyRole</role-name>
</auth-constraint>
</security-constraint>
...
</web-app>

Element <security-constraint> declares the web resources to be protected and the role required to access those resources. Element <web-resource-name> is required, and it simply assigns a name to the declared <web-resource-collection>. Element <description> is optional, and it provides textual description of the declared <web-resource-collection>. Element <url-pattern> is optional (although, without it the <web-resource-collection> is ignored), and it declares to which URL patterns this security constraint applies. URL patterns can be catch-all ("/*") or they can be repeated to list specific resources. For example:

<url-pattern>/MySecureHandler</url-pattern>

<url-pattern>/MySecureArea/*</url-pattern>

<url-pattern>*.jsp</url-pattern>

The preceding slash (/) character makes the URLs absolute within the web application only. In addition to URL patterns, it is also possible to limit the security constraint to HTTP methods using the <http-method> element as follows:

<web-resource-collection>
...
<http-method>POST</http-method>
<http-method>GET</http-method></web-resource-collection>

If the <http-method> element is omitted, the default behavior is to apply the security constraint to all HTTP methods. The <auth-constraint> element indicates the user roles that should be permitted access to this resource collection. The <role-name> used here must either correspond to the <role-name> of one of the <security-role> elements defined for this web application (more on this soon), or be the specially reserved role-name "*" that is a compact syntax for indicating all roles in the web application. If no roles are defined, no user is allowed access to the portion of the web application described by the containing security-constraint. JBoss AS matches role names case-sensitively when determining access. Adding login configuration:

<web-app ...>
...
<security-constraint>
...
</security-constraint>

<login-config>
<auth-method>BASIC</auth-method>
<realm-name>My Secure Application</realm-name>
</login-config>
...
</web-app> Element <login-config> 

 configures the login method for the secured resource.

In this case, we just use HTTP BASIC authentication, but other options for JBoss are DIGEST, FORM, and CLIENT-CERT. We will cover some of these later. Declaring security roles:

<web-app ...>
...
<security-constraint>
...
<auth-constraint>
<role-name>MyRole</role-name>
</auth-constraint>
</security-constraint>

<login-config>
...
</login-config>

<security-role>
<description>All members of MyRole</description>
<role-name>MyRole</role-name>
</security-role>
...
</web-app>

If multiple roles are desired, declare them as follows:

<web-app ...>
...
<security-constraint>
<web-resource-collection> ... </web-resource-collection>
<auth-constraint>
<role-name>Manager</role-name>
</auth-constraint>
<auth-constraint>
<role-name>Administrator</role-name>
</auth-constraint>
</security-constraint>
<login-config> ... </login-config>
<security-role>
<role-name>Manager</role-name>
</security-role>
<security-role>
<role-name>Administrator</role-name>
</security-role>
...
</web-app>