The importance of Audience in Web SSO

When dealing with Single Sign On for Web Applications (Web SSO) the stakeholders involved in offering those applications i.e. developers, architects, application owners and their administrators, tend to care about how to identify and authenticate the end user who is accessing the web application. And in fact that used to be the only thing they really needed to care about in the early days of the web when everything was built and deployed in house. That has changed as time moved along:

  • the range of web applications offered by the same business party today is developed by different software development companies and contractors
  • that suite of applications is deployed on infrastructure belonging to different administrative domains, e.g. an Infrastructure-as-a-Service provider, a hosting party and/or a data center operator
  • those applications are often managed by different parties, e.g. hosting providers,  contractors, managed service providers

Now those developments brought along a challenge in Web SSO since the classic solutions were (and some still are) built on leveraging a single cookie across a set of applications. That cookie presents the identity of the user in a verifiable way by consulting a policy server or by verifying a signature. That is all nice and well except that nature of an SSO mechanism that leverages a single cookie that can be used to access different applications works against itself when different parties are involved in offering those applications: suddenly all of those parties can get a hold of that cookie i.e. an application developer could obtain it through modified code, an infrastructure provider could get it from logs or introspection, an application manager could get it from the application itself or a monitoring system.

wam-token1

But since they obtain that cookie (and they can because their application needs it) they can now also turn around and play it against any of the other applications connected to the same SSO system and thus impersonate the end user in those applications! That is an unacceptable risk for banking and financial businesses but in fact for any company with a reasonable security and compliance policy. In addition to being exposed to this risk when leveraging different external parties to offer applications they are also at risk of employees (application administrators) in one business unit turn bad and hijack applications in other business units.

The way forward is as simple as elegant: make sure that every application receives its own token that cannot be used against another application.  The security property of such a token that makes the difference here is called “audience”. The “audience” defines who the intended recipient of the token is and in the modern web it is just as important as the “subject” i.e. the authenticated end user. You may know the concept from the SAML and OpenID Connect protocols where those tokens are issued by a central entity called Identity Provider but always target a specific recipient.

wam-token2

All of the above is one more reason (warning, long sentence…) to move away from previous-century, single-domain cookie-based legacy Web Access Management Systems towards modern standards-based per-application token based security!

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

6 Responses to The importance of Audience in Web SSO

  1. triggerwave says:

    In the OpenID Connect SSO scenario above, how does the OIDC server determine that the App2 user is currently logged on to App1. If a shared cookie isn’t the mechanism what is?

    • It is a cookie indeed, but that cookie lives on the SSO server/domain only and does not reach the applications; App2 and App1 redirect to the SSO server to determine the authentication status of the user. An application-specific token derived from that cookie comes back in a protocol message. The application in its turn may now set an application session cookie but that is independent of the authentication/SSO mechanism.

  2. triggerwave says:

    Thanks for replying… that’s a great explanation and it makes perfect sense.

    Following on from that I’ve got a further question…
    Now say the marketing dept. insist that http://www.app1.com and http://www.app2.com should access the IDP via the domain of the original login redirect (quote “why would a user trust a login screen on an unrelated URL”). I.e. each application needs to access the IDP on a URL in the same domain as the app e.g. auth.app.com. Is there an elegant way to achieve this following an OpenID Connect implementation.

    I’m sure this must be a pretty common requirement for organisations wanting to implement SSO across multiple web sites on different domains.

    • app1.com and app2.com are not as common as app1.example.com and app2.example.com; in the latter case the SSO server/cookie could live on auth.example.com; in the former case there’s no way to authenticate directly on app1.com; the whole point of federated SSO is to pass your credentials only to a single domain that you trust and that would be example.com, not app1.com or app2.com since those may not be managed by your organization

  3. triggerwave says:

    Hi Hans,

    How about this scenario: user logged in against app1.example.com and attempts to log into app2.com, which we want to participate in an SSO experience. At which point we present the user user the option of logging on via auth.example.com or entering their credentials?

    Hummm, still doesn’t feel right. So the problem here is that there are a number of distinct domains which we want to register as RPs but we don’t want the user to see the redirect URL on the IDP which is going to manage the AuthN/Z.

    Any thoughts?

    Michael McD.

  4. not really a way around this, that’s the point of 3rd-party logon, but you could complete the process in a popup window; renaming the domains is probably a better idea 😉

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s