The Return of Authorization

Authorization is one of the key concepts and processes involved in security, both in the real world as well as the digital world.  Many formulations of the definition for authorization exist, and some are context dependent.  For IT security purposes, we’ll say authorization is the act of evaluating whether a person, process, or device is allowed to operate on or possess a specific resource, such as data, a program, a computing device, or a cyberphysical object (e.g., a door, a gate, etc.).

The concept of authorization has evolved considerably over the last two decades.  No longer must users be directly assigned entitlements to particular resources. Security administrators can provision groups of users or select attributes of users (e.g. employee, contractor of XYZ Corp, etc.) as determinants for access.

For some of the most advanced authorization and access control needs, the OASIS eXtensible Access Control Markup Language (XACML) standard can be utilized. Created in the mid-2000s,  XACML is an example of an Attribute-Based Access Control (ABAC) methodology.  XACML is an XML policy language, reference architecture, and request/response protocol. ABAC systems allow administrators to combine specific subject, resource, environmental, and action attributes for access control evaluation.  XACML solutions facilitate run-time processing of dynamic and complex authorization scenarios.  XACML can be somewhat difficult to deploy, given the complexity of some architectural components and the policy language.  Within the last few years, JSON and REST profiles of XACML have been created to make it easier to integrate into modern line-of-business applications.

Just prior to the development of XACML, OASIS debuted Security Assertion Markup Language (SAML).  Numerous profiles of SAML exist, but the most common usage is for identity federation.  SAML assertions serve as proof of authentication at the domain of origin, which can be trusted by other domains.  SAML can also facilitate authorization, in that, other attributes about the subject can be added to the signed assertion. SAML is widely used for federated authentication and limited authorization purposes.

OAuth 2.0 is a lighter weight IETF standard. It takes the access token approach, passing tokens on behalf of authenticated and authorized users, processes, and now even devices.  OAuth 2.0 now serves as a framework upon which additional standard are defined, such as Open ID Connect (OIDC) and User Managed Access (UMA).  OAuth has become a widely used standard across the web.  For example, “social logins”, i.e. using a social network provider for authentication, generally pass OAuth tokens between authorization servers and relying party sites to authorize the subject user.  OAuth is a simpler alternative to XACML and SAML, but also is usually considered less secure.

From an identity management perspective, authentication has received the lion’s share of attention over the last several years.  The reasons for this are two-fold:

However, in 2017 we have noticed an uptick in industry interest in dynamic authorization technologies that can help meet complicated business and regulatory requirements. As authentication technologies improve and become more commonplace, we predict that more organizations with fine-grained access control needs will begin to look at dedicated authorization solutions.  For an in-depth look at dynamic authorization, including guidelines and best practices for the different approaches, see the Advisory Note: Unifying RBAC and ABAC in a Dynamic Authorization Framework.

Organizations that operate in strictly regulated environments find that both MFA / risk adaptive authentication and dynamic authorization are necessary to achieve compliance.  Regulations often mandate 2FA / MFA, e.g. US HSPD-12, NIST 800-63-3, EU PSD2, etc.  Regulations occasionally stipulate certain that access subject or business conditions, expressed as attributes, be met as a precursor to granting permission.  For example, in export regulations these attributes are commonly access subject nationality or licensed company.

Authorization becomes extremely important at the API level.  Consider PSD2: it will require banks and other financial institutions to expose APIs for 3^rd party financial processors to utilize.  These APIs will have tiered and firewalled access into core banking functions.  Banks will of course require authentication from trusted 3^rd party financial processors.  Moreover, banks will no doubt enforce granular authorization on the use of each API call, per API consumer, and per account.  The stakes are high with PSD2, as banks will need to compete more efficiently and protect themselves from a much greater risk of fraud.

For more information on authentication and authorization technologies, as well as guidance on preparing for PSD2, please visit the Focus Areas section of our website.

John Tolbert is senior analyst at KuppingerCole. Read more KuppingerCole blogs here.