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:
- 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
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
- Expose our APIs safely to our Business Partners
- Manage scalability of our Application Resources
- Reduce (or eliminate) dependencies 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)
- Which Application? (Mobile Device or J2EE or hopefully identified by client_id)
- What operations is Authorized to be performed? (provided by OAuth Scopes)
- subject - who or Identity Token
- auth_time - When
- acr - Authentication Method (Authentication Context Class Reference) the user logged in (values from OpenID Connect)
OAuth 2.0 + Authentication gives us the tools we need. (ie OpenID Connect)#
- subject - 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 claim. (comes from JWT values in OpenID Connect)
- scope - informs us what the the extent of access.
- auth_time- informs us when the Subject (User) performed the Authentication (comes from JWT values in OpenID Connect)
- acr - Authentication Method the user logged in (values from OpenID Connect)
- read_regular - for any successful Authentication
- read_premium - for any Customer
- read_write - for only employees
- OAuth Client (ArticleReader) is always granted - read_regular OAuth Scope only - for any successful Authentication
- Subject (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 to determine if the user is also a Customer.
- 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 LoginID
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)
- 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:
--> 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.
--> 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.