16.4. About Java Authentication and Authorization Service (JAAS)
Server groups (in a managed domain) and servers (in a standalone server) include the configuration for security domains. A security domain includes information about a combination of authentication, authorization, mapping, and auditing modules, with configuration details. An application specifies which security domain it requires, by name, in its
Application-specific configuration takes place in one or more of the following four files.
Table 16.1. Application-Specific Configuration Files
The deployment descriptor for an Enterprise JavaBean (EJB) application, located in the
The deployment descriptor for a Java Enterprise Edition (EE) web application. Use the
Contains JBoss-specific extensions to the
Contains JBoss-specific extensions to the
web.xmlare defined in the Java Enterprise Edition (Java EE) specification. The
jboss-ejb3.xmlprovides JBoss-specific extensions for the
ejb-jar.xml, and the
jboss-web.xmlprovides JBoss-specific extensions for the
The Java Authentication and Authorization Service (JAAS) is a framework for user-level security in Java applications, using pluggable authentication modules (PAM). It is integrated into the Java Runtime Environment (JRE). In JBoss EAP 6, the container-side component is the
org.jboss.security.plugins.JaasSecurityManager MBean. It provides the default implementations of the
The JaasSecurityManager uses the JAAS packages to implement the AuthenticationManager and RealmMapping interface behavior. In particular, its behavior derives from the execution of the login module instances that are configured in the security domain to which the JaasSecurityManager has been assigned. The login modules implement the security domain's principal authentication and role-mapping behavior. You can use the JaasSecurityManager across different security domains by plugging in different login module configurations for the domains.
EJBHome. The EJB has already been deployed in the server and its
EJBHomeinterface methods have been secured using <method-permission> elements in the
ejb-jar.xmldescriptor. It uses the
jwdomainsecurity domain, which is specified in the <security-domain> element of the
jboss-ejb3.xmlfile. The image below shows the steps, which are explained afterward.
Figure 16.1. Steps of a Secured EJB Method Invocation
- The client performs a JAAS login to establish the principal and credentials for authentication. This is labeled Client Side Login in the figure. This could also be performed via JNDI.To perform a JAAS login, you create a LoginContext instance and pass in the name of the configuration to use. Here, the configuration name is
other. This one-time login associates the login principal and credentials with all subsequent EJB method invocations. The process does not necessarily authenticate the user. The nature of the client-side login depends on the login module configuration that the client uses. In this example, the
otherclient-side login configuration entry uses the
ClientLoginModulelogin module. This module binds the user name and password to the EJB invocation layer for later authentication on the server. The identity of the client is not authenticated on the client.
- The client obtains the
EJBHomemethod and invokes it on the server. The invocation includes the method arguments passed by the client, along with the user identity and credentials from the client-side JAAS login.
- On the server, the security interceptor authenticates the user who invoked the method. This involves another JAAS login.
- The security domain under determines the choice of login modules. The name of the security domain is passed to the
LoginContextconstructor as the login configuration entry name. The EJB security domain is
jwdomain. If the JAAS authentication is successful, a JAAS Subject is created. A JAAS subject includes a PrincipalSet, which includes the following details:
java.security.Principalinstance that corresponds to the client identity from the deployment security environment.
Roles, which contains the role names from the user's application domain. Objects of type
org.jboss.security.SimplePrincipalobjects represent the role names. These roles validate access to EJB methods according to constraints in
- An optional
CallerPrincipal, which contains a single
org.jboss.security.SimplePrincipalthat corresponds to the identity of the application domain's caller. The CallerPrincipal group member is the value returned by the
EJBContext.getCallerPrincipal()method. This mapping allows a Principal in the operational security environment to map to a Principal known to the application. In the absence of a CallerPrincipal mapping, the operational principal is the same as the application domain principal.
- The server verifies that the user calling the EJB method has the permission to do so. Performing this authorization involves the following steps:
- Obtain the names of the roles allowed to access the EJB method from the EJB container. The role names are determined by
ejb-jar.xmldescriptor <role-name> elements of all <method-permission> elements containing the invoked method.
- If no roles have been assigned, or the method is specified in an exclude-list element, access to the method is denied. Otherwise, the
doesUserHaveRolemethod is invoked on the security manager by the security interceptor to check if the caller has one of the assigned role names. This method iterates through the role names and checks if the authenticated user's
Subject Rolesgroup contains a SimplePrincipal with the assigned role name. Access is allowed if any role name is a member of the Roles group. Access is denied if none of the role names are members.
- If the EJB uses a custom security proxy, the method invocation is delegated to the proxy. If the security proxy denies access to the caller, it throws a
java.lang.SecurityException. Otherwise, access to the EJB method is allowed and the method invocation passes to the next container interceptor. The SecurityProxyInterceptor handles this check and this interceptor is not shown.
- For web connection requests, the web server checks the security constraints defined in
web.xmlthat match the requested resource and the accessed HTTP method.If a constraint exists for the request, the web server calls the JaasSecurityManager to perform the principal authentication, which in turn ensures the user roles are associated with that principal object.