Overview#

OAuth Scope Example shows an Example

What is the Problem?#

Currently many organizations have a history of various Access Control Models that have been used. When they used mainframes, RACF centrally controlled most application access and most applicaitons were on the mainframe.

As time went on distributed applications were deployed often each with their own Access Control Models.

As enterprises move toward an API Economy and enterprise data is shared between applicaitons via Representational State Transfer (REST) methods and given the current Cybersecurity environment, we find our existing Access Control Models lacking in the ability to:

What is done now?#

In a typical enterprise environment we would have a pipeline similar to:
Request --> API-Gateway --> Routing --> Application Logic --> Data Store

Often, the Application Logic or even the Data Store, determines the Authorization for the Application or API. The problem with this is we have a dependency in our Application (and/or Data Store) for a particular authentication method. As there are many Authentication Methods whenever we decide to change our Authentication Method, we also must change our Application.

If our Objective is to

Let us break down the problem and look at what is needed to determine Authorization.

For Access Control the API needs to know?#

In OAuth 2.0/OpenID Connect#

If you design your Application and are using Google, you make assumptions about the values in the Access Token and Identity Token that may not work when you need to also add Facebook.

OAuth 2.0 + Authentication gives us the tools we need. (ie OpenID Connect)#

OAuth Scopes#

Like permissions scopes specify the extent of the validated aud's access.
  • Listed on the Consent UI (if UI provided)
  • Consent UI is Not standardized

For an Example:#

In our Example the Subject is using a social Login even though they are a customer.

The following Implicit Scope is assigned (based on Authorization Policy) to the OAuth Client (we call the app ArticleReader) for all Successful Access Tokens returned:

  • read_regular
The following OAuth Scopes that could be assigned to the Identity Token based on the Authenticated user:
  • read_regular - for any successful Authentication
  • read_premium - for any Customer
  • read_write - for only employees
So the OAuth Client (ArticleReader) dances with the Authorization Server and we end up with The following OAuth Scopes: In this scenario, then we end up with these scopes within the Identity Token Now, if we look at:
Request --> AccessProxy (Think PingAccess or maybe NGINX) --> Routing --> Application Logic --> Database

--> API-Gateway#

The API-Gateway could do the following:

--> Routing#

Routing, depending on the Architecture could be done with NGIX or IHS or Apache or any of the many Microservice frameworks

Assuming the request gets past the proxy, then the Routing (Think NGINX) now only needs to know:

  • read_regular
  • read_premium
  • read_write
And based on these values, we can determine, perhaps, which route is required. Perhaps, the Router would know where to send each request based on the values of the scopes or aud values.

--> Application Logic#

By the time we get to the Application Logic, there should be little no need for Authentication and hopefully only fine grained Authorization logic embedded within the Application.

One of our many desires is to abstract the Authentication/Authorization logic away from application to a provide more centralized Access Controls and Audited

--> Data Store#

By the time we get to the Data Store, there should be little to no need for Authentication/Authorization logic embedded within the Data Store, perhaps only the Client_id and access permissions needed by the application.

What we are trying to do#

Remember what we are trying to do, is protect API access and optimize resources.
  • From a security perspective, the closer they get to the data, the more serious the breach if it occurred.
  • Likewise, from an optimization perspective, the closer they get to the data, the more resources we have expended.

Questions, Comments and Suggestions are always welcome.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-6) was last changed on 07-Jan-2017 11:51 by jim