Skip to content
This repository

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)
  • Something went wrong with that request. Please try again.