Configuring Single Sign-On using SAML in WebLogic Server 9.2

by Vikrant Sawant
01/04/2007

Abstract

BEA WebLogic Server 9.2 provides out-of-the-box support for Security Assertion Markup Language (SAML) to build single sign-on (SSO) solutions with minimum or no coding, depending on your security requirements. Using WebLogic Server 9.2, the single sign-on capability can be easily added between multiple online applications running on trusted domains. The SAML standard defines a framework for exchanging security information between the federation of trusted servers. The primary function of the security framework is to provide configuration tools and APIs to secure your applications.

This tutorial provides step by step instructions to configure the single sign-on capability between two simple Java EE Web applications running on two different WebLogic domains. The SAML configuration for single sign-on is performed using the WebLogic Server 9.2 Administration Console with no programming involved. The tutorial also briefly introduces the basic interactions between WebLogic containers, the security providers, and the security framework during the single sign-on process.

Introduction

The SAML standard defines a framework for exchanging security information within the federation of trusted servers. For some background, read Introduction to SAML by Beth Linker (Dev2Dev, 2006). This tutorial shows how to set up SAML authorization between two Web applications. The source for these applications is provided here.

This tutorial looks at a simple example involving two Web applications; appA deployed on the source (local) site, and appB deployed on the destination (remote) site. You'll learn how to configure these applications using the WebLogic Server 9.2 Administration Console and participate in a SSO process using SAML.

The source site provides an authentication service and securely passes the authentication details using SAML Inter-site Transfer Service (ITS) when requested by the destination site. The server on the source site includes an ITS servlet, which is an addressable component that provides SAML processing functionality such as artifact generation and the ability to redirect a user to the destination site.

Figure 1 shows the basic interaction between source site and destination site during the SSO process.

Figure 1. Interaction between source site and destination site, using SAML, during single sign-on

1. The user's browser accesses the application appA(source site), hosted on a WebLogic Server domain, called domainA, by supplying user credentials.
2. The application appA passes the user credentials to the authentication service provider.
3. If authentication is successful, the authenticated session is established, and a welcome page of appA is displayed.
4. From the welcome page, the user then clicks on a link on the page to access a secured Web page of application appB (destination site), hosted on a different WebLogic Server domain, called domainB. This triggers a call to the Inter-Site Transfer Service (ITS) servlet.
5. The ITS servlet calls the SAML Credential Mapper to request a caller assertion. The SAML Credential Mapper returns the assertion. It also returns the URL of the destination site application Web page (a secured Web page of appB) and path to the appropriate POST form (if the source site is configured to use the POST profile).
6. The SAML ITS servlet generates a SAML response containing the generated assertion, signs it, base-64 encodes it, embeds it in the HTML form, and returns the form to the user's browser.
7. The user's browser POSTs the form to the destination site's Assertion Consumer Service (ACS).
8. The assertion is validated.
9. If the assertion is successful, the user is redirected to the target—that is, the secured Web page of the appB application.
10. The user is logged in on the destination site application appB, without having to reauthenticate at appB.

The whole single sign-on process listed above requires no coding by the developer (except for the coding of applications appA and appB, of course) and can be easily configured using the Administration Console.