I wanted to highlight a blog post on the Enterprise Application Platform (EAP) this week. Christina Wong, Principal Product Marketing Manager, talks about a EAP Webinar lead by John Doyle.
On March 20th, Red Hat JBoss
Enterprise Application Platform product manager, John Doyle lead a
webinar that discussed management and security in enterprise
applications. Specifically, John
dived into some of the management and security enhancements to JBoss
EAP 6.2. Including:
- Role-based access control for control of management operations.
- Configuration options for auditing and logging administrative actions.
- Management operations to install patches, roll back patches, and report patch states.
- The Common Criteria Certification and its significance to organizations
Missed it? Watch the webinar by
registering here!
We had several great questions from the
audience, but ran out of time to answer all of them. I've posted the
questions (with minor edits) and our best attempts to answer them
here:
Does 6.2 comply to Java EE 7 specs? If yes, why not call it JBoss EAP 7.0?
Major versions of JBoss EAP (like 5 or 6) remain certified with a specific version of Java EE. Therefore, JBoss EAP 6 is Java EE 6 certified, and JBoss EAP 7 will be Java EE 7 certified.
Do the role-based access control enhancements include the application user security, roles and permissions that a developer would typically design into an application? Do you have examples of application security in JBoss EAP?
The access control enhancements discussed in this webinar was about administrative access to the management interfaces of JBoss EAP. It was not about the application user roles that a developer considers when designing application security. Information about application-level security can be found in JBoss EAP's Security Guide, Section III, Securing Applications.
Are passwords stored as plain text on disk? Could a hacker with root access see passwords?
While a user could have plain text passwords stored in the configuration files on disk, this approach would clearly be a security risk. Typically, best practice dictates use of a password vault and associated keys for each piece of sensitive information. The vault is used to store passwords and other sensitive strings. The key is placed in the configuration file and used to retrieve the information from the vault. Visit the Red Hat Customer Portal and read the Security Guide, Section 3.8, Password Vaults for Sensitive Strings and the Administration and Configuration Guide, Section 10.11, SSL Encryption to learn more.
Where is the audit log location?
The location of the audit log is configurable, but audit logging is pre-configured to output to the file EAP_HOME/standalone/data/audit-log.log. Audit logging must be enabled with the Command Line Interface (CLI) before the audit log is produced. See the Administration and Configuration Guide, Section 3.8, Management Interface Audit Logging to learn more.
Will JBoss Operations Network be able to use these new JBoss roles? Can I define the users in JBoss Operations Network who will have access to the JBoss EAP role? For example: Operator, Monitor, etc... ?
We are looking to link the access control that you can define in JBoss Operations Network with the access control roles defined in JBoss EAP, but that change will arrive in a future version of JBoss Operations Network. We do not synchronize the releases of the products in the portfolio, so new features in the server products typically arrive before they are reflected in JBoss Operations Network.
Should I use the new patching feature for servers in my production environment? I am concerned about the fact that it replaces modules while JBoss EAP is running. Is this feature in technology preview or fully supported?
The new patching feature is a fully supported new feature and therefore, ready for use with your production systems. It is, in fact, the only supported way to patch. Pushing patches without validating them in a test environment is never a recommended practice! So, we expect that you would validate any patches in your test environment before you patch your production systems. The patch system does replace modules in your JBoss EAP server, but in order to apply the fixes staged by the patch command, you will be required to reload the server.
Can I patch JBoss EAP through JBoss Operations Network?
The patch command is a standard CLI command, so JBoss Operations Network can call that command just like any other management command.
Can I patch an JBoss EAP RPM installation via the Red Hat Network?
Yes, this new patching system allows you to use standard yum updates for patching.
Do the management and security features shown also apply for Red Hat JBoss Fuse Service Works?
JBoss Fuse Service Works is currently supported on a base of JBoss EAP 6.1.1. The access control, auditing, and patch capabilities described in our webinar are features of EAP 6.2. Once JBoss Fuse Service Works supports EAP 6.2 these features will be supported and exposed in the same way as shown during our webinar.