Interview and Book Excerpt: Masoud Kalali’s GlassFish Security

Posted by Srini Penchikala on Nov 29, 2010 |

GlassFish Security book, by author Masoud Kalali, covers Java EE security model and how to design and develop secure Web and EJB modules in Java EE applications and deploy them to GlassFish server environment. In the book, Masoud discusses the installation and configuration of the application server and OpenDS Directory Server for Light-weight Directory Access Protocol (LDAP) based user authentication and authorization.

The book also covers the Single Sign-on (SSO) solution using OpenSSO framework which includes authenticating and authorizing users using RESTful web services as well as securing Java EE applications and web services using/by OpenSSO solution.

InfoQ spoke with Masoud about the book, the main motivation for writing it, new security features in Java EE 6 release, and other topics. We are also making an excerpt (Chapter 3 - Designing and Developing Secure Java EE Applications; 778 KB PDF) from the book available for our readers.

InfoQ: What was the main motivation for writing your book?

Masoud Kalali: I can name dozen of reasons for authoring this book but the biggest motivations are as follow:

The most important reason behind writing this book is the importance of having a clear understanding of security in general and Java EE security in particular for all developers. I believe it is essential for any developer working in Java EE field to know Java EE security basics and therefore I tried to explain it in a simple and yet detailed manner in the book.

On the other hand, Glassfish is a prominent application server and understanding its security is something required for anyone using it in production environment.

Finally, the new security features introduced in Java EE 6 needed to be introduced to the developers interested in the subject someway easier to understand compared to reference documents.

InfoQ: What do you think about the new security features introduced in Java EE 6 release?

Masoud: Security has not seen that much of change in Java EE compared to other services and components. Look at the dramatic changes we saw in Java EE 5 and Java EE 6 for EJB and web tier and compare it to what we have for security. Although Java EE 6 added some fresh breath of life into the platform security but I believe we are still behind what we should really have.

InfoQ: Authentication is now possible in the web tier components (Servlets) using declarative (@ServletSecurity annotations) and programmatic (login and authenticate methods in the HTTP Servlet Request interface). What do you think about this security support in the web tier?

Masoud: Adding the annotations fits in the overall move from XML descriptors to annotations for development and sometimes deployment time. But the more interesting thing is the programmatic security enhancements including the login and logout methods which give the developer more control over the authentication and authorization process. I am happy to see that we are changing the platform toward having better security features.

InfoQ: How do the new security features in Java EE 6 compare with other security frameworks like Spring Security version 3?

Masoud: I believe we cannot compare the Java EE platform security with Spring Security as their names suggest one is a platform and the other is a framework built on top of the platform to address more fine grained requirements. Using Spring Security is the way to go when we are using Spring frameworks as a whole or when the software architect knows that they will not need intensive security integration scenarios.

When the Java EE platform security is not enough, I'd rather go with using products like OpenSSO which not only provides non-intrusive integration with Java applications but also makes it possible to use the same infrastructure from other programming languages either natively or via its RESTful interface.

InfoQ: How do the other security related JSR's like Java Authentication Service Provider Interface for Containers (JSR 196) and Java Authorization Contract for Containers (JSR 115) fit in the Java security model?

Masoud: We all know that plug-ability and extensibility are valuable when we need to add a new feature to a product. We realize that this plug-ability will be much more valuable when we know that the same contract interface that product A supports is also supported by other similar products.

In our case the JSR-196 and JSR-115 are two specifications which provide guidelines and contract interfaces to unify the authentication and authorization model of Java EE application servers.

The JSR-196 target is not application developers but rather frameworks and security product developers as it facilitates integration of different authentication models with the Java EE application server. Using JSR-196 SPI, developers can develop their own authentication module, plug it into the application server, configure the module and intercept the messages which are transmitted between the server and its clients. The message can be intercepted in four points:

  1. In the client, before transmitting the request to the server.
  2. In the server, before the target service receives the client request.
  3. In the server, before a response can be sent back to the client.
  4. In the client, before the server response can be consumed.

An example of its uses can be seen in the GlassFish application server message security which is used by Metro web services framework to provide an easy to configure and easy to administrate web services security.

Another use case of the JSR-196 can be integrating "none-supported" authentication models like OpenID into the application server and then use it for different applications deployed in that application server.

Whenever we talk about security first two things that pop-up are authentication and authorization, the JSR-196 addresses the unification of authentication pliability for Java EE application servers as I explained above. The JSR-115 introduces the SPI for adding new authorization models to Java EE application server supporting the JSR by allowing the module developers to introduce their own logic around how to define a principal, what is definition for a role and how to check whether a principal has a role or not.

InfoQ: What other security features would you like to see in the future releases of Java EE?

Masoud: I look for more control over the entire authentication and authorization process to be provided for the developers to either use the defaults or go with their own configuration and customizations. For now we have some frameworks with specific security layer like Seam and some security frameworks like Spring Security which provide developers with a fair deal of security measure customizations, I am looking forward for some rule based access control and wider acceptance of SSO. Right now all of these along with many other security integration features are provided through different access management products starting with OpenSSO, Oracle Access manager, IBM Tivoli Access Manager and so on.

InfoQ: Thanks for your time for this interview. Final question, what are your favorite IT and non-IT books?

Masoud: Well, when it come to IT books I like Large Scale software architecture: A practical guide on using UML, and for non-IT books, I like "The Lord of the Rings" series more than all others.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.