Chapter 5. Legacy Core Management and Security Subsystem 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, 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.

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

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.

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

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:

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.

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.

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.

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, 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:

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.

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.

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

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.