Chapter 4. Example Scenarios

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.

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

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

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 ] and xref:Adding RBAC to the Management Interfaces[ sections.

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.

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

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.

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:

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.

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.

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.

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

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:

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.

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.

The following users have been added to the LDAP directory:

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.

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.

The following users have been created in the Kerberos server:

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

The following roles have also been configured in each application:

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.