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.
Figure 10. SAML destination site settings
|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
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
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.
auth.jsp page will now be displayed. This page shows a link to
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
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.
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:
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
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