X

Best Practices from Oracle Development's A‑Team

OAM Federation 11.1.2.3: Performing a loopback test with WS-Federation

In a previous post I gave steps for performing a loopback test with SAML. This is where we configure OAM Federation to talk to itself, to act as both IdP and SP. This is useful in development and test environments to confirm OAM Federation is working without requiring an external server to talk to at the other end. So in this post, I want to do the same for WS-Federation (WS-Fed).

SAML vs WS-Fed

Support for WS-Federation (WS-Fed), and specifically the WS-Fed Passive Requestor Profile (WS-Fed PRP), was introduced in OAM Federation 11.1.2.3. Support for WS-Fed PRP in OAM 11.1.2.3 is similar to the support for WS-Federation in the 11.1.1.x Oracle Identity Federation (OIF) standalone product. OAM Federation 11.1.2.3 does not support the WS-Fed Active Requestor Profile.

WS-Fed is a competing federation protocol to SAML: the capabilities each provides are largely similar, but the underlying protocols are different and each uses distinct terminology. Most vendors, including Oracle, have focused on SAML for identity federation; WS-Fed has seen limited adoption outside of Microsoft-centric environments. Given that, if you have a choice, I would strongly recommend using SAML over WS-Fed.

There are two primary cases in which the need for WS-Fed may be encountered:

  • Active Directory Federation Services (ADFS): since this supports both SAML and WS-Fed, either protocol could be used for integration with OAM Federation. But the SAML-based integration should be preferred, since that is what most customers with this use case successfully use.
  • ASP.NET and WCF applications: the Windows Identity Federation (WIF) component shipped with .NET 4.5 and later supports WS-Fed protecting ASP.NET and WCF applications simply through XML configuration changes (i.e. no code required.) By contrast, while it does include some .Net classes for validating SAML tokens, it does not contain a complete implementation of the SAML protocol, so ASP.NET/WCF applications cannot be federated with SAML unless you either write some custom code, or use third party components. Due to this, when you have existing ASP.NET/WCF apps, migrating them from WS-Fed to SAML can be time-consuming.

Given this situation, the main use case for using WS-Fed with OAM Federation is ASP.NET or WCF applications.

Configuring OAM for the WS-Fed loopback test

We assume you have OAM 11.1.2.3 up and running, and that you have enabled the Federation Service in the OAM console. Also, note that if you did the SAML Loopback test from my previous blog post the SAML and WS-Fed Loopback test configurations cannot co-exist at the same time. This is because OAM Federation only supports a single protocol per a provider URL - either SAML or WS-Fed. In practice, this should not be an issue, since if a given provider URL supports multiple protocols, it makes sense for OAM to use one of those protocols only to communicate with it.

In order to configure a WS-Federation partner, you need to use WLST commands. The OAM Console web application cannot create or edit WS-Federation partners, although it can be used to delete them.

We need to export the certificate stscertalias from the $DOMAIN_HOME/config/fmwconfig/.oamkeystore
Use this command:

$JAVA_HOME/bin/keytool -exportcert -keystore $DOMAIN_HOME/config/fmwconfig/.oamkeystore -storetype JCEKS -alias stscertalias -file /tmp/stscertalias.cer -v

When it asks you for the password, you can just press ENTER and ignore the WARNING. (You don't actually need to know the password to export the certificate.)

Next we run the following commands using $OAM_ORACLE_HOME/common/bin/wlst.sh:

connect("weblogic","welcome1","t3://ADMINSERVERHOST:ADMINSERVERPORT") domainRuntime() configureTestSPEngine("true") deleteFederationPartner(partnerName="LoopbackIDP", partnerType="idp") deleteFederationPartner(partnerName="LoopbackSP", partnerType="sp") addWSFed11IdPFederationPartner(partnerName="LoopbackIDP", providerID="http://OAMHOST:OAMPORT/oam/fed",ssoURL="http://OAMHOST:OAMPORT/oamfed/idp/wsfed11") addWSFed11SPFederationPartner(partnerName="LoopbackSP", realm="http://OAMHOST:OAMPORT/oam/fed", ssoURL="http://OAMHOST:OAMPORT/oamfed/sp/wsfed11") setFederationPartnerSigningCert(partnerName="LoopbackIDP",partnerType="idp",certFile="/tmp/stscertalias.cer")

Of course, you will replace ADMINSERVERHOST, ADMINSERVERPORT, OAMHOST and OAMPORT with appropriate values for your environment.

Note that we are calling configureTestSPEngine() to run enable the OAM Federation test page - we will use that in our testing below. Note also that we are calling deleteFederationPartner() to delete the federation partners first. The first time you run this script, these two commands will print an error. However, by including them, we make it possible to run the script multiple times, and have it delete any existing provider by that name before creating the new one.

Performing the loopback test

Open a new private browsing window, and go to the URL http://OAMHOST:OAMPORT/oamfed/user/testspsso, you should see the following displayed:
WSFedBlogPost-001
(Note: if you find the screenshots hard to read, click on them to load higher resolution versions)

Selecting "LoopbackIDP", and clicking on "Start SSO", we should get the OAM login page:
WSFedBlogPost-002
I try logging in as "weblogic", and then I get this error:
WSFedBlogPost-003
What went wrong here? Out-of-the-box, the "weblogic" user included in the Embedded WebLogic LDAP does not have an email attribute, which is what we use by default as our NameID format. To fix this, I can set an email attribute on that user. Go to WLS console > Security Realm > myrealm > Users and Groups > Users > weblogic > Attributes. Find the “mail” attribute (it should be on the second page), click on its Value table cell, and enter an email address (e.g. weblogic@example.com):
WSFedBlogPost-004
Then press ENTER to save. Now if we try the test again using a new private browsing window, it works:
WSFedBlogPost-005
Note: if you don't use a new private browsing window, and try the test again with the original window, you will get the same error again. This is because OAM Federation does not pick up the change in email address until the user logs out and logs in again.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha