Chapter 5. Legacy Core Management and Security Subsystem Example Scenarios

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

5.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 installation. An application, sampleApp1.war, is deployed and configured to use container-based security.

scenario1

5.1.1. Core Management Authentication out of the Box

5.1.1.1. Security

The Core Management Authentication offers two preconfigured 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 and the management APIs, also defines and enables local authentication for users using the CLI on the same host as the JBoss EAP instance. The ApplicationRealm is preconfigured to store authentication and authorization information but for use with other applications besides the management APIs. In addition, ApplicationRealm comes preconfigured with local authentication enabled, but it is not commonly used.

5.1.1.2. How It Works

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

Table 5.1. Users

UsernamePasswordRolesSecurity Realm

Susan

Testing123!

 

ManagementRealm

Sarah

Testing123!

sample

ApplicationRealm

Frank

Testing123!

 

ApplicationRealm

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

If Susan attempts to access either of the management interfaces, 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 because they are not in the ManagementRealm security realm.

5.1.2. Security Subsystem out of the Box

5.1.2.1. Security

The security subsystem comes preconfigured with four security domains: other, jboss-web-policy, jboss-ejb-policy, and jaspitest. The other security domain performs authentication and authorization by delegating to the realm specified in the login module, which uses ApplicationRealm by default.

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

5.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. Because 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 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.

5.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

5.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, for example, server-identities, protocol, keystore, alias, and so on. 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 Advanced Security section.

JBoss EAP also offers the ability to enable RBAC on the management interfaces using a couple of different authentication schemes. This example uses username and 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.

5.2.2. How It Works

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

Table 5.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 5.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. Because RBAC has been enabled, each user is now restricted based on the roles they have. Suzy, Tim, Emily, Zach, and Natalie have different roles, which are shown 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 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 Role-Based Access Control and Adding RBAC to the Management Interfaces sections.

5.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

5.3.1. Security

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

5.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 5.4. sample-domain Users

UsernamePasswordRoles

Vincent

samplePass

sample

On startup, JBoss EAP loads the core services and starts the undertow and security subsystems that manage the HTTPS connections for all web applications and the sample-domain, respectively. sampleApp2.war is loaded and 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 his username and password. After successfully logging in, he is able to view /secure/hello.html. All other users can access /hello.html without logging in, but none can access /secure/hello.html because Vincent is the only user in sample-domain. This also applies to all traffic handled over HTTPS.

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

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

scenario4

5.4.1. Security

JBoss EAP provides support for clustered and non-clustered SSO with web applications by using a combination of the security, undertow, and infinispan subsystems. The security subsystem provides a security domain for performing authentication and authorization, while the infinispan and undertow 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 5.5. sso-domain Users

UsernamePasswordRoles

Jane

samplePass

sample

All four JBoss EAP instances have also been configured to start up with either the 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 undertow subsystem has been configured to use them both. EAP1 and EAP2 have configured their undertow 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 the applications are themselves clustered. Although these technologies may be used together, they are mutually exclusive and may be used independently.

5.4.2. How It Works

On startup, JBoss EAP loads the core services and starts the security, undertow, and infinispan subsystems that manage sso-domain and the associated caching for SSO information. 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 be added in the SSO caches used by the undertow and infinispan subsystems. If she attempts to access EAP1/sampleAppB/secure/hello.html, she will not be asked to reauthenticate. sampleAppB running on EAP1 will find her session using the undertow subsystem caches, along with the infinispan subsystem, and grant her access because she is already authenticated. If Jane attempts to access either EAP2/sampleAppA/secure/hello.html or EAP2/sampleAppB/secure/hello.html, she will be asked to authenticate again because 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 reauthenticate. If either EAP3 or EAP4 are restarted, Jane’s SSO information will remain in the cache because the other JBoss EAP instance and the cluster remain running, thus preserving the cache. Similarly, if Jane’s session is invalidated, it ripples across the cache, and she will be asked to reauthenticate regardless of which application or server she tries to access in the cluster.

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

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

scenario5

5.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, in this case named 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 IDP application, for example IDP.war, is deployed to that JBoss EAP instance, in this example 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 authenticate users as well as issue SAML tokens containing the user’s identity and role information. Three additional JBoss EAP instances: EAP1, EAP2, and EAP3, each host one distinct application that will serve as an individual SP, 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.

