Securing our Applications using OpenSSO in GlassFish Security

An example of such system is integration between an online shopping system, the product provider who actually produces the goods, the insurance company that provides insurance on purchases, and finally the shipping company that delivers the goods to the consumers’ hand. All of these systems access some parts of the data, which flows into the other software to perform its job in an efficient way. All the employees can benefit from a single sign-on solution, which keeps them free from having to authenticate themselves multiple times during the working day.

Another example can be a travel portal, whose clients need to communicate with many other systems to plan their traveling. Integration between an in-house system and external partners can happen in different levels, from communication protocol and data format to security policies, authentication, and authorization. Because of the variety of communication models, policies, and client types that each partner may use, unifying the security model is almost impossible and the urge for some kind of integration mechanism shows itself bolder and bolder.

SSO as a concept and OpenSSO as a product address this urge for integrating the systems’ security together.

OpenSSO provides developers with several client interfaces to interact with OpenSSO to perform authentication, authorization, session and identity management, and audition. These interfaces include Client SDK for different programming languages and using standards including:

• Liberty Alliance Project and Security Assertion Markup Language (SAML) for authentication and single sign-on (SSO)
• XML Access Control Markup Language (XACML) for authorization functions
• Service Provisioning Markup Language (SPML) for identity management functions. Using the client SDKs and standards mentioned above are suitable when we are developing custom solutions or integrating our system with partners, which are already using them in their security infrastructure. For any other scenario these methods are overkill for developers. To make it easier for the developers to interact with OpenSSO core services the Identity Web Services are provided. We discussed IWS briefly in OpenSSO functionalities section. The IWS are included in OpenSSO to perform the tasks included in the following table.

IWS are exposed in two models—the first model is the WS-* compliant SOAP-based Web Services and the second model is a very simple but elegant RESTful set of services based on HTTP and REST principles.

Finally, the third way of using OpenSSO is deploying the policy agents to protect the resources available in a container.

In the following section we will use RESTful interface to perform authentication, authorization, and SSO.

Authenticating users by the RESTful interface

Performing authentication using the RESTful Web Services interface is very simple as it is just like performing a pure HTTP communication with an HTTP server. For each type of operation there is one URL, which may have some required parameters and the output is what we can expect from that operation. The URL for authentication operation along with its parameters is as follows:

• Operation: Authentication
• Operation URL: http://host:port/OpenSSOContext/identity/authenticate
• Parameters: username, password, uri
• Output: subjectid

The Operation URL specifies the address of a Servlet which will receive the required parameters, perform the operation, and write back the result. In the template included above we have the host, port, and OpenSSOContext which are things we already know. After the context we have the path to the RESTful service we want to invoke. The path includes the task type, which can be one of the tasks included in the IWS task lists table and the operation we want to invoke.

All parameters are self-descriptive except the uri. We pass a URL to have our users redirected to it after the authentication is performed. This URL can include information related to the user or the original resource which the user has requested.

In the case of successful authentication we will receive a subjectid, which we can use in any other RESTful operation like authorization, to log in, log out, and so on. If you remember session ID from your web development experience, subjected is the same as session ID. You can view all sessions along with related information from the OpenSSO administration console homepage under the Sessions tab. The following listing shows a sample JSP page which performs a RESTful call over OpenSSO to authenticate a user and obtain a session ID for the user if they get authenticated.

<%
try {
String operationURL =
"http://gfbook.pcname.com:8080/opensso/identity/authenticate";
String username = "james";
String password = "james";
username = java.net.URLEncoder.encode(username, "UTF-8");
password = java.net.URLEncoder.encode(password, "UTF-8");
String operationString = operationURL + "?username=" +
username +"&password=" + password;
java.net.URL Operation = new java.net.URL(operationString);
java.net.HttpURLConnection connection =
(java.net.HttpURLConnection)Operation.openConnection();
int responseCode = connection.getResponseCode();
if (responseCode == java.net.HttpURLConnection.HTTP_OK) {
java.io.BufferedReader reader = new java.io.BufferedReader(
new java.io.InputStreamReader(
(java.io.InputStream) connection.getContent()));
out.println("<h2>Subject ID</h2>");
String line = reader.readLine();
out.println(line);
}
} catch (Exception e) {
e.printStackTrace();
}
%>

