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.
- In the administration console, select Environment, and then select Servers in the Domain Structure window.
- 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.
Figure 10. SAML destination site settings
- 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).
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.
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.
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:
- In the administration console, select Environment, and then select Servers, in the Domain Structure window.
- Select AdminServer and then the Debug tab.
- In the Change Center window, select Lock and Edit; this will allow you to edit the debug settings.
- 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.
- In the Change Center window, click Activate Changes.
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).
Figure 15. AdminServer log showing SAML interactions
Download
Summary
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.
References
- Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1 - OASIS Web site on SAML
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