OpenID Demo Application

Obtaining an OpenID

There are many ways to obtain a OpenID. See the page on the OpenID.net site that lists the various OpenID providers which are commonly used.

Application overview

The example application has just two Web pages demonstrating the radical simplicity of Project Zero. The first is an index page that contains a text area where users can post comments. When the comments are posted, the application uses Ajax technology to send a RESTful request to the server to submit the message. Then, the application makes another Ajax call to obtain the message from the server back to the browser. While this is not a particularly useful application, it will provide enough functionality to demonstrate how OpenID works in Project Zero. Start the application. Now, direct your browser to the http://localhost:8080 to test the sample application.

Login page for the OpenID example application

At this point, we will use the openid_url (todkap.myopenid.com) that was provided by the openid provider to log in. With OpenID, the login request will be redirected over to the OpenID provider site (myopenid.com in this example) and start the authentication process on that site with the appropriate opened_url and password.

Login page for the OpenID Provider

After successfully authenticating with the OpenID provider (myopenid.com), the OpenID provider will redirect the client back to the originally requested page (http://localhost:8080/index.gt), which shows the RemoteUser, groups, and roles the user is a member of. The remoteUser will be the openid_url that was used to log in. The groups will contain a single group called VALID_OPENID_USER, and the role will be populated with OPENID_ROLE. If this is not the case, the user would not be authenticated because only users in the role OPENID_ROLE are permitted to access this resource.

Index page after successful login

Using only trusted OpenID providers

One of the downsides of OpenID is that any site exposing an OpenID provider service can claim a user's identity is valid. This poses a challenge for the relying party (your Web site) to trust all those claims. To assist in limiting this exposure, Zero provides a configuration option to limit which sites the application will trust as OpenID providers. The following demonstrates how to enable this configuration (currently commented out in zero.config), and what happens if the openid_url specified is from an untrusted domain. Note that while this could be done on the client side through JavaScript code, there should always be validation on the server to prevent possible circumventions on the client.

Configuring a white list of trusted OpenID providers

@include "openid/rule.config"{
	"openidLoginPage" : "/openidlogin.gt",
	"allowedOpenidDomains" : ["myopenid.com", "verisignlabs.com",  "blueid.bluehost.ibm.com"]
}

Now that we have configured this option and restarted the application, we will try an untrusted OpenIDProvider. In this example, we will use a fictitious openid_url called 'http://myuntrusteduser.someunknownsite.com'. This results in the following exception being logged to the client for instances where the openid_url provider is not listed in the list of allowedOpenidDomains.

Untrusted OpenId provider error page

Conclusion

OpenID provides increased flexibility for application deployment by enabling applications to leverage third-party authentication providers for handling authentication. Providers such as OpenID have become very common as more users want a single user profile across multiple sites for blogs, wikis, and other social networking activities. Additionally, many Web sites do not want to maintain, or require users to continually provide, the same profile-related information just to ensure that the user credentials are valid.