Authorization

Authorization

Best Practices for Authorization

1. auth system should deny by default
2. Principle of least privilege (fine-grain)
3. each non-anonymous entry point have an access control check
4. authorization check at or near the beginning of code implementing sensitive activities
5. Ensure that Model code checks to ensure that the requesting user should have access to the protected resource.
6. Reauthorization for high value activities or after idle out
7. If custom code is required to perform authorization functions, consider
   fail-safe authentication and exception handling – ensure that if an exception
   is thrown, the user is logged out or at least prevented from accessing the
   protected resource or function.
8. Well written applications centralize access control routines, so if any bugs
   are found, they can be fixed once and the results apply throughout the
   application immediately.

Authorization in a trust context

• remember: goal is prediction not control

Patterns for Policy definition / Authorization / access control

*Reference Monitor (SecPatt p256)

• Set of authorization rules
• Actor, Action, Resource => Monitor+(rules) => ctrlr

Role based:
subj, role, right. action, resource
RBAC, access is controlled at the system level, outside of the user’s control

Filter based
User x Controller x Action x Params —

Object based
model security delegation

Access Control Matrix http://en.wikipedia.org/wiki/Access_Control_Matrix

CommandProcessor pattern (DSL approach)

DENY FROM … / ALLOW FROM … approach

Capability based control: bundle together the designation of an object and the permission to access that object
ie. I can name it if and only if I am allowed to get at it.

Notes from Security patterns
by M Schumacher (website for book)

Reference Monitor (SecPatt p256)

• Set of authorization rules
• Actor, Action, Resource => Monitor+(rules) => ctrlr

= Full access with Errors (SecPatt p305)

• Users should not be able to view data or perform operations for which they
  have no permissions.
• Hiding an available and accessible function is inappropriate, because users
  must be able to see what they can do.
• The visual appeal and usability of a graphical user interface (GUI) can be de-
  graded by varying layouts depending on the (current) access rights of a
  user. For example, blank space might appear for some users where others see
  options they can access, or sequence and number of menu items might differ,
  depending on the current user’s rights, and thus ‘blind’ operation of the menu
  by an expe- rienced user is no longer possible.
• Showing currently unavailable functions can tease users to into upgrading
  their access rights, for example by paying for the access or buying a license
  after us- ing a demo version.
• Trial and error are ineffective means of learning which functions are
  accessible. Invoking an operation only to learn that it doesn’t work with
  your access rights is confusing.
• The privilege grouping of the typical user community might not be known at the
  design time of the GUI, and it might change over time, for example through
  organizational or business process changes, so that providing a few special
  modes of the GUI depending on the corresponding user roles is inappropriate.
• Checking whether a function is allowed by a user is most efficient, robust and
  secure, if done by the function itself—at least the code performing the checks
  is then closely related to the code performing the subsequent operation
  afterwards.

Outcomes / Obligations

- forbid
- ask for trust escalation (eg log in, prove_as_human, validate_email, are_you_sure, send_me_ten_cents)
- drag ass
- permit

- reinterpret past actions based on future evolution of trust
- prioritize changesets based on trust.

Notes from Core Security Patterns website

1. Authentication Enforcer who the hell are you
2. Intercepting Validator Is your request well-formed
3. Authorization Enforcer Are you allowed to do that
4. Secure Logger Know what’s happening/happened
   #

notes from XACML

PolicySets [Policy Combining Algorithm]
Policy [Rule Combining Algorithm] (defines access to particular resources.)

1. Target
   1. Subject Attributes
   2. Resource Attributes
   3. Action Attributes
   4. Environment Attributes
2. Rule [Effect] Identify various conditions or cases under which a policy may become applicable
   1. Subject Attributes user who has made an access request
   2. Resource Attributes object to which access is requested
   3. Action Attributes action the subject wants to take on the resource
   4. Environment Attributes request environment (time of day, ip, etc)
   5. Conditions
3. Obligations

Roles — student, janitor, dean, stranger, …
Branches — Departments, etc.

• Examine applicable rules until you get an outcome, failure or passes thru (in which case rejected)
• Rule combining Algorithms

• Obligations — things to do once requests have been denied or permitted

Reference Monitor (SecPatt p256)

• Set of authorization rules
• Actor, Action, Resource —> Monitor+(rules) —> ctrlr

#

1. ask for permissions on arbitrary (subject, action, resource)
2. roles
3. get filtered object based on action (:public_info, :admin_info, etc.)
4. attach a rule to a (subject|role, action, resource) triple
   “subject should have role R”
   “subject should have role R on resource X”
   "should meet the

• Role supervisor:
• adds, defines, removes roles. no policy — just attaches roles to users

• Policy
  answers “can Actor do Action to Resource”
• Rules
• Rule resolution
• outcome, obligations.
  policy definitions can come from many places, go to policy mgr.
• Hall monitor
  enforces policy (before filters)
• Policy observers
  handle policy obligations

• Athentication — identification, really: securely attach visitor to identity
• Validation — qualify trust
• Access control — define policy
  • Roles
  • Acc. matrix
• Authorization — enforce policy (reference monitor ; filter chain)
• Obligations
  • Audit — (observer)

Notes from SAML

• Divided into providers and consumers of information
• Authorization works by request messages and decision responses
• Roles are Policy Decision Points (PDP) and Policy Enforcement Points (PEP)