The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.



When trying to interoperate with Oracle delivered applications there are a few options that are known to work using native Oracle technologies.

Weblogic Native - SAML1 RP

It is possible to setup a Weblogic container as a SAML1 RP that can work with your Shibboleth IdP. 

More notes here later... but this does work.

Quick notes:

  • NameID coming in (subject) needs to map to the userid at the Weblogic container. 
    • There is an internal weblogic sudo-ldap facility that can be used for starters.  
  • You must specify the NameID format in the md on the IdP side
  • I believe pushing on the saml1 response was ok.. again i'll have to revisit

Oracle Identity Federation - SAML2 RP

It is possible to setup / configure Oracle Identity Federation (OIF) as a SAML2 RP that communicates with your Shibboleth IdP. The main reason one would want to do this is to enable access to any number of oracle specific applications that can use native OAM / OSSO for user access. Effectively what you are doing is creating a bridging service that will delegate some degree of SSO to your Shibboleth IdP.

The remainder of this article assumes you have OIF installed and are past the Oracle Middleware install idiosyncrasies.

You will be configuring OIF using the Oracle Enterprise Manger 11g (OEM) GUI.

Overall Steps

  1. Bootstrap the "Federation" – upload metadata to define your IdP
  2. Configure Server Properties – ports, etc
  3. Configure your Service Provider
  4. Export your Metadata
  5. Fixup and import metadata to your Shibboleth Environment
  6. Enable the SP Integration modules: Test SP and Oracle Single-Sign-On
  7. Test round trip with the OIF Testing SP
  8. Configure the mechanics between OIF and OAM 
  9. Configure release at your Shibboleth IdP
Locations of Interest (for config)


Oracle Enterprise ManageerHTTP://OIF-HOST:OIF-ConsolePort/em


If you are taking defaults from the OIF / OAM install you will end up with the following ports: SP port 7499, Admin Console port 7001, OAM hooks port 14100


Create a Federation in OIF

To boot strap things to a running state in our environment we need to configure how our Federation will look (according to OIF).

OIF dropdown > Administration > Federations : Add , Enable Provider , Load Metadata (upload file)

Configure the OIF SP

This is the piece we are after (SP) to create our bridge into the Oracle Single-Sign-On (OSSO) space.

OIF Dropdown >> Administration >> Service Provider

The Service Provider will be using the assertion sent by the IdP to map the user into an OSSO Id.  Configure the Oracle SP to Map the Assertion to the User account, then configure to map the user via Attribute Query.

 This is not an attribute query back to the IdP rather we are "querying" the attribute stack we have just received via the assertion.


Obtain OIF Metadata

We need to produce some metadata on the OIF side so we can import this into our IdP metadata feed(s).  Obtain the OIF metadata from here

OIF Dropdown >> Administration >> Security and Trust

Use the Provider Metadata tab to find the Generate Metadata pane and button.

Save the generated XML metadata file and load that into your Shibboleth IdP config.

You will want to remove some XML properties / elements such as ValidUntil. You will also want to ensure that the NameId requested in metadata matches your release from the IdP.

Enable the SP Integration modules: Test SP and Oracle Single-Sign-On

Here we enable to integration points the Test SP and the Oracle Single-Sign-On module.

OIF Dropdown >> Service Provider Integration Modules

Test round trip with Test SP module



Register OAM with OIF

Register DAP token.. 

Configure release at Shibboleth IdP

You will need to configure a filter for this entityID such that only the NameID that you are expecting gets used in the assertion.  This needs to be something that will be locatable on the RP side (OAM) as an actual user.  In our case this is the netid of the user.