Configuring Single Sign-On using SAML in WebLogic Server 9.2

Step 10: Configure the SAML 1.1 destination site

In this step I'll configure various destination site settings for the server instance running application appB. These settings enable a server instance running on domainB to serve as a SAML destination site, define service URIs (for example, Assertion Consumer Service URI), add a certificate to sign POST profile responses, and configure SSL for the Assertion Consumer Service.

  1. In the administration console, select Environment, and then select Servers in the Domain Structure window.
  2. Select AdminServer, and then in the Settings for AdminServer, click Federation Services, and then the SAML 1.1 Destination Site tab, as shown in Figure 10.

SAML Destination Site Settings
Figure 10. SAML destination site settings

  1. Set the destination site values, as listed in Table 6.
Parameter Value
Destination Site Enabled Select the checkbox(true)
Assertion Consumer URIs /samlacs/acs
ACS Requires SSL  Select the checkbox(true)
SSL Client Identity Alias  testalias
SSL Client Identity Pass Phrase  testkeypass
POST Recipient Check Enabled Select the checkbox(true)
POST one Use Check Enabled Select the checkbox(true)
Used Assertion Cache Properties APID=ap_00001

Table 6. Destination Site Values

Test Single Sign-On

To test single sign-on, open a browser and point to the URL http://localhost:7001/appA/. The FORM-based authentication configured for appA will display the login.jsp page, as shown in Figure 11. Enter ssouser and demosaml as the values (created in step 2).

appA Application
Figure 11. Browser showing appA login

This will authenticate the user using the default authenticator configured for domainA.

The auth.jsp page will now be displayed. This page shows a link to appB ( http://localhost:7003/appB/admin/services.jsp), as shown in Figure 12. Clicking this link will trigger a call to the ITS servlet and cause the assertion to be generated and the control to be transferred to the destination site.

appA Login Success
Figure 12. Browser showing appA successful login with destination site (appB on domainB) link

Once the assertion is validated on the destination site, the ssouser is allowed to access the services.jsp page, as shown in Figure 13.

appB Successful Login
Figure 13. Browser showing appB successful login with SSO

What if ssouser visits the destination site first? In Step 9, when the asserting party was configured, the Source Site Redirect URI was set to URI /appB/admin/services.jsp. This is the URI from which the unauthenticated user will be redirected to the ITS URL, https://localhost:7001/samlits_ba/its, of the source site. This is done to support the destination site first scenario, whereby a user tries to access a destination site URL prior to being authenticated and is redirected to the source site to be authenticated and then obtain a SAML assertion. The ITS servlet at the source site will challenge the user to supply a username and password. Upon successful authentication, the redirection to the destination site is issued, and the /appB/admin/services.jsp page is displayed.

Debugging Notes

You can enable SAML security debugging to see how the source and destination site interact using the SAML SSO process. To enable SAML security debugging:

  1. In the administration console, select Environment, and then select Servers, in the Domain Structure window.
  2. Select AdminServer and then the Debug tab.
  3. In the Change Center window, select Lock and Edit; this will allow you to edit the debug settings.
  4. In the Debug Scope and Attributes, click to open the weblogic > security > saml node. Select the checkbox to enable SAML debugging, as shown in the Figure 14.
  5. In the Change Center window, click Activate Changes.

SAML Debugging
Figure 14. Showing WebLogic console enabling SAML debug

You can then view the AdminServer log file on domainA (source) and domainB (destination) to debug the SAML-related issues (Figure 15).

SAML Debugging
Figure 15. AdminServer log showing SAML interactions



The tutorial shows how SAML source and destination site domains can be configured to allow Web applications on these domains to operate in a federation of trust based on successful single sign-on to the SAML source site Web application. This is a powerful paradigm, completely configured using the administration console, providing immediate benefit to users of your many applications.


Vikrant Sawant is Senior IT Specialist at the Legislative Counsel Bureau, California. He has over 14 years of experience in software development and has worked extensively in Java and Java EE based projects