My thoughts on JSR 351, Java Identity API

Identity, something that we hear more often these days with the whole web 2.0 and social services and more and more web based public services growing around us. The identity notion is an integral part of a security system in distributed services. Developing effective software system require an effective security and access control system which java provides, not exactly in the way that it should be in 2011 but it does provide what is the bare bone necessity to develop applications and frameworks on top of it and  benefit from its presence. The identity API is going to ease the interaction between the identity providers and those who consume the identity and trust the identity providers in addition to governing and managing the identity attributes.

I was studying the JSR details and it seems to be covering everything required for the identity attributes governance and the required API for both ends of the usage including the client API the governing/producing API. The identity producing and consuming is not new and there are fair number of public identity producers like facebook, twitter, etc. and also products that system integrators can use  like OpenAM as an open source product or gorilla Commercial software products like ORACLE identity management  or IBM tivoli identity management software, etc.

In a very simple set of words, the JSR 351: The Java Identity API will be as successful as it is going to be adopted. No adoption and it will endup dying some dark corner…  Design a simple and elegant API and try to ship it with some free and easy to use service implementations and it may get some momentum, otherwise it will be a goner and people will stick with what they have. I like the new features that it is going to introduce in the decision making or authorization part but we should see how well it will be adopted by identity providers to develop the services that provides the interaction point between the JSR interface and their repositories.  Pushing it as JSR wont really do that much without a wide adoption in the community. Look at how many implementation of the JSR 115 and JSR 196 exits to be plugged into application servers supporting the contract and you will get what I am referring to by community adoption.

My slides for Java EE Security session at JavaForum meeting 69

On the 7th of december I presented the “Security in Java EE platform: what is included, what is missing” session in the JavaForum meeting.

Although I arrived somehow late and left  right after the last presentation which was done by Chet Hendrickson but I can say that the athmospher was really friendly and enjoyable. I enjoyed the HTML 5 session and more than that I enjoyed the session presented by Chet, his way of presenting the session was different and pretty fun.

Following album contains some photos from the session.

GlassFish Security book FAQ 1: Custom Security Realm in GlassFish

I decided to write down the answer for some questions which my book’s readers email me or ask me via twitter in my weblog so everyone can benefit from the answers. Here is the answer to the first question which involves custom security realms.

GlassFish supports 5 types of security realms out of the box which are sd follow:

  1. File Realm: Usefull for development and testing purposes. GlassFish provids a user/ group management interface for this realm. We can add user and groups using the administration console. When using this realm all usernames, passwords and groups are stored in a plain text file.
  2. JDBC Realm: In production environment we store user information including but not limited to username, passwords and groups in an RDBMS and then configure a JDBC realm to authenticate the given credentials againts the information stored in the datase.
  3. LDAP Realm: Sometimes we have all user details stored in an LDAP like Active Directory or Redhat Directory Server, OpenDS or Sun Java System Directory Server Enterprise Edition.
  4. Solaris Realm: This realm is used to authenticate users with a Solaris user directory.
  5. Certificate Realm: The certificate realm allows us to conduct mutual SSL authentication based on the client certificates.

Sometimes our users information is stored in a silo different than all of this mentioned storages and we need to use that source for authentication and access control. For example assume that we have our users information including username, passwords and group membership stored in an Object Database and we need to authenticate our enterprise application’s users with that storage. In such times we should either think about having a synchronized RDMBS keeping update user information and use JDBC realm for authentication and authorization or we should develop  a custom security realm which uses the object database as a source for authentication.

Setting up synchronization between the e.g object database and RDBS can be tricky while developing a custom authentication realm is much easier using GlassFish provided SPIs.

Second chapter of GlassFish security book discusses GlassFish security realms in details and discuss a sample application which uses these realms for authenticating and authorizing users. In the same chapter, developing custom security realms is discussed along with developing a sample realm.

In the same chapter GlassFish support for  JSR-196 (Java Authentication Service Provider Interface for Containers) is discussed to complete the ring of authentication and authorization in Java EE in general and GlassFish application server in particular.

GlassFish v3 and EJBCA 3.x a fair couple for mutual SSL authentication.

Please use the following articles while I am updating this entry

  1. How to have your Own CA and configure Glassfish and your clients for mutual authentication?
  2. How to have your Own CA and configure Glassfish and your clients for mutual authentication?, Part II

Please post any comment or question here so we can have one main reference for this.

How to Secure GlassFish installation, Part II

In order to secure the application server you need to secure its communication ways with outside world, It means you will need to secure all ports and listeners.

There are 3 kind of listeners in Glassfish application server that you will need to take care of them

