Chapter 4. Example Scenarios

One way of understanding how JBoss EAP security and its components work together is to view in context of real scenarios. The following sections cover several generalized but realistic situations that involve the various JBoss EAP security components and configuration options. They will focus on how an application or set of applications is secured as well as how the management interfaces are secured.

4.1. Red Hat JBoss Enterprise Application Platform Out of the Box

This scenario shows how JBoss EAP and a sample application are secured when no configuration changes are made after the initial install. An application (sampleApp1.war) is deployed and configured to use container-based security.

scenario1

4.1.1. Core Management Authentication Out of the Box

4.1.1.1. Security

The core management authentication offers two pre-configured security realms by default: ManagementRealm and ApplicationRealm. These realms use property files to store the usernames, passwords, and roles. The ManagementRealm, which is used to store the authentication information the management APIs, also defines and enables local authentication for users using the CLI interface on the same host as the JBoss EAP instance. The ApplicationRealm is also pre-configured to store authentication and authorization information, but for use with other applications besides the management APIs. In addition, ApplicationRealm does come pre-configured with local authentication enabled but is not commonly used.

4.1.1.2. How it works

For this scenario, the following users have been added to a default installation of JBoss EAP:

Table 4.1. Users

UsernamePasswordRolesSecurity Realm

Susan

Testing123!

 

ManagementRealm

Sarah

Testing123!

sample

ApplicationRealm

Frank

Testing123!

 

ApplicationRealm

On startup, the JBoss EAP instance loads both the ManagementRealm and ApplicationRealm security realms.

If Susan attempts to access either of the management APIs (HTTP or CLI), she is required to authenticate. Her username, password, and roles must match an entry in the ManagementRealm security realm. By default, no roles are required to access the management APIs. Sarah and Frank would not be able to access the management APIs since they are not in the ManagementRealm security realm.

4.1.2. Security Subsystem Out of the Box

4.1.2.1. Security

The security subsystem also comes pre-configured with three security domains: other, jboss-web-policy, and jboss-ejb-policy. The other security domain performs authentication and authorization by delegating to the realm specified in the login module (uses ApplicationRealm by default).

Additional information about both the default security realms as well as the default security domains can be found in the Security Realms and Security Domains sections.

4.1.2.2. How it Works

