Monday Jul 27, 2015

Ivar Grimstad's Java EE Sessions at JavaOne 2015

For the Java EE track at JavaOne 2015 we are highlighting some key sessions and speakers to better inform you of what you can expect, right up until the start of the conference.

To this end we recently interviewed Ivar Grimstad. Ivar is a Java EE advocate, speaker, blogger and open source hacker. He is a part of the Java EE 8 MVC and Security JSRs. We wanted to talk to him about his two accepted sessions at JavaOne 2015, his expectations for JavaOne and his experiences in the JCP (click here if you can't see the embedded video):

The following are the sessions we talked about:

Besides Ivar's sessions, we have a very strong program for the Java EE track and JavaOne overall - just explore the content catalog. If you can't make it, you can be assured that we will make key content available after the conference just as we have always done.

Thursday Jun 04, 2015

Devoxx Replay: Java EE Security API (JSR 375)

A few weeks ago, Alex Kosowski (JSR 375 Specification Lead) gave a session at Devoxx Paris on the new Java EE Security API (JSR 375). During that session, Alex gave some background and the motivations that led to the creation of JSR 375. Alex then outlined some of the initial plans of the Expert Groups.

This session is particularly useful to understand what the EG is trying to accomplish, it will also provide sufficient background to start following the JSR 375 EG discussions (see here).

Note: The audio level is low at the beginning of the video but everything is fine around the 2m45 mark. Alex's slides can be found here.

Tuesday Apr 14, 2015

Java EE Security API (JSR 375) Update

"If you don't vote you can't complain. Get involved." (David Blevins)

From the current set of Java EE 8 JSRs, 'Java EE Security API' (JSR 375) is the latest one as it was only approved in December last year. It was started later than the other JSRs. Nevertheless, the EG is now very active (+200 messages just for last month!). 

Obviously, this effort need a strong focus as 'Security' can mean a lot of things. And depending on whom you ask, you will high likely have different views. So to EG is currently busy filtering and consolidating ideas. In addition, one thing that is clear is that having a common ground for discussions is really needed. So the EG is also working on defining a security API terminology; i.e. a common vocabulary to enable concise and accurate communication amongst the EG and the community (see here). This may sounds obvious but it's not; e.g. what's the difference between a user store and a user realm?

During JavaLand, some EG members have presented a few ideas that will be tackled in this JSR. Alex Kosowski (JSR375 Specification Lead) also presented, during Devoxx France, the plans for JSR 375. Alex's session recording will be made available in the coming weeks. In the meantime, you can check the slides.

Since there are potentially a lot of things that could be addressed in this JSR, the EG needs to make sure they address the right features, in the right order and in the right form. So the goal of those different sessions is really to expose the EG current plans and ideas but more importantly to get your feedback!

To know more, you should check this playground has it contains prototype ideas for possible inclusions in this JSR; lurk in the JSR 375 users mailing list and voice any relevant feedback!

Tuesday Mar 10, 2015

Java EE Security API (JSR 375) Update

It took a bit longer than expected but the JSR 375 Expert Group is now formed! The EG is led by Alex Kosowski (Oracle) and is composed of the following members (companies representatives and individuals) : 

Adam Bien David Blevins (Tomitribe)
Rudy De Busscher Ivar Grimstad
Les Hazlewood (Stormpath, Inc.) Will Hopkins (Oracle)
Werner Keil Matt Konda (Jemurai)
Darran Lofthouse (RedHat) Jean-Louis Monteiro (Tomitribe)
Pedro Igor Silva (RedHat) Arjan Tijms (ZEEF) 

At that at this stage, IBM’s participation is not yet confirmed but this should be, hopefully, resolved quickly.

Now that the EG is formed, the technical discussions can take place. So make sure to watch the discussions as they happen over the JSR 375 user mailing list. The JSR 375 Issue Tracker is also a good resource to keep track of.

It is also worth to mention that this topic will be discussed during the upcoming weeks in 2 conferences. David Blevins and Jean-Louis Monteiro, both from Tomitribe and both EG members will present “Java EE Security: Let's Make Something Useful” during JavaLand (Germany).  In addition, Alex Kosowski (JSR 375 Spec Lead) will give, at Devoxx France, a session on JSR 375. So if you happen to attend one of those conferences, make sure to add those sessions to your schedule. 

Thursday Nov 27, 2014

JSR 375: Java EE Security API

Java EE has been used to develop and run enterprise applications securely since years.  Obviously, Java EE and its containers are just parts of the global security equation. When we zoom at the Java EE layer, we see that some of the security capabilities are backed into the specification while others security features are proprietary and specific to the different Java EE implementations.  Sometime, some of the security capabilities are also external add-on's (e.g. 3rd party libraries).  Security is not a self-contained matter as interactions between different components are often required (e.g. a Java EE Application Server needs to interact with an LDAP server).  Things also change when we go from an on-premises deployment to a cloud based deployment.  Finally, portability is never simple when it comes to security.

Java EE needs to evolve to stay relevant and clearly, if we look at the feedback from the Java EE 8 Community Survey, security is an area that could be improved.  And that is the goal of JSR 375 (Java EE Security API) which has just been submitted to the JCP for review.  JSR 375 is slated for inclusion in Java EE 8, its initial scope is based on the community survey feedback, on issues and RFEs filled against the Java EE specifications, on various exchanges EG members had overtime and also on various informal discussions we had during conferences, etc.

The JSR proposal gives a more detailed overview of what it will try to achieve.  In short, JSR 375’s goal is to simplify, standardize, and modernize the Security API across the platform in different area.

  • User Management: Standardization of a ’user service’ API which would enable an application to perform user management operations (e.g. create a user). The ‘user service’ would rely on a ‘user source’ which would be an abstraction of a physical user store (e.g. LDAP, data-bases, etc.).  The user service would be configurable to match the deployment requirements.
  • Password Aliasing: Standardization of syntax for pointing (alias) to passwords stored in a (secure) password repository.  This password repository might then be bundled with an application (e.g. think cloud deployment).
  • Role Mapping: Definition and standardization of a ‘role service’ API that would enable an application to perform various role mapping operations (e.g. querying a group role).  This would be done via different role mappers (e.g. LDAP, files) that would be adaptable based on the environment’s needs.
  • Authorization: Definition of a new CDI interceptor annotation that would be used to preform application-domain rules at the method level.
  • Authentication: Several enhancements are also planned around authentication (e.g. the ability for a web application to offers different authentication methods).

This is the just of overview of the initial scope. In addition, the Experts Group will also have to look at how some of the Java EE orthogonal technologies (e.g. CDI events, Expression Language, etc.) can be leveraged in order to simplify the use of those new APIs.  To know more about this JSR, make sure to read the JSR 375 proposal. You can also watch the replay of the "Java EE 8 Overview" that Linda DeMichiel gave during JavaOne as she has touched some of those ideas during her talk.

JSR 375 has entered the JCP review period; the next step should then be the approval ballot period. And if it passes this ballot, the Experts Group will be formed and the real works (and discussions) will start!   So we are just at the beginning of this effort but it’s nice to see the different pieces of Java EE 8 being put in place...

Thursday Sep 25, 2014

Spotlight on GlassFish 4.1: #11 Enable Remote Admin

Spotlight on GlassFish 4.1' is a series of posts that highlights specific enhancements of the latest GF release, GlassFish 4.1. It could be a new feature, a fix, a behavior change, a tip, etc.

#11 Enable Remote Admin

When you unzip GlassFish 4.1, the Administration user has no password set. This was introduced quite some time ago to simplify the developer experience. For obvious security reasons, the remote admin capabilities are also disabled. So the default Admin user is 'admin' and its password is empty.

To enable remote Admin, you should first define a password for the admin user and then enable remote admin. The trick is that the change-admin-password command is asking the admin password, in that case you should leave it empty.

./asadmin change-admin-password 
Enter admin user name [default: admin]> [leave it empty to use the default value]
Enter the admin password> [make sure to leave this field empty]
Enter the new admin password> myNewPassword
Enter the new admin password again> myNewPassword
Command change-admin-password execute

You can enable the securre-admin.

./asadmin enable-secure-admin
Enter admin password for user "admin"> [fill in the new password you have defined]
You must restart all running servers for the change in secure admin to take effect. Command enable-secure-admin executed successfully.

And just restart the domain and you are all set!

./asadmin restart-domain domain1

The 'empty admin password' is mentionned in the initial page of the first chapter of the Administration Guide.

Friday Aug 08, 2014

Spotlight on GlassFish 4.1: #4 JAXP accessExternalSchema

'Spotlight on GlassFish 4.1' is a series of posts that highlights specific enhancements of the upcoming GlassFish 4.1 release. It could be a new feature, a fix, a behaviour change, a tip, etc.

#4 JAXP 1.5 accessExternalSchema

GlassFish 4.1 supports recent JDK versions (JDK 7 u65+ and JDK 8 u5+). Sometime, those newer JDKs might have some side effect as they bring new features too. 

For example, several properties have been introduced in JAXP 1.5 (JDK 7u40+ and JDK 8+). Properties which are used to set restrictions when JAXP is used to process untrusted XML contents. And by default, those restrictions are set!

GF 4.1 is configured to offer the behavior of GF 4.0 used with an older JAXP release (prior to JAXP 1.5), i.e. no restriction on schemas processing. So by default, a GF 4.1 domain.xml is configured with the following JVM option to allow all schemas to be processed: <jvm-options>-Djavax.xml.accessExternalSchema=all </jvm-options>
This configuration obviously assumes that your external XML content is trusted or at least sanitised by an XML firewall. This is applicable to JAXP 1.5 (and above).

Thursday Jul 03, 2014

Spotlight on GlassFish 4.0.1: #1 JDBC Realm

'Spotlight on GlassFish 4.0.1' is a series of posts that highlights specific enhancements of the upcoming GlassFish 4.0.1 release. It could be a new feature, a fix, a behaviour change, a tip, etc.

#1 JDBC Realm for user authentication

There has been some refactoring between GF 3.x and GF 4.0. One unfortunate consequence of that refactoring is that the JDBC Auth Realm package has changed between those 2 GF versions. This can cause some obvious issues when moving,  from GF 3.x to GF 4.0, an application using the JDBC Realm!

GF 3.x was using while GF 4.0 is using
GF 4.0.1 will fix this and revert back to the original package!

If you want to know more...

  • Check the original Jira ticket for some background
  • Read the JDBC Realm section of the Java EE Tutorial
  • Test it today using the latest version of this sample in the trunk of the Java EE Tutorial
You can also help us to test GF 4.0.1 more broadly via the FishCAT Program.

Tuesday Jun 17, 2014

Jersey OAuth support

"The biggest guru-mantra is: never share your secrets with anybody. It will destroy you." (Chanakya

You have probably already heard of OAuth as it is widely used by many online services providers such as Google, FaceBook, LinkedIn, Yahoo, Twitter, ... to name just a few! OAuth is an authentication protocol that allows users to approve application to act on their behalf without sharing their password.  

OAuth support was introduced, several years ago, in Jersey 1.x. 'Recently' ... well more than 6 months ago (*), OAuth support has been added to Jersey 2.x, this post post covers in more details the OAuth support added to Jersey 2.3

If you are not yet familiar with OAuth, it is probably a good time to start to look at this open protocol. The OAuth chapter of the Jersey documentation should be a good starting point.

(*) It's sometime difficult to keep up with the Jersey release cadence! At the time of writing, the current release is Jersey 2.9!

Tuesday Oct 15, 2013

Securing WebSocket Endpoints

As you know, WebSocket is a key capability standardized into Java EE 7. When I talk to developers, many wonder how WebSockets are to be secured. One very nice characteristic for WebSocket is that it in fact completely piggybacks on HTTP. This means that all the well-understood ways of securing web applications instantly applies to WebSocket including SSL/TLS, Basic Authentication, Digest Authentication, LDAP, role based authorization and all the robust security infrastructure built into modern application servers like GlassFish and WebLogic. In a brief blog post, Pavel Bucek demonstrates how to secure WebSocket endpoints in GlassFish using TLS/SSL. Besides the server-side, he also includes a secure client side code example using the wss: protocol.

For a more complete example, you could look at the code for my joint JavaOne 2013 session with Ryan Cuprak and Bala Muthuvarathan titled "Android and iOS Development with Java EE 7". Do let me know if you need more detailed coverage focused on the topic, I will be happy to put something together on my personal blog.

Thursday Apr 18, 2013

The Java Update, Applets/Web Start and GlassFish

By now, most of us know about the Java SE security vulnerability that affects primarily Java Applets. You might be relieved to know that the latest Java update, Java 7 Update 21, looks to fix that vulnerability. Java EE expert group member and key community figure Markus Eisele did an awesome job explaining the details and providing further context.

Although the security vulnerabilities definitely do not affect server-side applications (the ones running on GlassFish), GlassFish has had support for launching Java EE application clients using Java Web Start. If you don't know what Web Start is, you are hardly alone - it's even less prevalent than Applets these days. The site does a pretty good job of explaining Web Start. The Java update affects Web Start too, so if you are using it, you'll need to be aware of the changes. Oracle's Tim Quinn explains what you need to watch out for.

Friday Jan 25, 2013

Oracle Speaks up on Java Security

As many of you are keenly aware, there has been a veritable media firestorm around the recent Java vulnerability. As you know, the vulnerability pertains to Java on the browser, not server-side Java, desktop Java or emdedded Java. You may also have been frustrated with Oracle's relative silence on the issue.

Hopefully it comes as some relief that Oracle is now starting to openly speak up on the issue. The lead for Oracle Security Martin Smith and Doland Smith from the OpenJDK team very recently had a conference call with worlwide JUG leaders. The recordings of the meeting is available here. This was a frank two-way discussion with Java community leaders about Java security, bundled software installers, openness, communication and the technical/journalistic quality of recent press coverage in some venues. As Donald and Martin indicate on the call, we can expect this to be the tip of the iceberg of what will be done on the Java Security and communication fronts.

You are encouraged to participate in this crucial dialog and provide your feedback.

John Spragge offers his opinions on these very issues in his intelligent, insightful blog post: A passionate defence of Java's virtues. It is well worth a read if you are a fan of GlassFish, Java EE or Java.

Tuesday May 15, 2012

SecuritEE in the Cloud

Java EE 7 and the Cloud theme continue to move full steam ahead. In a PaaS environment where infrastructure is shared and configuration tends to be split between the PaaS Provider (vendor or IT) and the PaaS user, security requires additional flexibility.

The SecuritEE blog covers Java EE security. The first two entries (here, here) begin to address Java EE 7 PaaS security.

If security is important to your Java EE applications, add the RSS feed to your reader.