Configuring OpenAM IDP Proxy with ADFS and Salesforce


This post will describe how OpenAM can be configured as a hosted SAML Identity Provider Proxy with Salesforce acting as Service Provider, and Active Directory Federation Services 2.0 as the Identity Provider. Note that this use case uses Salesforce as the Service Provider. Note that to a Service Provider, an IdP Proxy looks like an ordinary IdP. Likewise, to an Identity Provider, an IdP Proxy looks like an SP. Thus an IdP Proxy has the combined capability of being both an IdP and SP.

The following table is lifted from Spaces. Like a Web (HTTP) Proxy, an IdP Proxy delivers increased efficiency, security, and flexibility.

Web Proxy IdP Proxy
Efficiency ..cache web pages ..cache attributes
Security ..controlled access to web pages ..controlled access to federation IdPs
Flexibility ..HTTP request/response filtering ..SAML request/response filtering

Presented here is the IdP Proxy flow:

  1. A browser client requests a web resource protected by a SAML SP (Salesforce). If a security context for the principal already exists at Salesforce, skip to step 14.
  2. The client is redirected to the IdP component of the IdP Proxy (OpenAM-IdP0), which is protected by the SP component of the IdP Proxy (OpenAM-SP1).
  3. The client makes a SAML AuthnRequest to the SSO service at OpenAM-IdP0. If a security context for the principal already exists at OpenAM-IdP0, skip to step 10.
  4. The AuthnRequest is cached and the client is redirected to the terminal IdP (ADFS). ADFS presents a BA prompt for authentication by default.
  5. The client makes a SAML AuthnRequest to the SSO service at ADFS. If a security context for the principal does not exist, ADFS identifies the principal.
  6. ADFS updates its security context for this principal, issues one or more assertions, and returns a response to the client.
  7. The client submits the response to the assertion consumer service at OpenAM-SP1. The assertion consumer service validates the assertions in the response.
  8. OpenAM-SP1 updates its security context for this principal and redirects the client to OpenAM-IdP0.
  9. The client makes a SAML AuthnRequest to OpenAM-IdP0, the same AuthnRequest made at step 3.
  10. OpenAM-IdP0 updates its security context for this principal, issues a single assertion, and returns a response to the client. The response may also contain the assertions issued by ADFS at step 6.
  11. The client submits the response to the assertion consumer service at Salesforce. The assertion consumer service validates the assertions in the response.
  12. Salesforce updates its security context for this principal and redirects the client to the resource.
  13. The client requests the resource, the same request issued at step 1.
  14. The resource makes an access control decision based on the security context for this principal and returns the Salesforce landing page to the client.


For starters, please refer to Victor’s excellent post about preparing the metadata files for a similar scenario at SAMLv2 IDP Proxy Part 1.

Follow steps 1-4 in that post to prepare your metadata.

Federation Entities in OpenAM

In this section we will survey the entities you have imported in OpenAM so far:

Circle of Trust


Remote Service Provider: Salesforce

Your settings should be very similar to those presented here:

Signing and encryption can be turned off, if not needed.

This screen shows a critical settings related to the IDP Proxy. Ensure your ADFS 2.0 Entity ID is correctly defined in the list.

Remote Identity Provider: ADFS 2.0

Hosted IDP Proxy

IDP Section

Set “test” as the signer certificate in the IDP section of the Hosted IDP/SP proxy entity.

IDP Section continued..


SP Section

The first page..

Assertion processing screen..

The mapping shown below is critical. Here we map the ADFS credential to an internal (anonymous) user, in our case it is “demo”. It could be “anonymous” if such a user is present in your user repository.

Since ADFS does not support Scoping elements, also necessary to achieve this integration is a custom Service Provider adapter that removes the Scoping element from SAML AuthRequest sent to ADFS.

SP Section Continued..

Add the Entity ID for Salesforce here:


Preliminary Steps: Configure OpenAM

1. Import certificates into OpenAM keystore and Java keystore:

