h2. Authorization

"Best Practices for Authorization":http://www.owasp.org/index.php/Guide_to_Authorization
# auth system should deny by default
# Principle of least privilege (fine-grain)
# each non-anonymous entry point have an access control check
# authorization check at or near the beginning of code implementing sensitive activities
# Ensure that Model code checks to ensure that the requesting user should have access to the protected resource.
# Reauthorization for high value activities or after idle out
# 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.
# 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.

h2. Authorization in a trust context

* [http://en.wikipedia.org/wiki/Authorization]
* remember: goal is **prediction** not **control**

h2. 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.

h2. Notes from "Security patterns":http://www.amazon.com/Security-Patterns-Integrating-Engineering-Software/dp/0470858842
by M Schumacher ("website for book":http://www.securitypatterns.org/)

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.

h2. 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.


h2. Notes from "Core Security Patterns":http://www.coresecuritypatterns.com/patterns.htm website

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

h2. notes from "XACML":http://www.nsitonline.in/hemant/stuff/xacml/XACML%20Tutorial%20with%20a%20Use%20Case%20Scenario%20for%20Academic%20Institutions.htm

PolicySets [Policy Combining Algorithm]
Policy [Rule Combining Algorithm] (defines access to particular resources.)
# Target
## Subject Attributes
## Resource Attributes
## Action Attributes
## Environment Attributes
# Rule [Effect]		Identify various conditions or cases under which a policy may become applicable
## Subject Attributes	user who has made an access request
## Resource Attributes	object to which access is requested
## Action Attributes	action the subject wants to take on the resource
## Environment Attributes	request environment (time of day, ip, etc)
## Conditions
# 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

#
# ask for permissions on arbitrary (subject, action, resource)
  * roles
# get filtered object based on action (:public_info, :admin_info, etc.)
# 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)

