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.