/usr/java/jdk1.7.0_45/bin/keytool -importcert -alias sfdc -file SelfSignedCert_09Mar2014_053347.crt -keystore keystore.jks
/usr/java/jdk1.7.0_45/bin/keytool -importcert -alias adfs -file adfscert.cer -keystore keystore.jks
/usr/java/jdk1.7.0_45/bin/keytool -exportcert -alias adfs -file adfscert.crt -keystore keystore.jks
/usr/java/jdk1.7.0_45/bin/keytool -exportcert -alias sfdc -file sfdc.crt -keystore keystore.jks
/usr/java/jdk1.7.0_45/bin/keytool -importcert -alias adfs -file ccgadfs.crt -trustcacerts -keystore /usr/java/jdk1.7.0_45/jre/lib/security/cacerts
/usr/java/jdk1.7.0_45/bin/keytool -importcert -alias sfdc -file sfdc.crt -trustcacerts -keystore /usr/java/jdk1.7.0_45/jre/lib/security/cacerts

2. In OpenAM, after importing the metadata files, add the Federation Authentication Module under /local realm

Step 5: Creating the Single Sign On settings in Salesforce

In Salesforce, under Security Controls -> Single Sign On Settings, create a new “SAML Single Sign-On Setting”, and fill in the Identity Provider Login URL, and Logout URLs from the metadata file “” in Step 4.a.

Step 6: Importing the Service Provider descriptor from the IdP Proxy into ADFS 2.0

On the Windows server, start up AD FS 2.0 Management utility, and create a new relying part trust, by cliking on “Add Relying Party Trust”.

Select “Import data about the relying party from a file”, and use the “” you created in Step 4.c. Call it “Salesforce via OpenAM IDP Proxy” and finish.

Select the newly created relying party and ensure the settings match the screenshots presented here.

For example, change the default SAML ACE from Artifact to POST.

Also, change the secure hash algorithm to SHA-1 as shown here.

Click on “Edit Claim Rules” and follow instructions given in OpenAM and ADFS2 configuration to create the first rule.

Create a custom claim rule using the following script:

