Learn what the new Java EE security API means for developers
The new Java EE security API is a proposal for baking better security into Java EE, and could ease many security implementation headaches.
Security has been somewhat of an afterthought as part of the Java EE development environment. Developers have either had to implement security at the server level or use a third-party framework. This can create a headache as enterprises move to cloud platforms, said Alex Kosowski, principal member of the Oracle technical staff and one of the leads on the new Java EE security API (JSR 375), a new proposal for baking better security into Java EE.
We want to make [JSR 375] more app developer-friendly so that common security configurations don't require server changes.
Alex Kosowski,
principal member of the Oracle technical staff
"The ultimate goal is to have security without vendor-specific configurations," Kosowski said. "The latest JSR was 196, which is not compatible with the cloud application development paradigm. We want to make it more app developer-friendly so that common security configurations don't require server changes."
An early draft of JSR 375 is planned for release by the end of 2015; the final release is expected in early 2017. The new APIs being defined in JSR 375 will promote self-contained application portability across Java EE servers and the use of modern programming concepts such as expression language and contexts and dependency injection (CDI).
The Oracle development group is focusing on seven specific areas:
1. Define terminology
When work began on the Java EE security API, the Oracle team realized they were talking about the same things but using different terms. There also were subtle nuances between the uses of the same terms. Kosowski said a good practice is to clarify terms and their use to ensure everyone is on the same page when defining the security framework. There needs to be a consistent vocabulary and meaning as it relates to different Java container contexts.
2. API for authentication mechanisms
The use case: An application needs to authenticate users to assign roles based on an application model. The API needs to support programmatic access even when the server cannot support it using external services like OpenID Connect. Java Authentication Service Provider Interface for Containers (JASPIC) is available as part of JSR 196 and currently supports some authentication capabilities. But JASPIC requires five methods to implement. JSR 375 will make it possible to do this with one method that can be configured.
3. API for identity store
The use case: An application needs to access a repository of identities, like users or groups. User credentials could be stored in an application-specific repository like lightweight directory access protocol (LDAP). This will make it easy to manage credentials without application-specific configurations. There is currently no Java EE support for this model. The terminology group decided to call the entities callers to make it easier to represent devices as well as human users. This will make it easier to adopt a better practice of specifying the credential access model using CDI rather than hard coding it into the application itself. There also are plans to standardize on credential types, Kosowski said. "This was always relegated to a server administrator that would map security to role of users or groups."
4. API for password aliasing
A number of security breaches have occurred when hackers managed to steal plain-text user password files. A much better practice is to encrypt this information in such a way that it could confirm credentials at run time without leaving a target for hackers. The API for password aliasing will make it easier to implement a portable way to protect stored passwords. The alias would be stored in an archive that is deployed with the application that can be maintained with a key tool.
5. API for role/permission assignment
Applications should be coded so they can assign roles based on an application-specific model. The API for role/permission assignments enables flexible dynamic application role changes. This makes it easier to manage users without access to server configurations. This API will make it easier for application developers to assign dynamic application-based roles. For example, this would simplify creating the logic for upgrading a basic user to a premium user after payment.
6. API for security context
Another good practice is to implement a dynamic model within the application code. This requires an easier way to authenticate users and devices, check roles and invoke RunAs statements. This API will allow an application to find out if the current caller is in a role that is authorized to access the session context. This security context could be injected with CDI, which makes it easier manage across containers.
7. API for authorization interceptors
Currently, Java EE supports only role-based authentication methods. The API for authorization interceptors will make it easier to implement rule-based security. It would check not only to see that a manager has permission to perform a transaction,but also if it is occurring during office hours. There are considerations for decentralizing this information in LDAP that would make it easier to manage rules centrally.
The work on the new Java EE security API is ongoing, and Kosowski said the Oracle team is open to external input. Check out the Java EE Security Spec page to find out more. There is also a GitHub play area for exploring possible Java EE security concepts.
How will the new Java EE security API aid your application development? Let us know.
Next Steps:
Handling Java security updates
Java patching: A security necessity?
Mitigating JavaScript risks