5.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 5.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, 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 plain text in the configuration of the DatabaseLoginModule login module, password hashing is configured to obscure certain fields, for example, password for the database. IDP.war uses idp-domain for authentication and authorization. IDP.war is also configured, using 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 IDP.

On startup of EAP1, EAP2 and EAP3, the management interfaces start, 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 properly connect to an IDP 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 IDP, IDP.war, using that IDP’s login form.

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

Table 5.7. Application/SP roles

Application/SPAllowed Roles

sampleAppA

all, AB

sampleAppB

all, AB

sampleAppC

all, C

When an unauthenticated user attempts to access the URLs secured by sso-domain, that is, /secure/*, of any application, that user is redirected to the login page at IDP.war. The user then authenticates using the form and is issued a SAML token containing their identity and role information. The user is redirected to the original URL, and their SAML token is presented to the application, SP. 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 use that token to be authenticated and authorized on the other applications secured by SSO using the same IDP. Once the SAML token expires or becomes invalidated, the user will be required to obtain a new SAML token from the IDP.

In this example, if Eric accesses EAP1/sampleAppA/secure/hello.html, he is redirected to EAP-IDP/IDP/login.html to log in. After successfully logging in, he is issued a SAML token containing his user information and the role all and is redirected to EAP1/sampleAppA/secure/hello.html. His SAML token is presented to sampleAppA to be checked and to authorize him based on his roles. Because 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 tries to access EAP2/sampleAppB/secure/hello.html, because he is not already authenticated against that SP, he is redirected to IDP.war with an authentication request. Because Eric has already authenticated against the IDP, he is redirected to EAP2/sampleAppB/secure/hello.html by IDP.war with a new SAML token for that SP without having to reauthenticate. sampleAppB checks his new SAML token and authorizes him based on his role. Because sampleAppB allows the roles all and AB to access /secure/* and Eric has the role all, he is allowed to access EAP2/sampleAppB/secure/hello.html. The same thing would apply if Eric were to try to 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 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 be restricted from viewing EAP3/sampleAppC/secure/hello.html because 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 because he has no role. Each SP also has an unsecured area which any user, authorized or not, can view without obtaining a SAML token.

5.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 as a standalone server. The ManagementRealm on EAP1 has also been updated to use LDAP as the authentication and authorization mechanism.

scenario6

5.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 changes the authentication mechanism from digest to BASIC / Plain and will transmit usernames and passwords in the clear over the network by default.

5.6.2. How It Works

The following users have been added to the LDAP directory:

Table 5.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. Since EAP1 is using the default simple access controls, after authentication, Adam’s roles will not be checked and he will be granted access. The same process will occur if Sam attempts to access the management interface.

If RBAC was enabled after Adam is authenticated, his roles would be passed back to the management interface for authorization. Because Adam has the SuperUser role, he would be granted access to the management interface. If Sam attempted to access a management interface with RBAC enabled, he would be authenticated via LDAP but would be denied access because he does not have a proper role.

5.7. Using Desktop SSO, using 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 as a standalone server. 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

5.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, see the Third-Party SSO Implementations section. To enable JBoss EAP and deployed web applications to use Kerberos 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, for example, 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 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 operating system 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 only has to support FORM authentication, that is, username and password validation and roles. Each application is configured to use spnego-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.

5.7.1.1. How It Works

The following users have been created in the Kerberos server:

Table 5.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 5.10. User Roles

UsernameRoles

Brent

all

Andy

A

Bill

B

Ron

 

The following roles have also been configured in each application:

Table 5.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 deployed and connect to spnego-domain for authentication.

Brent has logged in to a computer that is secured with Kerberos. He opens a browser and attempts to access sampleAppA/secure/hello.html. Because 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 that is configured on his computer. After the browser obtains a key, 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. Because 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. He will be granted access, due to him having the all role. Andy and Bill would follow the same process, 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 because he has no role.

If Andy were to attempt to access sampleAppA/secure/hello.html from a computer not secured by Kerberos, for example 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 the process would continue with authorization.





Revised on 2022-02-01 13:04:46 UTC