New Features and Enhancements in JSA 7.3.2
The following new features and enhancements make it easier for administrators to manage their JSA 7.3.2 deployment.
To view a list of all new features in this release, see What’s New Guide.
New Managed Host for Apps
JSA 7.3.2 introduces the App Host, which is designed specifically to store and manage your applications. By using the new App Host in your JSA deployment, you can manage the appliance in the same way as other managed hosts. As an added benefit, JSA manages all updates to the operating system, and you can include the App Host in your high-availability deployments. You no longer have to upgrade the App Node separately from your managed hosts because JSA is now managing it for you.
Earlier versions of JSA used an external App Node to provide extra storage, memory, and CPU resources for JSA applications. The App Host replaces the App Node.
Improved Currency of Searches, Filters, and Rules
In JSA 7.3.2, you can reduce the lag time of expired reference data to as little as 1 minute to improve the currency of JSA searches, filters, and rules.
There’s a brief time lag before expired reference data is removed from the reference set. During the lag time, expired reference data is still seen by JSA searches, filters, and rule test conditions. By default, expired reference data remains for up to 5 minutes.
Easy Monitoring with Consolidated Audit Events
By default, each expired reference data element is logged as
a separate audit event when it’s removed from the reference
set. Large numbers of expired elements can clutter the
In JSA 7.3.2, you can log expired reference data elements that are removed at the same time as one audit event, or choose not to log them at all. Fewer audit events make it easier to monitor other important changes that are made to JSA.
More Comprehensive Monitoring with Audit Events for New Offenses
When an offense is created, it triggers an audit event with QID 28250369, which can be used by JSA searches, filters, and rule test conditions.
For example, you can schedule a daily report showing offenses that were created in the last 24 hours.
Data Obfuscation Configured per Domain or Tenant
In JSA 7.3.2, you can configure obfuscation for each domain or tenant.
Data obfuscation prevents unauthorized access to sensitive or personal identifiable information that is stored in JSA.
Previously, obfuscation was not configured for a log source type per domain or tenant. The work-around was to configure obfuscation for each individual log source, which became impractical if you had many log sources.
Improved Management of Backup Files
Backup files are now detected and flagged in JSA. If your external storage becomes unavailable for a period, the risk of inadvertently deleting backup files is reduced.
Previously, when you backed up JSA files to an
external file system, an issue with the external mount might cause
files to become unavailable. If this issue occurred, references to
the files were removed from the database. If the file system connection
was later restored, JSA flagged the returned backup files
as invalid. These files were not automatically deleted, and could
be inserted into the system by using the upload feature
Now, the backups that are listed on the Backup and Recovery page are flagged as missing if they are not found. If files were intentionally deleted by a JSA administrator, they can remove backups that are listed on the Backup and Recovery page.
For example, you might have an external file mount set up that stores your backup files. A failure of the mount causes the mount to disconnect, and JSA can no longer detect the backup files. On the Backup and Recovery page, the backups in the table display a warning to notify you that they are missing.
You can delete any of the backup entries in the table. Also, you can wait for the external mount connection to be restored. After the restoration and a page refresh, JSA rediscovers the backup files and removes the warnings on the Backup and Recovery page.
Single Sign-on Authentication with SAML 2.0
JSA 7.3.2 includes support for the Security Assertion Markup Language (SAML) 2.0 single sign-on format.
By using the SAML authentication feature, you can easily integrate JSA with your corporate identity server to provide single sign-on. SAML eliminates the need to maintain local users for JSA.
With SAML single sign-on authentication, users who are authenticated to your identity server can automatically authenticate to JSA. These users don't need to remember separate passwords or type in credentials every time they access JSA.
Support Added for Multi-domain Microsoft Active Directory Authentication
In JSA 7.3.2, you can now use multiple Active Directory
IDs, which requires a change in login credential format. Previously,
you logged in with your userid, but starting
with 7.3.2, you use the
Domain\user or Repository_ID\user login formats.
The Repository ID is an identifier or alias that uniquely represents the server that is entered in the Server URL field and the domain from the Domain field. Use the Repository ID when you enter your login details. For example, you might use AD_1 to represent server_A on Domain_A in one Active Directory Repository, and AD_2 to represent server_B on Domain_A in your second repository.
Users can log in by using the
Repository_ID\user login formats.
The login request that uses
Repository_ID\user is attempted on a specific server that is linked to a specific domain.
For example, Server A on Domain A, which is more specific than the
Domain\user login request format.
The login request that uses the Domain\user format is attempted on servers that are linked to the specified domain until a successful login is achieved. For example, there might be more that one server on a specific domain.
For Active Directory user authentication, you must create a local JSA user account in Active Directory authentication mode that is the same as the Active Directory (AD) account on the authentication server.