Enterprise Java Development@TOPIC@
Legacy implementation (covered below) [15]
<server xmlns="urn:jboss:domain:7.0">
<management>
<security-realms>
...
</security-realms>
...
<subsystem xmlns="urn:jboss:domain:security:2.0">
<security-domains>
...
</security-domains>
</subsystem>
Latest implementation: "Elytron" (not covered) [16]
<subsystem xmlns="urn:wildfly:elytron:3.0" final-providers="combined-providers"
disallowed-providers="OracleUcrypto">
<security-domains>
...
</security-domains>
<security-realms>
...
</security-realms>
</subsystem>
Integrates identity store into application server
Verifies credentials
Obtains attributes associated with identity
Performs role mappings
ManagementRealm and ApplicationRealm supplied out of the box
# standalone.xml
<server xmlns="urn:jboss:domain:7.0">
<management>
<security-realms>
<security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="application.keystore"
relative-to="jboss.server.config.dir"
keystore-password="password"
alias="server"
key-password="password"
generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<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>
</security-realms>
server-identities
Supplies a server identity to clients for inbound connections
Supplies a client identity for outbound connections (e.g., username/password)
In this example, server identity is supplied from an SSL keystore
authentication
Identifies which credential stores are used to authenticate incoming connections
In this example, user credentials are stored in a static file with username and password
"local"
Allows local users to connect to server without a password
Leverages a token written to the filesystem and judges read/write permissions of the client
Anonymous local client will have identity of "$local"
Local client may specify any username in "allowed-users" without a password
Applies to only JBoss Remoting/RMI callers
authorization
In this example, user roles are stored in a static file with username and roles
JBoss can operate in a mode to trust an RMI 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"/>
<subsystem xmlns="urn:jboss:domain:remoting:4.0">
<http-connector name="http-remoting-connector"
connector-ref="default"
security-realm="ApplicationRealm"/>
</subsystem>
<subsystem xmlns="urn:jboss:domain:undertow:6.0" default-server="default-server"
default-virtual-host="default-host"
default-servlet-container="default"
default-security-domain="other"
statistics-enabled="true">
<server name="default-server">
...
<https-listener name="https" socket-binding="https"
security-realm="ApplicationRealm"
enable-http2="true"/>
<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<http-invoker security-realm="ApplicationRealm"/>
</host>
High-level security policies backed by one or more Security Realms
Can be shared across multiple applications
Results in a Security Identity for the identity of the current caller
Default Security Domain for applications
Two login modules
Remoting leverages information from Remoting connection if used
RealmDirect delegates to SecurityRealm (default=ApplicationRealm)
<subsystem xmlns="urn:jboss:domain:security:2.0">
<security-domains>
<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>
<subsystem xmlns="urn:jboss:domain:ejb3:5.0">
...
<default-security-domain value="other"/>
...
</subsystem>
<subsystem xmlns="urn:jboss:domain:undertow:6.0" default-server="default-server"
default-virtual-host="default-host"
default-servlet-container="default"
default-security-domain="other"
statistics-enabled="true">
...
</subsystem>
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 113.1. 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 113.2. 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
Legacy and Elytron serve the same authentication and authorization purposes
SecurityRealm addresses details of authentication and obtaining user properties
SecurityDomain contains higher level instructions - including the map realm properties into roles