A talk about authorization models for application security given at the Utah Java Users Group (Sep 2015).

1. Application Security
Authorization Models
Adinath Raveendra Raj
UJUG, September 17, 2015
www.acciente.com

2. Overview
● Introduction
● Historical Context
● Different Authorization Models
● Java Security Frameworks

3. CIA Principle
● Confidentiality
– Restricting the disclosure of sensitive information to authorized
persons. Can be seen as privacy.
● Integrity
– Ensuring/detecting that sensitive information is not maliciously altered
or tampered by unauthorized or authorized persons.
● Availability
– Ensuring continued access to information. Redundancy. High
availability.

4. What is an Authorization Model?

5. What is Authorization?

6. Authorization vs. Authentication
● Authentication is about verifying the identity of a user
(more generally called a subject).
● Authorization is about controlling what resources a user
has access to, after successful authentication.
● Authorization is not authentication.

7. What is an Authorization Model?

8. Authorization Model
A model for granting (or denying) users access
to resources.

9. Historical Context
● Background
– Emerged in the 1960s and 1970s in DoD systems
– The focus was on confidentiality
● MAC
– Mandatory Access Control
– Centrally administered, non-discretionary (not DAC)
– Most government systems used MAC
● DAC
– Discretionary Access Control
– Delegated authority to administer (not MAC)
– Unix File System permission

10. Historical Context
●
Background
– Emerging focus on integrity over confidentiality for commercial systems
● ACL
– Access Control List
– Emerged from the need to restrict access at the resource level
● RBAC
– Role-based Access Control
– Defined in 1992 to better address the security needs of commercial organizations
●
ABAC
– Attribute-based Access Control
– Allows incorporating dynamic factors into the access decision, for example, time of day
●
OACC
– Object ACcess Control
– It is the model used by OACC Java Security Framework released in 2014.

11. Access Control List (ACL)
● How does it work?
– A list of user-permission pairs (the ACL) is associated with a resource.
– An entry in the list is sometimes called an ACE (Access Control Entry).
– Each entry in the list is a user and a permission.
– Example: (john-doe, read)
● Some applications
– File system security in Windows NT, Linux, BSD, Solaris, Mac OS X.
– Network configuration in Amazon EC2.
● Comments
– Efficient to check if a user is authorized to a resource.
– Extremely inefficient to determine all resources a given user has access to.
– Difficult to manage complex topologies.

12. Role-based Access Control (RBAC)
● How does it work?
– Each user is assigned one or more roles
– Permissions are assigned to roles instead of directly to user
– Essentially the user inherits the permissions from the assigned roles
● The NIST model for RBAC specifies 4 levels of RBAC capability
– Level 1 - Flat RBAC
– Level 2 - Hierarchical RBAC
– Level 3 - Constrained RBAC
– Level 4 - Symmetric RBAC
●
Widespread poor practice
– Users are assigned to roles, and security is checked by checking for membership in the role
● Comments
– Can be centrally administered or distributed
– Complex topologies are easier to maintain than ACL
– Supports all the capabilities of ACL (J. Barkley, 1997)
– RBAC Level 4 supports "before the fact" audits
– Permissions are static compared to ABAC

13. Attribute-based Access Control
(ABAC)
● How does it work?
– Access is determined by evaluating a policy on attributes
associated with the user, target object and possibly the
environment
● Comments
– Access decision can take into dynamic variables such as time of
day
– Difficult to audit, very difficult to determine what users have access
to a resource
– Evaluating an access request can be potentially very performance
intensive (to collect the attributes needed for the decision)

14. Object Access Control (OACC)
● How does it work?
– Both users and secured entities are resources
– A resource is of a resource type and is contained within a domain
– A resource may have permissions on domains and resources
– A resource can inherit permissions from one or more resources
● This is the security model used by the open-source OACC Java Security
Framework released in 2014.
● Comments
– Designed to support multi-tenant systems
– Can be centrally administered or distributed
– Supports of RBAC Level 1, 2 and 4
– Supports ACL and ACLg

15. Java Security Frameworks
MAC DAC ACL ACLg RBAC RBAC level
Apache Shiro Yes No Yes Yes No --
OACC Yes Yes Yes Yes Yes Level 1, 2 and 4
Spring Security Yes No Yes Yes No --