REST

REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

• In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.

RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.
REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.

• Despite being simple, REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture.

REST is not a "standard". There will never be a W3C recommendataion for REST, for example. And while there are REST programming frameworks, working with REST is so simple that you can often "roll your own" with standard library features in languages like Perl, Java, or C#.

Federated SSO - Google Apps in OpenSSO

With OpenSSO users can implement federation for such applications as the widely-adopted Google Apps, for single sign-on (SSO) in just a few steps.

The article leads readers through the federation process, in which OpenSSO acts as the identity provider (IdP) and Google Apps as the service provider (SP). Security Assertion Markup Language (SAML) version 2 serves as the SSO protocol for creating a Circle of Trust on the IdP.

For the convenience of their readers, the authors point out videos that demonstrate the several steps involved in the subject process, noting that each requires the installation of the Apple QuickTime plug-in:

Prerequisites

As a first step, one must have a premier account for Google Apps and download the following software:

• Sun OpenSSO Enterprise 8.0, the latest commercial release of OpenSSO; or the latest Sun OpenSSO Express stable build (build 6 or later)

• An OpenSSO-supported Web container (see "Supported Web Containers" on page 11 of the Sun OpenSSO Enterprise 8.0 Release Notes for the choices)

The authors note that the example in their article uses GlassFish v2 Update Release 2 as the container.

Procedure

The five-step procedure involves the following actions, preceded by performing the predeployment tasks for one's container, which is detailed in the OpenSSO Enterprise Release Notes. Then, perform the following steps:

• Step 1: Deploy the OpenSSO WAR File. This involves becoming root and typing in the code the authors provide. Next, one must start and stop GlassFish. Once again, code is provided.

• Step 2: Configure OpenSSO, using the configuration wizard on one's browser (access the container and the OpenSSO context). The video provides the configuration steps.

• Step 3: Configure the IdP on OpenSSO, using the OpenSSO workflow wizard in the Administration Console. Steps in the procedure are demonstrated in the video.

• Step 4: Configure the SP on Google Apps. Again, the video demonstrates the process.

• Step 5: Map the Name Identifier. The video shows how to accomplish this.

Testing

It is possible to test the federation by going to ttp://mail.google.com/a/domain_name. If SSO works, the authors continue, you will be redirected to the OpenSSO login screen instead of the traditional Google login screen. Simply sign in with the appropriate user ID and password. The article shows how to view the behind-the-scenes exchanges of SAML v2-based SOAP messages.

Enabling SSL on JBoss 4.2.0

Delete existing certificates

This is step is not strictly required but it helps to get rid of previously created certificates (in case you have been playing around with the keystore). Run the following commands:

keytool -delete -alias localhost
keytool -delete -alias localhost -keystore “C:/Program Files/Java/jdk1.5.0_14/jre/lib/security/cacerts”

The first command removes the certificate with alias localhost from the user keystore, the second deletes the certificate from the system trusted certification repository.

The cacerts file is basically the system keystore which stores the CA (Certification Authority) certificates and can be found at ${java.home}/jre/lib/security/cacerts

Generate certificate

The certificate can now be generated running:

keytool -genkey -alias localhost -keyalg RSA

The certificate is generated and added to the keystore using the alias localhost while RSA is the recommended algorithm to be used to generate the key pair.

Export certificate to a file

The certificate is exported:

keytool -export -alias localhost -file localhost.cer

The certificate with alias localhost is retrieved from the keystore and stored in the locahost.cer file.

Import certificate into trusted Cert repository

keytool -import -file localhost.cer -keypass changeit -keystore “%JAVA_HOME%/jre/lib/security/cacerts”

The certificate stored in the localhost.cer file is uploaded in the system keystore and added to the list of trusted certificates.

The following can help you to list the content of the keystore (will prompt for password):

keytool -list

JBoss Configuration

Finally edit the embedded Tomcat server.xml which in JBoss 4.2.0 can be found at

${JBoss.home}\server\default\jboss-web.deployer\server.xml

and add the SSL Connector

Now you JBoss container should be able to run on SSL: https://localhost

Tips

• The user keystore is called .keystore and located in the {user.home}. It is created the first time the keytool genkey command is used on a keystore which doesn’t exist (i.e. can be removed if you need to re-create it from scratch).

• Create the certificate using cn=localhost as in my examples: CN field normally holds the name of server host.
• When prompted use changeit as password as it is the default keystore password.
  
  

SUN OPENSSO

• Comprehensive solution to solve all Single Sign-On (SSO) challenges for internal and external applications and Web services
• First integrated solution for managing SSO, authorization, and personalization in Web, federated, and Web services environments
• Simple to Use
• Simple to Deploy
• Simple Understanding Documentation