c:[Type == ""] => issue(Type = "", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties[""] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified", Properties[""] = "<entity-id of ADFS 2.0>", Properties[""] = "<entity-id of your IDP proxy>");

You should see two rules now:

Click ok to finish editing claim rules.

Optional ADFS 2.0 configuration

You can configure ADFS to not encrypt or sign SAML responses. Follow these steps if necessary:

  1. Use Windows Power Shell to check for installed ADFS snap-in: Get-PSSnapin -Registered
  2. You should be able to see: Microsoft.Adfs.PowerShell 1.0 “This powershell snap-in contains cmdlets used to manage Microsoft Identity Server resources”
  3. Now proceed to add it : Add-PSSnapin Microsoft.Adfs.Powershell
  4. Configure ADFS to not encrypt SAML response: Set -ADFSRelyingPartyTrust -TargetName “Salesforce via OpenAM IDP Proxy” -EncryptClaims $False
  5. **If you get an erroneous SAML StatusCode “Responder” error in OpenAM during testing, run these commands to turn off certificate revocation checks in ADFS:
    1. Set-ADFSRelyingPartyTrust -TargetName “Salesforce via OpenAM IDP Proxy” -EncryptionCertificateRevocationCheck ‘None’
    2. Set-ADFSRelyingPartyTrust -TargetName “Salesforce via OpenAM IDP Proxy” -SigningCertificateRevocationCheck ‘None’


Navigate to your Salesforce SSO URL, you will immediately be taken to the ADFS basic authentication prompt:


Enter your ADFS domain credentials here and hit Log In. If all is well, you should be taken to your Salesforce landing page.

SAML2 as ForgeRock OpenAM 13 Authentication Module Instance

This blog post was first published @, included here with permission.

Well, you’ve possibly heard about the release of newer version of the ForgeRock Identity Platform with several enhanced capabilities. If not, you can read about it all here. One of the new features in the Access Management component of ForgeRock Identity Platform is SAML2 Authentication Module. What that offers is, after configuring Federation, we could supply all the required details like the IDP entity, the binding method etc. in an Authentication Module instance of the ForgeRock Access Management solution and use it just like any other Authentication Module (LDAP, Database, HOTP etc.). Let’s see how that’s done in a video demonstration that follows this write up. And, by the way, if you’d like to get a quick idea what’s new in the newer version of ForgeRock Access Management solution, read the release notes here.

We’ve already discussed OpenAM Federation on this space before. Here’s list of links from the past:

ForgeRock OpenAM Federation Using SAML v2
Using SAML Assertion Attributes in ForgeRock OpenAM

While the following video walks through the OpenAM Federation Configuration from the scratch, if you feel there are details missing in it, please feel free to have a look at the web logs mentioned above. The main focus of the screen-cast below is only to see how SAML2 is used as an Authentication Module instance in the version 13 of ForgeRock OpenAM.

The following illustration might give a quick idea on what’s demonstrated in the video embedded below this post.

Now on to the screen-cast. Enjoy!

Enabling Single Log Out Support

The SAML2 Post Authentication Plugin (org.forgerock.openam.authentication.modules.saml2.SAML2PostAuthenticationPlugin) is an optional component which can be added to a chain which includes the SAML2 authentication module. It is responsible for configuring the session in such a way that it correctly responds to IdP-initiated single logout requests, and can additionally be configured to support SP-initiated single logout.

Supporting IdP-initiated single logout

By adding the SAML2 Post Authentication Plugin to your authentication chain, sessions which are logged in to your SP will be logged out when the IdP initiates logout (this may be a rather jarring experience for them, as they will simply be kicked out of the system upon the next action performed in the SP’s service). There is no additional configuration required, and supporting SP-initiated single logout is not required if not desired.

Supporting SP-initiated single logout

By setting the Single Logout Enabled boolean inside the authentication module’s configuration to true, a request to log out from the SP will attempt to log out the IdP’s logged in session also. Upon successful logout from the IdP, the user will be redirected to the value provided in the Single Logout URL field – this value must be a fully-qualified URL. You may not support SP-initiated single logout without supporting IdP-initiated single logout.

SAML2 in-chain authentication – The SAML2 Auth Module

The SAML2 authentication module is a new addition to OpenAM13. It comprises three new components which work together along with OpenAM’s SAML2 implementation to provide integrated SAML2 authentication to a standard OpenAM authentication chain. There are some limitations on the use of the new module – it supports HTTP-Artifact and HTTP-POST bindings and HTTP-Redirect and HTTP-POST request bindings. The new components are:
      • A new SAML2 authentication module
This is the authentication module that performs the bulk of the work. It handles identifying the user by sending them off to the remote identity provider, and – if appropriate – executing a sub-authentication chain which links the remote account to a local one.
      • A new assertion consumer endpoint
This assertion consumer endpoint differs slightly from the default OpenAM SAML2 endpoint, as it knows that it’s responsible for pushing the user agent back into the appropriate authentication chain. A SAML2 SP which utilises the authentication module must
      use the new assertion consumer endpoint.
    • A new post authentication plugin
This acts to enable IdP-initiated single logout support, and to configure and enable SP-initiated single logout. If you’re familiar with the function of OpenAM 12’s SP implementation, the authentication module’s configuration page will be very familiar to you. The parameters filled in here can – for the most part – be thought of simply as query parameters which would be sent to the old spsssoinit endpoint. Each option is explained in terms of its function in relation to the SAML2 process both in the administrator UI and the OpenAM 13 documentation, as such they won’t be enumerated here. However, articles here will cover the options necessary to configure to be able to set up each example. The SAML2 authentication module is a first factor module. That is, it results in the authentication modules following this module knowing the identity of the user in the local datastore the SAML2 module pointed to. This may be a newly Federated and generated user (see Dynamic Account Federation and Local Account Linking Account Federation examples) or an anonymous user (see article Anonymous Session Generation With Attribute Federation). Finally, the SAML2 authentication module is the first module to contain the ability to perform a secondary authentication chain whose result acts as a component to this module. All this is explained in the Local Account Linking Federation example.

ForgeRock OpenAM Federation Using SAMLv2

This blog post was first published @, included here with permission.

If you experience Deja Vu by looking at the illustration just below, chances are that you’ve hit my blogs before, in particular on this entry, where we looked at ForgeRock OpenAM as an Identity Provider and ForgeRock OpenIG as a Service Provider.

A friend asked me if I could demonstrate a very simple configuration of Federation using two ForgeRock OpenAM instances, one acting as an Identity Provider (a.k.a IDP) and another one taking up the role of a Service Provider (a.k.a SP). It wasn’t difficult to do one, so here we have it embedded towards the end of this post.


So what do we have here:

– A Circle of Trust which has two OpenAM instances, one of which acting as an Identity Provider and another one as Service Provider
– User always authenticates against the Identity Provider
– The authentication process is intiated either by the IDP (known as IDP initiated SSO) or by the SP (SP initiated SSO)
– Once the user is authenticated successfully, IDP sends across a piece of security information to the SP (known as assertion) that could contain user attributes
– SP then gives the user access to protected resources

In the demonstration that follows, because ‘Auto Federation’ is not enabled, during the first login the user will be prompted for credentials both by the IDP and the SP. Once the account linking is done, it’s only the IDP who would challenge the user.

If the illustration and the briefing above hasn’t given you the complete picture, the video below might give a better one.


European Open Identity Summit – Review

This week saw the first European Open Identity Summit hosted by identity management vendor ForgeRock [1].  Following hot on the heels of the US summit, that was in Pacific Grove, California in June, the sold out European event, brought together customers, partners, vendors and analysts from the likes of Salesforce, Deloitte, Forrester and Kuppinger Cole amongst others.

Whilst the weather was typically October-esque, the venue was typically French chateau, set in panoramic grounds, with great hosting, food and wine to keep everyone in a relaxed mood.

The agenda brought together the key themes of the modern identity era, such as standards adoption (XACML, SAML2, OAuth2, OpenID Connect, SCIM), modern implementation approaches (JSON, API, REST) through to the vision for modern identity enablement for areas such as mobile and adaptive authentication, all whilst allowing customers and partners a chance to collaborate and swap war stories with some great networking.

Consumer Identity As A Revenue Generator

I have discussed the evolution of identity management on several occasions over the years (not least in August!), with the current iteration seeing a strong focus on utilising the identity of the consumer, as an approach to help drive new and existing revenue, for services and applications.  By capturing consumer identity details, either via portal facing registration systems, or making services available online, brand stickiness can be increased and a more relationship based approach can be developed. Developing platforms for consumer focused identity, requires several key components, mainly scale, modularity and agility.

Salesforce Expand Identity Offering

One of the key announcements at the summit was the expansion of the identity offering, by CRM software as a service giants, Salesforce.  With the Identity Connect platform, Salesforce and ForgeRock have entered into an OEM agreement, where the ForgeRock Open Identity Stack is used to enable the Salesforce solution to allow enterprises to seamlessly integrate with existing on-premise identity directories, with additional SSO capabilities.  Salesforce hope the solution will accelerate the onboarding of new and existing client accounts into their portfolio of online services. This is yet another example of organisations seeing customer identity as a key strategic component of business enablement and revenue generation.

Passwords Are Dead...Long Live The Password!

One of this years keynote speakers was Forrester's Eve Maler.  Always an articulate presenter, Eve dropped the bombshell that 'passwords are dead...'.  Whilst this isn't probably the most surprising announcement in the identity and infosec worlds, there is still to be defined, a clear way to replace the use of passwords as an authentication mechanism.  This is a topic I have blogged on multiple occasions (The Problem With Passwords Again, Still - Oct 2012, The Password Is Dead (Long Live The Password) - Feb 2012, Passwords And Why They're Going Nowhere - Mar 2013).  The failures of password use, storage and implementation are well known, but they are now too well embedded technically and psychologically, that a simple passage to something resembling biometric sustainability is somewhat remote.  Answers on a postcard with how that can be obtained!

The Future is Bright

Everyone loves modern - modern art, modern fashion, cutting edge music, the latest tech gadgets, but where does that leave modern identity management?  Modern in this respect, shouldn't just be focused on the new and shiny.  It needs to be focused on the new and useful.  Mobile devices are clearly the key component for information access, either via smart phones or tablets.  The desktop is dead and the laptop not far behind.  Modern identity needs to integrate seamlessly with mobile devices, utilising native technologies and loosely coupled REST based APIs and integration points.  Modern identity must also be convenient and easy to use.  Security in general is bypassed when too restrictive or complex and modern identity is no different.  For authentication and authorization processes to be effective, they need to convenient, good looking and easy to use.

The summit was a great event, that produced some interesting and thought provoking discussions, highlighting identity management as a key component of many organisations' go-to-market approach for 2014 and beyond.

[1] - For audience transparency, the author is employed by ForgeRock.

The Evolution of Identity & Access Management

Identity and access management is going through a renaissance.  Organisations, both public and private have spent thousands of hours (and dollars) implementing and managing infrastructure that can manage the creation of identity information, as well as management of the authentication and authorization tasks associated with those identities.  Many organisations do this stuff, because they have to.  They're too large to perform these tasks manually, or perhaps have external regulations that require that they have a handle on the users who access their key systems. But how and why is all this changing?

The Enterprise and The Perimeter

Changing Identities
15 years ago, identity and access management was focused on stuff that happened within the corporate firewall.  Employees joined the company, were entered into the payroll system and 'IT' set them up on the necessary systems they needed.  That setup process was often manual, inconsistent and perhaps involved several different application and system owners and administrators.  IT being IT, would look to try and automate that account creation process.  This was driven partly by business benefits (new employees don't need to wait 3 days for to get working) and also the costs savings associated with migrating manual tasks to a centralised provisioning system.

Cloud, Services & The Modern Enterprise

Organisations are not the same as they were 15 years.  I talked about this recently with the onset of the 'modern' enterprise.  What does that mean?  Due to economic changes and changes in working patterns,  organisations are now multifaceted complex beasts.  No one team or department can be associated with a single process or business function.  Supply chains are now swollen by outsourced providers, all rapidly engaged and critical to short term product launches or business deliverables.  These business changes rely heavily on an agile identity management and authentication infrastructure, that can not only quickly engage new partners or suppliers, but also track, authorize, audit and remove users when they are no longer required or a partner contract expires.

Continually Connected

Identity from a consumer sense has also altered.  More and more individuals have an identity context on line.  That could be something like a Facebook or LinkedIn account, right through to personal email, banking and ecommerce as well as consumer outsourced services such as Spotify, Kindle books or iTunes.  Individuals are embracing applications and services that can give them non-physical access to experiences or data stores, all centred about their own identity.  These online consumer identities are only as valid of course, if the identity owner is able to connect to those services and sites.  That connectivity is now ubiquitous, making life experiences richer, whilst increasing demands for consumer scale infrastructure.

Standards and More Standards

I recently watched the Gartner on demand catch up series of the recent Catalyst event, that was neatly titled the "Identity Standards Smackdown".  A panel of 5 leading identity go-getters, represented some of the emerging and long standing IAM standards, promoting their worth in the current landscape.  The five represented were OAuth2, SCIM, XACML, OpenID Connect and SAML2.  The details of each are all varied and there are numerous pro's and con's to each.  What is interesting, is that we are now at a position where all of these standards are now playing a part in both public and private enterprise adoption, acting as catalysts for new service offerings by services and software vendors, as well as acting as a yardstick to aid comparisons, maturity metrics, interoperability and more.

The standards all play slightly different parts in the provisioning, authentication and authorization life cycle, but the healthy debate goes to show the both end user and vendor interest in this space is as hot as it has even been.

By Simon Moffatt