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 under the name that matches the security domain to which the JaasSecurityManager
has been assigned. The login modules implement the security domain's principal authentication and role-mapping behavior. Thus, you can use the JaasSecurityManager
across different security domains simply by plugging in different login module configurations for the domains.
To illustrate the details of the JaasSecurityManager
's usage of the JAAS authentication process, you will walk through a client invocation of an EJB home method invocation. The prerequisite setting is that the EJB has been deployed in the JBoss server and its home interface methods have been secured using method-permission
elements in the ejb-jar.xml
descriptor, and it has been assigned a security domain named jwdomain
using the jboss.xml
descriptor security-domain
element.
Figure 8.12. An illustration of the steps involved in the authentication and authorization of a secured EJB home method invocation.
Figure 8.12, “An illustration of the steps involved in the authentication and authorization of a secured EJB home method invocation.” provides a view of the client to server communication we will discuss. The numbered steps shown are:
The client first has to perform a JAAS login to establish the principal and credentials for authentication, and this is labeled Client Side Login in the figure. This is how clients establish their login identities in JBoss. Support for presenting the login information via JNDI
InitialContext
properties is provided via an alternate configuration. A JAAS login entails creating aLoginContext
instance and passing the name of the configuration to use. The configuration name isother
. This one-time login associates the login principal and credentials with all subsequent EJB method invocations. Note that the process might not authenticate the user. The nature of the client-side login depends on the login module configuration that the client uses. In this example, theother
client-side login configuration entry is set up to use theClientLoginModule
module (anorg.jboss.security.ClientLoginModule
). This is the default client side module that simply binds the username and password to the JBoss EJB invocation layer for later authentication on the server. The identity of the client is not authenticated on the client.Later, the client obtains the EJB home interface and attempts to create a bean. This event is labeled as Home Method Invocation . This results in a home interface method invocation being sent to the JBoss server. The invocation includes the method arguments passed by the client along with the user identity and credentials from the client-side JAAS login performed in step 1.
On the server side, the security interceptor first requires authentication of the user invoking the call, which, as on the client side, involves a JAAS login.
The security domain under which the EJB is secured determines the choice of login modules. The security domain name is used as the login configuration entry name passed to the
LoginContext
constructor. The EJB security domain isjwdomain
. If the JAAS login authenticates the user, a JAASSubject
is created that contains the following in itsPrincipalsSet
:A
java.security.Principal
that corresponds to the client identity as known in the deployment security environment.A
java.security.acl.Group
namedRoles
that contains the role names from the application domain to which the user has been assigned.org.jboss.security.SimplePrincipal
objects are used to represent the role names;SimplePrincipal
is a simple string-based implementation ofPrincipal
. These roles are used to validate the roles assigned to methods inejb-jar.xml
and theEJBContext.isCallerInRole(String)
method implementation.An optional
java.security.acl.Group
namedCallerPrincipal
, which contains a singleorg.jboss.security.SimplePrincipal
that corresponds to the identity of the application domain's caller. TheCallerPrincipal
sole group member will be the value returned by theEJBContext.getCallerPrincipal()
method. The purpose of this mapping is to allow aPrincipal
as known in the operational security environment to map to aPrincipal
with a name known to the application. In the absence of aCallerPrincipal
mapping the deployment security environment principal is used as thegetCallerPrincipal
method value. That is, the operational principal is the same as the application domain principal.
The final step of the security interceptor check is to verify that the authenticated user has permission to invoke the requested method This is labeled as Server Side Authorization in Figure 8.12, “An illustration of the steps involved in the authentication and authorization of a secured EJB home method invocation.”. Performing the authorization this entails 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.xml
descriptor role-name elements of allmethod-permission
elements containing the invoked method.If no roles have been assigned, or the method is specified in an
exclude-list
element, then access to the method is denied. Otherwise, thedoesUserHaveRole
method is invoked on the security manager by the security interceptor to see if the caller has one of the assigned role names. This method iterates through the role names and checks if the authenticated user's SubjectRoles
group contains aSimplePrincipal
with the assigned role name. Access is allowed if any role name is a member of theRoles
group. Access is denied if none of the role names are members.If the EJB was configured with a custom security proxy, the method invocation is delegated to it. If the security proxy wants to deny access to the caller, it will throw a
java.lang.SecurityException
. If noSecurityException
is thrown, access to the EJB method is allowed and the method invocation passes to the next container interceptor. Note that theSecurityProxyInterceptor
handles this check and this interceptor is not shown.
Every secured EJB method invocation, or secured web content access, requires the authentication and authorization of the caller because security information is handled as a stateless attribute of the request that must be presented and validated on each request. This can be an expensive operation if the JAAS login involves client-to-server communication. Because of this, the JaasSecurityManager
supports the notion of an authentication cache that is used to store principal and credential information from previous successful logins. You can specify the authentication cache instance to use as part of the JaasSecurityManager
configuration as you will see when the associated MBean service is discussed in following section. In the absence of any user-defined cache, a default cache that maintains credential information for a configurable period of time is used.