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)