Oracle's new API deals with Java EE security problems
(Image Credit: iStockPhoto/Hramovnick)
Oracle's staff are fully-aware that security in Java EE hasn't been taken as seriously as it should have, but are working to fix these problems in the new Java EE security API (JSR 375) which is a proposal for baking better security into the environment.
Java's development environment is notorious when it comes to security problems, at least out-the-box. There are several third-party frameworks to fill the void, and it's possible to implement security at a server-level, but it poses a serious headache as enterprises move to cloud platforms.
In a community survey of Java EE 8 developers back in March of last year, security was highlighted as requiring the most work:
We should have access to an early draft of JSR 375 before the end of the year, with a final release expected to debut in early 2017. According to a presentation show at Devoxx France earlier this year, seven key areas of Java EE security are being focused on in the upcoming API:
It was discovered that some of the terminology used around Java security was not concise, and it's hard to improve security if everyone isn't on the same page as to what's being discussed. Oracle found that different containers in Java EE used different names for the same concepts such as -
- Is this a group of users?
- A permission?
When "something" is authenticated – what is it?
- A User? (e.g. HTTPServletRequest.getUserPrincipal)
- A Caller? (e.g. EJBContext.getCallerPrincipal)
Oracle wants clarification between those and other terms used in Java security, and the subtle nuances used between them. This will help to ensure that everyone understands what is being discussed when it comes to defining the security framework.
The Authentication Mechanism API wants to provision easier support for authenticating users to assign roles based on an application model, whilst supporting programmatic access even when the server cannot support it (using external services like OpenID Connect.)
You can achieve this using the Java Authentication Service Provider Interface for Containers (JASPIC) which is available as part of JSR 196, but it requires five methods to implement. The API being delivered in JSR 375 wants to shave this down to just one method which needs to be configured.
If an application manages its own users and groups, yet requires access to a repository of identities, there is no solution in Java EE (only proprietary server support and through 3rd party security frameworks which provider user/group APIs.)
JSR 375 wants to solve this using an application-specific repository like Lightweight Directory Access Protocol (LDAP) to store things like user credentials. It will also promote a better practice of specifying the credential access model using CDI, rather than hard coding into the application itself.
For applications which use passwords to access resources like LDAP and DB, they are often stored in plain-text password files (which have been stolen by hackers on a number of occasions.)
Best practice advises that passwords are never store in clear text, so the API for Password Aliasing will provide a portable way to protect stored passwords through storage in an archive which is deployed with the application then subsequently maintained with a key tool.
Similar to authentication mechanism, if the application needs to assign roles (i.e. authorities, permission) to users and groups it manages; then it will be possible to store them in an app-specified repository such as LDAP which can be managed without access to server configuration.
The API will enable flexible application role changes, and simplify things such as upgrading a basic user to a premium user after payment.
If an application needs to retrieve the authenticated user, check roles, or to invoke runAs, then a new Security Context API will make it easier to achieve whilst adhering to best practice of implementing a dynamic model within the application code.
The API will allow the application to find out if the current caller is in a role that is authorised to access the session context.
Where an application needs to restrict specific methods to authorised users, application-model rules can be used to make access decisions. In a survey of Java EE developers, 78.6% of respondents said that security interceptions should be added in Java EE 8 (14.3% said "Not sure", leaving just 7.1% saying no.)
It's good to see Oracle taking security in Java seriously and using community feedback to guide where improvements should be prioritised. The work on JSR 375 is ongoing, and the Oracle team are still asking for external input.
Do you think Oracle's new Java EE security API will help your development? Let us know in the comments.