!!! Overview
[{$pagename}] 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:
* Be __widely distributed__ amongst several applicaitons and utilize central [Authentication] and [Authorization] methods
* Perform [Federation] with third-party [APIs]
* Expose our [APIs] safely to our Business Partners.
* Manage scalability of our Application Resources
* Meet the current [Cybersecurity] Threats

!! What is done now?
In a typical enterprise environment we would have a pipeline similar to:\\ 
Request --> [API-Gateway] --> Routing --> Application Logic --> [Data Store|DataStore]

Often, the Application Logic or even the [Data Store|DataStore], determines the [Authorization] for the Application or [API]. The problem with this is we have a [dependency] in our [Application] (and/or [Data Store|DataStore]) 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 
* Expose our [APIs] safely to our [Business Partners|B2B] 
* Manage scalability of our Application [Resources]
* Reduce (or eliminate) [dependencies|Dependency] on our [Application]

Let us break down the problem and look at what is needed to determine [Authorization].
 
! For [Access Control] the [API] needs to know?
* Who is the [Authenticated] user)? - provided by ([subject|sub])
** [OAuth 2.0] does __not know__ - [OAuth 2.0 NOT an Authentication protocol]. (delegates [Authentication] to another Service).
* Which Application? ([Mobile Device] or [J2EE] or hopefully identified by [client_id])
* What operations is [Authorized|Authorization] to be performed? (provided by [OAuth Scopes])
 
! In [OAuth 2.0]/[OpenID Connect]
* [subject|sub] - who or [Identity Token]
* [auth_time] - When
* [acr] - [Authentication Method] ([Authentication Context Class Reference]) the user logged in (values from [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])
* [subject|sub] - is an Identifier from Issuer for the [Authenticated] [Entity], which is intended to be consumed by the [OAuth Client], (comes from [JWT] values in [OpenID Connect])
* [aud] - identifies the recipients that the [Identity Token] is intended for and each [Entity] intended to process the [JWT] [MUST] identify itself with a value in the [audience|aud] claim. (comes from [JWT] values in [OpenID Connect])
* [scope|OAuth Scopes] - informs us what the the extent of access.
* [auth_time]- informs us when the [Subject|sub] (User) performed the [Authentication] (comes from [JWT] values in [OpenID Connect])
* [acr] - [Authentication Method] the user logged in (values from [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|sub] 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]:
* [OAuth Client] (ArticleReader) is always granted - read_regular [OAuth Scope] only - for any successful [Authentication]
* [Subject|sub] (user) when using acr=[social Login] is granted - read_regular scope also.
* When the access is for read_premium and the acr=[social Login], the [Authorization Server] looks for a associated "[social Login]" User in customer [Data Store|DataStore] to determine if the user is also a Customer.
** If the user is also a customer, then the read_premium [OAuth Scope] is returned within the [Identity Token]. (Even though it was not requested but as permitted by the specifications. Known as a [Implicit Scopes])
 
In this scenario, then we end up with these scopes within the [Identity Token]
* read_regular - from client (ArticleReader) AND read_regular - any [social Login]
* read_premium - from [Authorization Server] looking up [Resource Owner] (user) = customer associated with [social Login]ID 
 
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:
* [Access Token] exist? (If not send them to get an access_token)
* [Access Token] valid? (Refused if not valid)
* Obtain and validate [Identity Token] (If invalid, refuse request)
* [Identity Token] contains one or more of the following scopes: (if NONE of them exist, we refuse the request)
** read_regular
** read_premium
** read_write
* Abstracts the [Authentication] of the user from the [Application] and reduces to [OAuth Scopes]
! --> Routing
Routing, depending on the Architecture could be done with [NGINX] 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|Auditing]


! --> [Data Store|DataStore]
By the time we get to the [Data Store|DataStore], there should be little to no need for [Authentication]/[Authorization] logic embedded within the [Data Store|DataStore], 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:
[{ReferringPagesPlugin before='*' after='\n' }]