Enterprise Java Development@TOPIC@
EJB access restrictions
Declarative
Programmatic
EJB assignment to Security Domain
Server definition of Security Domain
Server Security Domain authentication and authorization
Figure 111.1. EJB Access Control: Annotations
@Stateless(name="SecurePingEJB")
public class SecurePingEJB implements SecurePingRemote, SecurePingLocal {
...
@PermitAll
public String pingAll() {
return getInfo("pingAll");
}
@RolesAllowed({"user"})
public String pingUser() {
return getInfo("pingUser");
}
@RolesAllowed({"admin"})
public String pingAdmin() {
return getInfo("pingAdmin");
}
@DenyAll
public String pingExcluded() {
return getInfo("pingExcluded");
}
}
javax.annotation.security annotations define access requirements to EJB methods
Figure 111.2. EJB Access Control: ejb-jar.xml
<assembly-descriptor>
...
<method-permission>
<unchecked/>
<method>
<ejb-name>SecurePingEJB</ejb-name>
<method-name>pingAllmethod-name>
</method>
</method-permission>
<method-permission>
<role-name>admin</role-name>
<method>
<ejb-name>SecurePingEJB</ejb-name>
<method-name>pingAdmin</method-name>
</method>
</method-permission>
<method-permission>
<role-name>user</role-name>
<method>
<ejb-name>SecurePingEJB</ejb-name>
<method-name>pingUser</method-name>
</method>
</method-permission>
<method-permission>
<excluded/>
<method>
<ejb-name>SecurePingEJB</ejb-name>
<method-name>pingExcluded</method-name>
</method>
</method-permission>
</assembly-descriptor>
Access restrictions can also be defined in the ejb-jar.xml deployment descriptor
Figure 111.3. Programmatic Security Check
@Resource
SessionContext ctx;
if (ctx.isCallerInRole(role)) {
...
}
Permits more fine-grain access control down to the object level
role can be literal or a logical mapping (see below)
Figure 111.4. Optional Role Mapping: ejb-jar.xml
<enterprise-beans>
<session>
<ejb-name>SecurePingEJB</ejb-name>
<security-role-ref>
<description>role-name checked within EJB</description>
<role-name>internalRole</role-name>
<role-link>admin</role-link>
</security-role-ref>
</session>
</enterprise-beans>
<assembly-descriptor>
<security-role>
<role-name>admin</role-name>
</security-role>
<security-role>
<role-name>user</role-name>
</security-role>
</assembly-descriptor>
Permits role-name within Java code to be mapped to security role
Figure 111.5. EJB Security Setup: META-INF/jboss-ejb3.xml
<?xml version="1.0"?>
<jboss:ejb-jar
xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns:sec="urn:security"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd
http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
urn:security urn:security"
version="3.1"
impl-version="2.0">
<assembly-descriptor>
<sec:security>
<ejb-name>*</ejb-name>
<sec:security-domain>other</sec:security-domain>
</sec:security>
</assembly-descriptor>
</jboss:ejb-jar>
Assigns one or more EJBs to a security-domain defined on server
Security is ignored until this is place
JBoss default security-domain is "other"
Realm
User Credentials (username and password)
Figure 111.6. Example Security Domain: "other"
<security-domain name="other" cache-type="default">
<authentication>
<login-module code="Remoting" flag="optional">
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
<login-module code="RealmDirect" flag="required">
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
</authentication>
</security-domain>
Watches over interactions
Defines policy on what can take place
Figure 111.7. Example Application Realm: "ApplicationRealm"
<security-realm name="ApplicationRealm">
<authentication>
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
<properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
Defines authentication and authorization sources
Optionally defines a default user for anonymous
JBoss can operate in a mode to trust a user connecting from the same machine and running under the same operating system identity that launched the server. This allows for development scenarios to bypass login credentials and Command Line Interface (CLI) to operate without credential prompts.
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
JBoss installs with a set of static files to implement user authentication and authorization. This can be augmented or replaced by more dynamic sources such as a database or LDAP.
Figure 111.8. Example Authentication Source: application-users.properties
$ cat standalone/configuration/application-users.properties
known=0aea67d2fdd25e4207f0bc2a5c84a1a6
user1=b802b482f67706cb453ab9294b88a9ea
admin1=7357a05355829fb2855412b69297a55b
publisher1=a15cfe086e59fea3fe4c787b834f55b8
subscriber1=838a4d7dceb6655e0297947d9677c6cb
requestor1=21a138aa0eeec44ee9cf08ebd9a1dcb5
worker1=41c30fe6af7d12f7b7fd9aa60060f13d
admin2=f064c7710b767a156f7e07469f8ad944
Authenticates identity of user
Username and hashed password stored in static file
Figure 111.9. Example Access Control Source: application-roles.properties
$ cat standalone/configuration/application-roles.properties
user1=user,esales-user
admin1=user,admin,dmv-admin,mayberry-admin,eleague-admin,eclub-admin
publisher1=publisher
subscriber1=subscriber
requestor1=requestor
worker1=worker
admin2=admin
Assigns roles to authenticated user
Username and roles stored in static file