REST made straightforward tasks easier than ever. Without using REST we would have dealt with complexity of SOAP and WSDL and so on but with REST you can understand the whole code with the first scan.

Beginning from the top, we define the REST operation URL, which is assembled using the operation URL and appending the required parameters using the parameters name and the parameters value. The URL that we will connect to it will be something like:

http://gfbook.pcname.com:8080/opensso/identity/authenticate?username=james&password=james

After assembling the URL we open a network connection to authenticate it. After opening the connection we can check to see whether we received an HTTP_OK response from the server or not. Receiving the HTTP_OK means that the authentication was successful and we can read the subjectid from the socket. The connection may result in other response codes like HTTP_UNAUTHORIZED (HTTP Error code 401) when the credentials are not valid. A complete list of possible return values can be found at http://java.sun.com/javase/6/docs/api/java/net/HttpURLConnection.html.

Authorizing using REST

If you remember in Configuring OpenSSO for authentication and authorization section we defined a rule that was set to police http://gfbook.pcname.com:8080/ URL for us. And later on we applied the policy rule to a group of users that we created; now we want to check and see how our policy works. In every security system, before any authorization process, an authentication process should compete with a positive result. In our case the result for the authentication is subjectid, which the authorization process will use to check whether the authenticated entity is allowed to perform the action or not. The URL for the authorization operation along with its parameters is as follows:

• Operation: Authorization
• Operation URL: http://host:port/OpenSSOContext/identity/authorize
• Parameters: uri, action, subjectid
• Output: True or false based on the permission of subject over the entity and given action

The combination of uri, action, and subjectid specifies that we want to check our client, identified by subjectid, permission for performing the specified action on the resource identified by the uri. The output of the service invocation is either true or false.

The following listing shows how we can check whether an authenticated user has access to a certain resource or not. In the sample code we are checking james, identified by his subjectid we acquired by executing the previous code snippet, against the localhost Protector rule we defined earlier.

<%
try {
String operationURL =
"http://gfbook.pcname.com:8080/opensso/identity/authorize";
String protectecUrl = " http://127.0.0.1:38080/Conversion-war/";
String subjectId =
"AQIC5wM2LY4SfcyemVIZX6qBGdyH7b8C5KFJjuuMbw4oj24=@AAJTSQACMDE=#";
String action = "POST";
protectecUrl = java.net.URLEncoder.encode(protectecUrl, "UTF-8");
subjectId = java.net.URLEncoder.encode(subjectId, "UTF-8");
String operationString = operationURL + "?uri=" + protectecUrl +
"&action=" + action + "&subjectid=" + subjectId;
java.net.URL Operation = new java.net.URL(operationString);
java.net.HttpURLConnection connection =
(java.net.HttpURLConnection) Operation.openConnection();
int responseCode = connection.getResponseCode();
if (responseCode == java.net.HttpURLConnection.HTTP_OK) {
java.io.BufferedReader reader = new java.io.BufferedReader(
new java.io.InputStreamReader(
(java.io.InputStream) connection.getContent()));
out.println("<h2>authorization Result</h2>");
String line = reader.readLine();
out.println(line);
}
} catch (Exception e) {
e.printStackTrace();
}
%>

For this listing everything is the same as the authentication process in terms of initializing objects and calling methods, except that in the beginning we define the protected URL string, then we include the subjectid, which is result of our previous authentication. Later on we define the action that we need to check the permission of our authenticated user over it and finally we read the result of authorization. The complete operation after including all parameters is similar to the following snippet:

http://gfbook.pcname.com:8080/opensso/identity/authorize?uri=http://127.0.0.1:38080/Conversion-war/&action=POST&subjectid=subjectId

Pay attention that two subjectid elements cannot be similar even for the same user on the same machine and same OpenSSO installation. So, before running this code, make sure that you perform the authentication process and include the subjectid resulted from your authentication with the subjectid we specified previously.