The application sampleApp1.war has two html files (/hello.html and /secure/hello.html) and uses basic HTTP authentication to secure the path /secure/*. It uses the other security domain and requires the role of sample. Since the other security domain defers to ApplicationRealm for its authentication and authorization information, refer to the users in the Users table from the previous section.

When Sarah requests /hello.html, she is able to view the page without authenticating. When Sarah tries to request /secure/hello.html, she is prompted to enter her username and password. She is then able to view /secure/hello.html after successfully logging in. Frank and Susan (or any user) can access /hello.html, but neither can access /secure/hello.html (Frank does not have the sample role and Susan is not in the ApplicationRealm security realm).

4.2. Red Hat JBoss Enterprise Application Platform with HTTPS and RBAC Added to the Management Interfaces

This scenario shows how JBoss EAP is secured when HTTPS is enabled for the management interfaces, and RBAC is added to the ManagementRealm security realm.

scenario2

4.2.1. Security

JBoss EAP provides support for using HTTPS with the management interfaces, which includes the Management Console. HTTPS can be enabled by configuring the secure-interface element, adding a secure-port to the http-interface section of the management interface, and configuring an existing or new security realm with the desired settings (e.g. server-identities, protocol, keystore, alias, etc). This enables the management interfaces to use SSL/TLS for all HTTP traffic. For more background information on HTTPS and securing the management interfaces in general, see the Section 2.2.2, “Advanced Security” section.

JBoss EAP also offers the ability to enable RBAC on the managent interfaces using a couple of different authentication schemes. This example uses username/password authentication with the existing property files used in the ManagementRealm. RBAC is enabled by setting the provider attribute to rbac for the management interface and updating the ManagementRealm with the desired users and roles.

4.2.2. How it works

For this scenario, the following users have been added to the existing security realms:

Table 4.2. Management Users

UsernamePasswordSecurity Realm

Suzy

Testing123!

ManagementRealm

Tim

Testing123!

ManagementRealm

Emily

Testing123!

ManagementRealm

Zach

Testing123!

ManagementRealm

Natalie

Testing123!

ManagementRealm

Based on group membership, the users have also been mapped to the following RBAC roles:

Table 4.3. RBAC Roles

UsernameRBAC Role

Suzy

SuperUser

Tim

Administrator

Emily

Maintainer

Zach

Deployer

Natalie

Monitor

On startup, JBoss EAP loads the ManagementRealm (with the RBAC configuration) and management interfaces as part of the core services, which also starts the http-interface (configured for HTTPS) for the management interfaces. Users now access the management interfaces via HTTPS, and RBAC has also been enabled and configured. If RBAC is not enabled, any user in the ManagementRealm security realm is considered a SuperUser and has unlimited access. Since RBAC has been enabled, each user is now restricted based on the roles they have. Suzy, Tim, Emily, Zach, and Natalie all have different roles which are showing in the table above. For example, only Suzy and Tim can read and modify access control information. Suzy, Tim, and Emily can modify runtime state and other persistent configuration information. Zach can also modify runtime state and other persistent configuration information, but only related to application resources. Suzy, Tim, Emily, Zach, and Natalie can all read configuration and state information, but Natalie cannot update anything. For more details on each of the roles and how JBoss EAP handles RBAC, see the Section 2.1.9, “Role-Based Access Control” and Section 2.2.2.3, “Adding RBAC to the Management Interfaces” sections.

4.3. Red Hat JBoss Enterprise Application Platform with an Updated Security Subsystem including HTTPS

This scenario shows how a sample application running on JBoss EAP is secured when a new security domain is added, and HTTPS is enabled. An application (sampleApp2.war) is deployed that is configured to use container-based security (sample-domain) and HTTPS.

scenario3

4.3.1. Security

JBoss EAP provides support for using HTTPS for use with applications, which is handled using the web subsystem. A new connector for HTTPS is added to the web subystem and is configured with the desired settings (e.g. protocol, port, keystore, etc). Once the configuration is saved, web applications can start accepting HTTPS traffic on the configured port. A new security domain has also been added called sample-domain that uses the IdentityLoginModule for authentication. sampleApp2.war is configured to use sample-domain to authenticate users.

4.3.2. How it works

A security domain (sample-domain) has been created and configured to use the IdentityLoginModule. The following credentials have been configured in the login module:

Table 4.4. sample-domain Users

UsernamePasswordRoles

Vincent

samplePass

sample

On startup, JBoss EAP loads the core services, and then starts up the web and security subsystems which manages the HTTPS connections for all web applications and the sample-domain respectively. sampleApp2.war is then loaded which looks for sample-domain for providing authentication and authorization for its secured URLs. sampleApp2.war has two html files (/hello.html and /secure/hello.html) and uses basic HTTP authentication to secure the path /secure/*. It uses the sample-domain security domain and requires the role of sample.

When Vincent requests /hello.html, he is able to view the page without authenticating. When Vincent tries to request /secure/hello.html, he is prompted to enter her username and password. He is then able to view /secure/hello.html after successfully logging in. All other users can access /hello.html without loggin in, but none can access /secure/hello.html since Vincent is the only user in sample-domain. This also applies to all traffic handled over HTTPS.

4.4. SSO for Web Applications on Red Hat JBoss Enterprise Application Platform

This scenario shows how web applications make use of both clustered and non-clustered SSO on JBoss EAP. Four JBoss EAP instances have are created (EAP1, EAP2, EAP3, and EAP4) with EAP1 and EAP2 operating in standalone mode, and EAP3 and EAP4 operating as a two node cluster. Two web applications (sampleAppA and sampleAppB) have been deployed to each of the four JBoss EAP instances.

scenario4

4.4.1. Security

JBoss EAP provides support for both clustered and non-clustered SSO with web applications by using a combination of the security, web, and infinispan subsystems. The security subsystem provides a security domain for performing authentication and authorization while the infinispan and web subsystems help with caching and distributing the SSO information between all the web applications on an JBoss EAP instance or across a JBoss EAP cluster. All four eap instances have a security domain (sso-domain) configured to use the IdentityLoginModule. sampleAppA and sampleAppB have been configured to use the sso-domain security domain to secure the path /secure/* and require the role of sample to access it. The following credentials have been configured in the sso-domain login module:

Table 4.5. sso-domain Users

UsernamePasswordRoles

Jane

samplePass

sample

All four JBoss EAP instances have also been configured to start up with either standalone-full-ha or full-ha profile, which adds the infinispan subsystem and other functionality needed for enabling SSO in this scenario. The web cache-container and SSO replicated-cache have also been added, and the web subsystem has been configured to use both them. EAP1 and EAP2 have configured their web subsystems for non-clustered SSO while the cluster containing EAP3 and EAP4 has been configured to use clustered SSO.

Application Clustering vs. Clustered SSO

There is a distinct difference between a clustered web application and clustered SSO. A clustered web application is one which is distributed across the nodes of a cluster to spread the load of hosting that application. In clustered applications (marked as distributable), all new sessions, and changes to existing sessions are replicated to other members of the cluster. Clustered SSO allows for replication of security context and identity information, regardless of whether or not the applications are themselves clustered. Although these technologies may be used together they are mutually exclusive and may be used independent of one other.

4.4.2. How it works

On startup, JBoss EAP loads the core services and then starts up the security, web, and infinispan subsystems which manage sso-domain and the associated caching for SSO informaiton. sampleAppA.war and sampleAppB.war are loaded on all four JBoss EAP instances, each of which look for sso-domain for providing authentication and authorization.

If Jane attempts to access EAP1/sampleAppA/secure/hello.html, she will be asked to authenticate. After providing the correct information, she will be allowed to see EAP1/sampleAppA/secure/hello.html. Jane’s session will then be be added into the SSO caches used by the web and infinispan subsystems. If she then attempts to access EAP1/sampleAppB/secure/hello.html, she will not be asked to re-authenticate. sampleAppB running on EAP1 will find her session using the web subsystem caches along with the infinispan subsystem and grant her access since she is already authenticated. If Jane then attempts to access either EAP2/sampleAppA/secure/hello.html or EAP2/sampleAppB/secure/hello.html, she will be asked to authenticate again since EAP1 and EAP2 do not share a cache.

If Jane attempts to access EAP3/sampleAppA/secure/hello.html, she will be asked to authenticate and her session will be stored in the SSO caches. These caches are stored across the entire cluster, so if Jane attempts to log into EAP3/sampleAppB/secure/hello.html, EAP4/sampleAppA/secure/hello.html, or EAP4/sampleAppB/secure/hello.html, she will not have to re-authenticate. Additionally, if either EAP3 or EAP4 are restarted, Jane’s SSO information will remain in the cache since the other JBoss EAP instance and the cluster remain running, hence preserving the cache. Similarly, if Jane’s session is invalidated, it ripples across the cache and she will be asked to re-authenticate regardless of which application or server she tries to access in the cluster.

4.5. Multiple Red Hat JBoss Enterprise Application Platform Instances and Multiple Applications Using Browser-Based SSO with SAML

This scenario shows how multiple JBoss EAP are secured and browser-based SSO is added. Three separate (non-clustered) JBoss EAP instances are configured(EAP1, EAP2, and EAP3) and three sample applications (sampleAppA.war, sampleAppB.war, and sampleAppC.war) are configured to use browser-based SSO for authentication.

scenario5

4.5.1. Security

JBoss EAP provides support for doing browser-based SSO via SAML with web applications as well as hosting an identity provider. To host an identity provider, a security domain (idp-domain) must be configured with an authentication mechanism defined. In this case, idp-domain is configured to use the DatabaseLoginModule as the authentication mechanism. The identity provider application (IDP.war) is deployed to that JBoss EAP instance (EAP-IDP), and configured to use idp-domain as its identity store. IDP.war uses the identity store in combination with functionality in the application to authentication users as well as issue SAML tokens containing the users identity and role information. Three additional JBoss EAP instances (EAP1, EAP2, and EAP3) each host one distinct application that will serve as an individual service provider (sampleAppA.war, sampleAppB.war, and sampleAppC respectively). Each JBoss EAP instance has a security domain (sso-domain) configured to use the SAML2LoginModule as the authentication mechanism. Each application contains functionality to support SSO, use IDP.war as an identity provider, and use HTTP/POST binding for authentication. Each application is also configured to use sso-domain to secure the path /secure/* and supplies its own list of roles for handling authorization.

4.5.2. How it works

For this scenario, the following users have been added to the database used by the DatabaseLoginModule in the idp-domain security domain:

Table 4.6. idp-domain Users

UsernamePasswordRoles

Eric

samplePass

all

Amar

samplePass

AB

Brian

samplePass

C

Alan

samplePass

 

On startup of EAP-IDP, the management interfaces start up, followed by the subsystems and deployed applications including the security subsystem (which includes idp-domain) and IDP.war. idp-domain connects to the database and loads the usernames, passwords, and roles as configured in the DatabaseLoginModule login module. To prevent sensitive information from being stored in plaintext in the configuration of the DatabaseLoginModule login module password hashing is configured to obscure certain fields (e.g. password for the database). IDP.war uses idp-domain for authentication and authorization. IDP.war is also configured (via jboss-web.xml, web.xml, picketlink.xml, and jboss-deployment-structure.xml) to issue SAML tokens to authenticated users and supplies a simple login form for users to authenticate against. This allows it to serve as an identity provider.

On startup of EAP1, EAP2 and EAP3, the management interfaces start up, followed by the subsystems and deployed applications including the security subsystem (which includes sso-domain on each instance) and sampleAppA.war, sampleAppB.war, and sampleAppC.war respectively. sso-domain is configured to use the SAML2LoginModule login module, but relies on the application to supply the proper SAML token. This means any application using sso-domain must handle properly connecting to an identity provider to obtain a SAML token. In this case, sampleAppA, sampleAppB, and sampleAppC are each configured (via jboss-web.xml, web.xml, picketlink.xml, and jboss-deployment-structure.xml) to obtain SAML tokens from an identity provider (IDP.war) using that identity providers login form.

Each application is also configured with its own set of allowed roles:

Table 4.7. Application/SP roles

Application/SPAllowed Roles

sampleAppA

all, AB

sampleAppB

all, AB

sampleAppC

all, C

When an un-authenticated user attempts to access the URLs secured by sso-domain (i.e. /secure/*) of any application, that user is redirected to the login page at IDP.war. The user then authenticates using the form, is issued a SAML token containing their identity and role information. The user is then redirected back to the original URL, and their SAML token is presented to the application (service provider). The application ensures the SAML token is valid and then authorizes the user based on the roles provided by the SAML token and the ones configured in the application. Once a user is issued a SAML token, they will then use that token to be authenticated and authorized on the other applications secured by SSO using the same identity provider. Once the SAML token expires or becomes invalidated, the user will required to obtain a new SAML token from the identity provider.

In this example, if Eric accesses EAP1/sampleAppA/secure/hello.html, he is redirected to EAP-IDP/IDP/login.html to login. After successful login, he is issued a SAML token containing his user information and the role all, and redirected back to EAP1/sampleAppA/secure/hello.html. His SAML token is then presented to sampleAppA to be checked and to authorize him based on his roles. Since sampleAppA allows the roles all and AB to access /secure/* and Eric has the role all, he is allowed to access EAP1/sampleAppA/secure/hello.html.

If Eric then tries to access EAP2/sampleAppB/secure/hello.html, since he is not already authenticated against that service provider, he is redirected again to IDP.war with an authentication request. Since Eric has already authenticated against the identity provider (IDP.war), he is then redirected back to EAP2/sampleAppB/secure/hello.html by IDP.war with a new SAML token for that service provider without having to re-authenticate. sampleAppB then simply checks his new SAML token and authorizes him based on his role. Since sampleAppB allows the roles all and AB to access /secure/* and Eric has the role all, he also is allowed to access EAP2/sampleAppB/secure/hello.html. The same thing would apply if Eric were to try and access EAP3/sampleAppC/secure/hello.html.

If Eric were to return to EAP1/sampleAppA/secure/hello.html (or any URL under EAP2/sampleAppB/secure/ * or EAP3/sampleAppC/secure/*) after his SAML token became invalidated via global logout, he would be redirected back to EAP-IDP/IDP/login.html to authenticate again and be issued a new SAML token.

If Amar attempted to access EAP1/sampleAppA/secure/hello.html or EAP2/sampleAppB/secure/hello.html, he would be directed through the same flow as Eric. If Amar attempted to access EAP3/sampleAppC/secure/hello.html, he would still be required to have or obtain a SAML token, but would restricted from viewing EAP3/sampleAppC/secure/hello.html since his role AB only allows him to access EAP1/sampleAppA/secure/* and EAP2/sampleAppB/secure/*. Brian is in a similar situation, but he is only allowed to access EAP3/sampleAppC/secure/*. If Alan tries to access any service provider’s secured area, he would still be required to have or obtain a SAML token, but would be restricted from seeing anything since he has no role. Each service provider also has unsecured area which any user (authorized or not) can view without obtaining a SAML token.

4.6. Using LDAP with the ManagementRealm

This scenario shows the ManagementRealm using LDAP for securing the management interfaces. A JBoss EAP instance has been created (EAP1) and is running in standalone mode. The ManagementRealm on EAP1 has also been updated to use LDAP as the authentication and authorization mechanism.

scenario6

4.6.1. Security

JBoss EAP supports using LDAP (as well as Kerberos) for authentication in security realms. This is accomplished by updating the existing ManagementRealm to use ldap as the authentication type and creating an outbound connection to the LDAP server. This, in turn, changes the authentication mechanism from digest to BASIC / Plain, and will transmit usernames and passwords in the clear over the network by default.

4.6.2. How it works

The following users have been added to the LDAP directory:

Table 4.8. Management Users

UsernamePasswordRoles

Adam

samplePass

SuperUser

Sam

samplePass

 

On startup, EAP1 loads the core-services, including ManagementRealm and the management interfaces. ManagementRealm connects to the LDAP directory server and provides the authentication for the management interfaces as needed.

If Adam attempts to access a management interface, he will be forced to authenticate. His credentials will be passed to the ManagementRealm security realm, which will use the LDAP directory server for authentication. After he is authenticated, his roles will be passed back to the management interface and for authorization. Since Adam has the SuperUser role, he will be granted access to the management interface. If Sam attempts to access a management interface, he would be authenticated via LDAP, but would be denied access since he does not have the proper role of SuperUser.

4.7. Using Desktop SSO (via Kerberos) to Provide SSO for Web Applications

This scenario shows how Kerberos can be used with JBoss EAP to provide SSO for web applications. A JBoss EAP instance has been created (EAP1) and is running in standalone mode. Two web applications (sampleAppA and sampleAppB) have been deployed to EAP1. Both the web applications and EAP1 have been configured to authenticate using desktop-based SSO via Kerberos.

scenario7

4.7.1. Security

JBoss EAP offers support for using Kerberos for SSO in web applications via SPNEGO and JBoss Negotiation. For more information on the specifics of Kerberos and SPNEGO please see the Section 1.6.1, “Third-Party SSO Implementations” section. To enable JBoss EAP and deployed web applications to use Keberos for authentication, two security domains must be created. The first security domain (host-domain) is configured with the kerberos login module to connect to the kerberos server. This allows JBoss EAP to authenticate at the container level. A second security domain (spnego-domain) is created with two login modules. One uses the spnego login module to connect to host-domain to authenticate users. The second can use any other login module to load role information for use in authorization decisions (e.g. UsersRoles using properties files to map users to roles).

These two login modules also make use of password-stacking to map the users and roles in the authorization module with the users in the authentication login module. EAP1 is configured with both host-domain and spnego-domain. Applications are then configured (via web.xml and jboss-web.xml) to use spnego-domain to perform authentication and get a user’s roles for authorization. Applications can also be configured with FORM authentication as a fallback authentication mechanism in case the security tokens cannot be passed from the OS to the browser. If FORM authentication is configured as a fallback, an additional security domain must be configured to support it. This security domain is independent of Kerberos and SPNEGO, and just has to support FORM authentication (i.e. username/password validation and roles). Each application is configured to use spengo-domain and to provide FORM authentication as a fallback. Each application is also configured to secure the path /secure/* and supplies its own list of roles for handling authorization.

4.7.2. How it works

The following users have been created in the Kerberos server:

Table 4.9. Kerberos Users

UsernamePassword

Brent

samplePass

Andy

samplePass

Bill

samplePass

Ron

samplePass

The following roles have mapped to the users via an additional module that is chained by setting the password-stacking option to useFirstPass:

Table 4.10. User Roles

UsernameRoles

Brent

all

Andy

A

Bill

B

Ron

 

The following roles have also been configured in each application:

Table 4.11. Application Roles

Application/SPAllowed Roles

sampleAppA

all, A

sampleAppB

all, B

On startup, EAP1 loads the core-services, followed by the security and other subsystems. host-domain establishes a connection to the Kerberos server and spnego-domain connects to host-domain. sampleAppA and sampleAppB are then deployed and connect to spnego-domain for authentication.

Brent has logged onto his computer that is secured with Kerberos. He then opens his browser and attempts to access sampleAppA/secure/hello.html. Since that is secured, authentication is required. EAP1 directs the browser to send a request for a key to the Kerberos server (specifically the Kerberos Key Distribution Center which is configured on his computer). After a key is obtained by the browser, it is sent to simpleAppA. simpleAppA sends the ticket to spnego-domain where it is unpacked and authentication is performed by host-domain (in conjunction with the configured Kerberos server). Once the ticket is authenticated, Brent’s role is passed back to simpleAppA to perform authorization. Since Brent has the all role, he will be able to access sampleAppA/secure/hello.html. If Brent tries to access sampleAppB/secure/hello.html, the same process will occur and he will be granted access (due to him having the all role). Andy and Bill would follow the same process as well, but with Andy only having access to sampleAppA/secure/hello.html and not sampleAppB/secure/hello.html. Bill would be the opposite, having access to sampleAppB/secure/hello.html and not sampleAppA/secure/hello.html. Ron would pass authentication to either sampleAppA/secure/hello.html or sampleAppB/secure/hello.html, but would not be granted access to either since he has no role.

If Andy were to attempt to access sampleAppA/secure/hello.html from a computer not secured by Kerberos (e.g. a personal laptop connected to the office network), he would be directed to the FORM login page as a fallback login mechanism. His credentials would then be authenticated via the fallback security domain and then the process would continue with authorization.