Silently federate from your SAML IdP or OpenID Connect Provider to IDCS

Introduction

As you may know IDCS can operate as both a SAML IdP and a SAML SP at the same time – a use case known as an IdP Proxy or IdP Chaining. This is useful in a bunch of situations, but the most common is when you want users to login to your on premises Identity Provider (e.g. OAM) using their current credentials and then freely access a bunch of stuff in Oracle’s Public Cloud (OPC) without setting up a bunch of point-to-point agreements between your IdP and each of those services individually.

By default when users access an app that relies on IDCS for authentication they will be taken to the IDCS login page where they will be prompted to login with a username and password OR click a button to go to your SAML IdP or OpenID Connect Provider.

But what if you don’t want to show that screen and instead just kick right over to your SAML IdP instead?

Yes, of course IDCS can do that. And here’s how…

IdP Policies in IDCS

The IDCS documentation covers the basics of IdP Policies and walks you through the steps to create or edit one. The very, very short and very simplified version of that text is that an IdP Policy tells IDCS “for these apps show these IdPs”. The default policy shows the IDCS login (i.e. start with username and password) as well as every configured SAML or OpenID Connect provider. But you can add and remove these at will.

And if you remove all but one IdP then IDCS knows that it need not show the screen at all (because why ask a question it already knows the answer to?). So it immediately kicks off federation using the SP initiated flow (for SAML) or the OpenID Connect Authorization Code flow.

Step by Step

To set this up

Login to the admin console, then open the “hamburger” menu () and expand Security and then IDP Policies.

Then create a new one:

 

Give it a name (not shown) and hit next.

 

Click Assign to add an IdP:

Note: Either of those buttons does the same thing – the big green button is just more obvious (and a bigger click target).

 

IDCS will show you a list of all of the IdPs (SAML and OpenID Connect) that you have configured.

 

Something like this:

Just tick the checkbox next to those that you want to use and hit OK.

 

NOTE:

  • If you choose just one IdP on this step then IDCS will skip prompting the user to pick an IdP – after all why should it ask the user a question if there’s only one possible answer?
  • If you choose two or more IdPs then IDCS will show the user a chooser.
  • If you include “Local IDP” then the user will be also be given the option to enter a username and password to be checked by IDCS itself. In other words “Local IDP” means “username and password (and maybe MFA) checked by IDCS itself”.

 

“OK” and Next your way to the Apps screen:

In this step what you’re doing is saying “if the user is attempting to sign in to one of these apps (via SAML, OAuth, or OpenID Connect) then this policy applies”.

 

Finally OK you way out to save the policy you just created.

What happens at runtime

When the user accesses an app that is integrated with IDCS the app should kick off SP initiated SSO (with IDCS as the IdP). IDCS will see that the user is not yet signed in and then that the app they’re accessing is configured in this IdP policy. It will evaluate the policy, see that there is just one IdP added and will immediately starts the SP initiated flow (with IDCS as the SP). The user is then taken to the other IdP (for example your on premises IdP – perhaps OAM) where they will do their login steps (username + password, MFA, WNA, or whatever you decide). When your existing IdP is done it will issue the user a SAMLAuthnResponse and have the browser POST that to IDCS. IDCS processes that, checks the assertion, maps the identity in it to a “local” user, create a local session, and then finally “kick back in” as an IdP to the original app.

The app doesn’t need to know anything about the IdP that actually did the original authentication. In fact the app doesn’t even care how the user authenticated – all it knows is that IDCS says that the user is authenticated and who they are.

What about OpenID Connect?

Up in the intro I said “IDCS can operate as both a SAML IdP and a SAML SP at the same time”. Of course it can also act as an OpenID Connect Provider, an OAuth Authorization Server, and an OpenID Connect Relying party. And you can mix and match all of these – IDCS can be an OpenID Connect RP and/or a SAML SP to let someone else authenticate users, and then a SAML IdP, OpenID Connect Provider, or OAuth Authorization Server for apps that want to rely on IDCS for authentication (and possibly authorization).

Add Your Comment