Centralized Authorization Service (CAuthS) or Authorization as a Service (AuthaaS)—A Conceptual Architecture

Absence of architecture to describe how to implement authorization as a centralized service, in a way similar to authentication, has been causing redundant deployment of computing resources, lack of standard practices, and neverending learning curve in maintaining proprietary or ad hoc authorization solutions. The paper develops an architecture, which focuses on centralization of authorization, to be called Centralized Authorization Service (CAuthS) or Authorization as a Service (AuthaaS), when deployed as a service, and is targeted to substitute platform-based ad hoc authorization solutions. General Terms XACML: eXtensible Access Control Markup Language is a standard maintained by OASIS [1]. ACL, RBAC, and ABAC: Access Control List, Role-Based Access Control, and Attribute-Based Access Control are commonly known patterns in the domain of authorization ( [2]; [3]; [4]]). User Access Control (UAC): An enterprise or federationscoped authorization (access control) service discussed in the paper. In addition to access control, validation of action by the principal (user) is included in the meaning of authorization. UUID: Universally Unique Identifier is defined by the Open Software Foundation [5]. It should guarantee uniqueness of principal within an enterprise-scoped or a federation-scoped UAC service. Identification, Identification Provider (IdP): Identification a.k.a., authentication, validates credentials of principals and returns results as Boolean responses. Issuing secured tokens is often included in the task-list of the IdP [6]; however, the latter responsibility may be gainfully shared by the SP particularly if per-transaction tokens are warranted for security reasons. Core Concern, Crosscutting Concern: Core business gives rise to logic known as the core concern; other, supportive Authorization has been defined differently by many ([20]; [21]; [22]; etc.). In this paper, it is, primarily, granting access to a principal over a view of a UAC resource. However, it may also include validation of user actions. 2 Similar to authorization, authentication (for the purpose of this paper it is same as or close to assertion of identity) has many definitions ([23]; [24]; etc.) Here, the term means asserting identity of a principal. Single Sign-On (SSO), Cross-Domain SSO, and Federated SSO ([25]; [26]; [27]; [28]; [24]) have contributed to centralization of this service. 3 Vide DUKPT [29], which is a way to address vulnerability of sessions that use a single token for all transactions associated with it. logic are known as crosscutting concern [7]. However, the paper will take a relative view on this: if individual concerns in the set C = c1 , c2,... containing all of them are implemented separately then it will be assumed that the relation, crosscutting Χ into C will be deemed reflexive, i.e. ciΧcj ⇔ cjΧci∀ci , cj ∈ C, ci ≠ cj . It practically means that authorization being a crosscutting concern for some business service also means and is meant by the business service (or a part of it) acting as crosscutting concern for authorization. Service Provider (SP): UAC resources are controlled by the Service Provider (SP), which provides access to identified principals, subject to nature and extent determined by the UAC. Principal: Entity seeking access over UAC resources. Also vide infra. Subject: Entity allowed access over UAC resources. Also vide infra.