Override Java settings on OpenShift

Introduction

With OpenShift, your server instance in the cloud is prepared with a few mouse clicks or with a single command with the rhc tool.

In most of the cases, this is all you need and you can start right away with your freshly created server instance (named gear in OpenShift terminology).

But in other situations, you want to make some changes to the Java environment, like setting system properties or changing the security settings.

In the case of the security settings, in a normal environment, you can update the java.security file in the JRE_HOME/lib/security folder.  But on the OpenShift environment there are some constraints which makes this task a bit more difficult.  This text shows you an easy way to accomplish your goal.

History

We have developed a JSF application which uses OAuth2 as authentication means.  So we are using an SSL connection to the OAuth2 provider to verify the tokens which are presented to the applications.

It was working fine on OpenShift with the latest WildFly 8.2 cartridge. And last week, we created a new gear and our application throw an exception

java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available

When we compared this new instance with the instance we had already running, we found out that the java version was different.  The newest one, is using OpenJDK 8u31.  And searching on the web for the combination of this version and the exception we received, revealed that there is an issue with this version related to Elliptic curve algorithm.

So, the next step was to edit the java.security file to exclude the algorithm which causes problems in our cases.  

The key jdk.tls.disabledAlgorithms in the file, needs to contain the codes of the algorithms we don't want, in our situation EC,ECDHE,ECDH.

But when I opened the java.security file and wanted to change the content, I received the warning that the film is read-only.  And you can't change it and you can't become a super user to overrule it.

And I can understand that you want to secure some parts of the server.  But it is no option for us to rewrite the Web application with Java 7 due to a, hopefully, temporarily issue with the Java which is running on the gear.

Solution

The solution was found when I found the blog of Eyal Lupu which gives a nice example of how you can override the contents of the java.security file (the documentation in the file itself indicate already this possibility but with the example it became clear for me) and the OpenShift user guide.

So we created a file on the gear to override the key jdk.tls.disabledAlgorithms from the java.security file. And by setting a system property using the JAVA_OPTS_EXT environment variable of the gear, we are able to make the application run again without throwing the exception.

Create the file

•  rhc ssc gearName
•  cd $OPENSHIFT_DATA_DIR
•  vi override_security.properties
•  content is jdk.tls.disabledAlgorithms=EC,ECDHE,ECDH
•  pwd -> and note down (copy) the full path location of the just created file.
•  exit

Set the environment variable

•  rhc env set JAVA_OPTS_EXT=-Djava.security.properties=file:<> -a gearName

Restart your gear/app

•  rhc app restart -a gearName

The OPENSHIFT_DATA_DIR isn't chosen at random.  It is the only directory which isn't cleared when you push some code to the git repository. So our file is save there and will not be touched by any of the system processes.

Conclusion

The JAVA_OPTS_EXT environment variable is important if you want to change some settings of the Java Environment.  You can add some system properties to configure your application (like setting the JSF project stage) or to override the java.security configuration for instance as explained in this text.

Hope this help you if you have a similar 'issue' with OpenShift.

My 3 Christmas wishes for Java EE Security

Introduction

Recently, there was the start up of the new Java EE Security JSR, JSR 375. For me, it is one of the areas, together with Integration testing, where the Java EE specs can be improved greatly.

Over the years, I did a few large scale enterprise applications and those applications could benefit a lot if some of the following things would be standardised or available out of the box.

This blog post describes my needs and/or proposals that I have for Security from the JavaSever Faces view technology angle. And I know, there is much more that is vital for a good security implementation.

LoginModule

LoginModule is an interface, part of the Java Authentication and Authorization Service (JAAS), some of the security basics of Java SE.

The LoginModule is responsible for taking the credentials (most of the time, they are the username and the password of the user) and verify it against some kind of store (database, LDAP, file, etc …)

The issue is that JAAS is only standardised within Java SE, so there is nothing specified how the Application servers should integrate it.

Glassfish for instance requires that you extend a custom class (which implements LoginModule of course) and WebSphere has his own extension of the Subject (the class which represents the end user) class.

And all the application servers have heir own way of defining the LoginModule within the configuration.

So why not standardise this, by introducing a new annotation like @Realm, which defines the name of the realm and the LoginModule to use for it.

This name can then be defined in the web.xml file and that is basically all the things you need to do.

Permission Based security

In almost all the cases, you only hear about role based access models as security means.  I have done several, quit large enterprise projects and I never used the role based model.

Simply because it is not flexibel enough. Because any change in what the user role is allowed to do, results in recompilation of the code.  And I’m not even talking about the nightmare it is to properly test the role based security model over and over.

Permission based security on the other hand is much simpler. Every action the end user can perform or any data piece which needs to be displayed conditionally, gets a permission assigned. And the end user needs this permission to be able to perform the action or view the data.

The main task is now the configuration which permissions are assigned to a user.  But this is done outside the application, no recompilation is need as this info can be stored in a database for instance. There can be many permissions, I once had a set of almost 1000 permissions, so you can group them before you assign the groups to users.

The main difference between permissions and roles is that a permission is undividable and guards a single piece of the application.  A role is linked to the end user and what the end user is allowed to do can change over time.

So I would like to see the term Permission appear in the specifications and how they are linked or mapped to users and roles.

And the classic role base model also fits in this model.  Just replace the term Permission with Role and assign the Permission/Role to multiple areas of application.

Declarative security for JSF Components

This is specific for JavaServer Faces, which is the view technology I use most of the time. When data or a button shouldn’t be shown to the end user, the rendered attribute is used in most cases

But rendered attribute can contain also business logic rules that determine the visibility of the button.

But security is a cross cutting concern and should thus be separated from the other logic. So the ideal situation is that you use tags to indicate which permission is needed to render the button.

Some years ago, I prototyped already such functionality.  You can read more on that topic in this blog text.

 

The framework allows you to define some voters that determine if a certain user is allowed to see the button based on a permission.

Beginning of this year, I integrated this feature in a larger security framework called Octopus.  There it is combined with Apache Shiro to have declarative security for JSF components, URL protection and secured methods of EJB and CDI beans.  See this text for some more info.

But enough promotion for my work, the JSF tags for security are very handy and very readable. But it needs something like a Renderer interceptor and although possible today, it should be described in the specs and promoted as the preferred way for security.

OAuth2

Oke, I had already my 3 wishes, but what about other authentication ways which doesn’t fit into the LoginModule concept like OAuth2.  Social media is everywhere and thus also OAuth2 security providers which we can and should use.

JSR 375

This JSR is a good start to modernise the security specification of Java EE.  But I’m also sceptic.  As said, security is a cross cutting concern and therefor can be seen separately from the rest.

But many aspects are specific for the view technology, like the JSF security tags of Octopus.  And will those kind of interaction be tackled by this JSR?

But since the JSR process is much more open nowadays, lets provide them with usecases we need.  This was my contribution to that process.