First of all make sure that you secured the administration listener, make sure that you have enabled Security for administrator listener and set an specific IP address for it to listen on. Usually we are not going to use administration console from outside of the internal network, so let it listen only on interfaces that you need it to listen perhaps the interface that connect the server to your LAN. In order to do this, open administration console and navigate to:

 Configuration> HTTP Service> HTTP Listeners> admin-listener 

Change the Network Address as appropriated, check the Security check box, and in the SSL Tab enable Client Authentication, in order to find out how you should use Client Certificate, take a look at my previous posts about SSL and securing GlassFish Application Server. You have two other Http listeners to take care of, so make sure that you change their Network Address and enable the Security facilities if required

There is another listener which you need to take care of, It is your IIOP listener. IIOP listener let you create a context to lookup into your JNDI, etc. In order to configure the IIOP listeners you should navigate to:

 Configuration> ORB> IIOP Listeners 

Here you can see that there are 3 different listeners already created and configure for different purposes. You should not allow the first non-secure listener (orb-listener-1) to listen over a public network as there is no authentication or transfer layer security for this listener, but the second one (SSL) have transport layer security and the third one (SSL_MUTUALAUTH) has mutual authentication which guarantee that listener will only process request come after a client cert authentication. make sure that you configure the listeners to listen on correct Network address and remove or disable the listeners those that you do not need. You can disable a listener by looking at listener details page which provides a check box for it.

Another listener which you need to take care of is your JMX connector listener, You can view and edit its configuration by navigating to:

 Configuration> Admin Service> system 

Here you are able to change the realm that this listener use to authenticate the users that are trying to connect to JMX listener, you can change the realm to an specific realm which you have made only for JMX users or let it use you administration realm. You can change the Network Address that this listener is using along with enabling the SSL and Client Cert Authentication in order to secure the data transfer and guarantee that only users with correct digital certification can use your JMX connector to control the application server

PS: All of the listeners that you can configure in your administration console allows you to have Mutual Authentication (Client Cert Authentication) which ensure that both parties have verify-able certifications. This certifications can come from well known providers like VeriSign or your own CA. on the other hand all listeners allows you to specify an specific alias for them, which means that each listener mutual authentication can be configured completely independent from other listeners, for example you can have two alias one for administration console and one for JMX connector in order to prevent JMX users to connect to administration console.

For more information you can take a look at my older posts related to this matter:

 

How to Secure GlassFish installation.

It is some days that I saw some posts about securing Glassfish in production environment, so I thought I write some of my experience here to let other secure the glassfish easier. There are some basic items that you will need to relay on in order to have a secure Glassfish installation.

 

  1. secure access to administration console, both web based and CLI.
  2. secure all ports and listeners that application server uses to interact with outside applications.
  3. secure your environment from GlassFish; Yes, glassfish can be evil if you have buggy software installed on you application server.
  4. secure your application server from the environment that it is operating on it.
  5. secure glassfish directories in order to prevent any accidental changes, use, etc in glassfish configuration files.
  6. Take care of all logging if you are not going to secure Glassfish on the file system.
  7. tips and tricks which are not mentioned in the above sections.
  8. firewalls, network security, clustered environment tips and tricks

 

But how you can do these, I will explain each item in as much details as I can begin with securing your administration console. As you know administration console is the main interaction point with an application server, however must of application servers let you perform all changes from a CLI or direct editing of server.xml, domain.xml and so on. But Web based administration console is the most open to access part of application server, So let’s see how we can secure it:

You will need to change administration password from the default one, do it by using the following command in CLI when your application server is running.

 change-admin-password 

 

Using this command you can change your administration password both for CLI and Web based console. The output of the command may differ from version or profile to another version and profile but it will asks you to enter old and new password, in case that it asks to accept a certificate accept it, you will change it later.

Second thing that you should change is master-password, make sure that you stop your application server before issuing the command as it will not work when the as is running. Following command in asadmin console will do it for you. Default master password value is “changeit”

 change-master-password 

 

Now you are sure that your administration console and keystore files are protected using a new password which you know.

Its time to take a closer look at application server web based console protection, you need to make sure that you have most possible protection over your administration console by limiting access to it using firewalls and after that you can add another level of protection and transmission integrity by using a mutual authentication using Digital Certificate.

By changing the administration http listener to use an a digital certificate specific for administration console and changing its setting to use client-cert authentication or mutual authentication you can ensure that your administration console will only opens in a browser which has a digital certificate signed by a CA known to your administration listener.

This way you can be sure that only the guys with that specific digital certificate will have access to your admin console and the administrator will not fool by anyone to connect to a mock server. On the other hand you have full protection of SSL over your transmitted data. To learn how you can setup your own CA and add keys to glassfish keystore take a look at some older entry of my weblog. however those entry shows how you can use digital certificate when your AS uses jks files ant certDB files.