1 / 33

An Algorithmic Approach to Authorization Rules Conflict Resolution in Software Security

An Algorithmic Approach to Authorization Rules Conflict Resolution in Software Security. Weider D. Yu Ellora Nayak San Jose State University San Jose (Silicon Valley), California, USA. Topics. Purpose Security in Web Services Web Service Authorization Requirements

tab
Download Presentation

An Algorithmic Approach to Authorization Rules Conflict Resolution in Software Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An Algorithmic Approach to Authorization Rules Conflict Resolution in Software Security Weider D. Yu Ellora Nayak San Jose State University San Jose (Silicon Valley), California, USA

  2. Topics • Purpose • Security in Web Services • Web Service Authorization Requirements • Authorization Framework using ARSL • Usage Scenario • Evaluation • Conflict Resolution • Future Scope and Conclusion TRUST Autumn 2008 Conference, Nashville, Tennessee

  3. Purpose • To propose a framework for implementing authorization in Web Services. • To provide a generalized and reusable approach that provides the flexibility to manage fast authorization rule updates. TRUST Autumn 2008 Conference, Nashville, Tennessee

  4. Need for Web Service Security • An unauthenticated person may try to access services. • An authenticated but unauthorized person may access services. • Messages might be modified by hackers. • Non-repudiation issue. TRUST Autumn 2008 Conference, Nashville, Tennessee

  5. Current Authorization Implementation I need a new service to graph the growth of my stock. Web Service User Requests for a new web service Discuss about users needs This is possible by developing a new module accessing customer database. Business Provider (e.g. IT dept of Bank ) Decide on security features Get the requirements Only authorized personnel should access the service. Customer can authorize over phone to access their data. Security Architect Security requirements passed to developer What is a funds growth graph? Can I switch off the access flag to prevent unauthorized access? Independent Software Vendor Validates application against user requirements Testing & QA TRUST Autumn 2008 Conference, Nashville, Tennessee

  6. Problems • Different perspectives of the stakeholders. • Different requirement, specializations and backgrounds of the stakeholders. • Insufficient understanding of individual domains. • Significant amount of time and effort required. TRUST Autumn 2008 Conference, Nashville, Tennessee

  7. Requirements of an Authorization Framework • Isolation of authorization module from the rest of the Web Service application. • Automated authorization code generation and integration. • Simple and powerful authorization and access control language for security administrators. TRUST Autumn 2008 Conference, Nashville, Tennessee

  8. Proposed Framework • The framework is composed of: • An authorization specification language (ARSL) used to specify authorization and access control policies. • A compiler used to automatically generate authorization modules in High-Level Language (HLL) from the above policies. • Dynamic Link Library (DLL) modules compiled from the HLL code and linked with existing Web Service. • The authorization layer is separated from the Web Service application. • Authorization and access control rules can be changed without affecting other Web Service application code. TRUST Autumn 2008 Conference, Nashville, Tennessee

  9. DB Testwithsampleinput stop Input file (in ARSL) (BankInput.txt) Security Admin adds/ corrects rules Updated rule file Compiler (ars.exe) ARSL Tool Error Generates code GeneratedFile.cs Insert Generated Code into Authorize.cs Other Authorization independent code DB Access code Generated Code Compile with HLL compiler (csc.exe) Error AuthLib.dll BankWService Authorization Enabled Web Service Module Error passed TRUST Autumn 2008 Conference, Nashville, Tennessee

  10. Compiler (forall x) [ LocSecure(x) AND Role_HRM(x) =>Access(EmployeeDetails) ] Authorization Rules Generates Code bool AccessEmployeeDetails( int userid ) { return ( (LocSecure(userid) ) && (userid.Role == “HRM”) ); } Authorization Module Authorization Module DLL AuthLib.dll linked Existing Web Service modules Database Web Service with Authorization TRUST Autumn 2008 Conference, Nashville, Tennessee

  11. Authorization Rule Specification Language (ARSL) • ARSL is a special high-level specification language to specify authorization rules. • Based on mathematical predicate logic: • It is a knowledge representation type of language. • The language syntax is suitable for stating facts and deriving additional facts. TRUST Autumn 2008 Conference, Nashville, Tennessee

  12. Language Syntax • Authorization Rule: quantifier [(function_1) op (function_2) …op (function_N) => Access (service)] Left hand side terms of the rule are used to specify conditions that must be verified for the authorization to hold. • Example: “All employees who are not teller have access to the service to open account.” (forall x)[ NOT Role_TELLER( x) =>Access(OPEN_ACT)]; where: Role_TELLER()  macro OPEN_ACT  service name TRUST Autumn 2008 Conference, Nashville, Tennessee

  13. Design Requirements • Provide a way to specify string, Boolean, numeric constants, and variables. • Provide a way to define individual components that combine to give rules. • Facilitate combining individual clauses (or macros) to derive authorization rules. • Provide basic logical and arithmetic operators. • Be complete enough to express any authorization rules. TRUST Autumn 2008 Conference, Nashville, Tennessee

  14. Language Constructs • Constants: Boolean constants (true and false), string constants (set of characters within quotes), numeric constants. • Operators: Arithmetic operators, logical operators, assignment operators, string operators are implemented. Example: AND, OR, NOT, =, ==, +, - , *, /, >, <, >=, <=. • Quantifiers: forall • Delimiter: Semicolon is used to terminate rules Example: (forall x) [CurrentTime(x) > 900 AND CurrentTime (x) < 1700 => Access(BankServices)]; TRUST Autumn 2008 Conference, Nashville, Tennessee

  15. Language Constructs (cont.) Predicate: • A unary predicate, Access, which takes as argument the service name: Access (ServiceName). • During code generation, calls to Access(ServiceName) is translated to the function call ‘AccessServiceName (UserId)’. TRUST Autumn 2008 Conference, Nashville, Tennessee

  16. Language Constructs (cont.) • Macros: • Subroutines for an access rule. • Defined in terms of user data, such as his/her location, role etc. • Evaluated in isolation and do not specify an access rule. • Example: [Location(x) ==”Sunnyvale” OR Location(x) ==”San Jose” => LocationSecure(x)]; where LocationSecure is a macro. TRUST Autumn 2008 Conference, Nashville, Tennessee

  17. Grammar Rules • <start>  <macros> BEGIN <rules> END • <rules>  <rules> <access_rule> • <access_rule>  <quantifier> [<predicate> IMPLIES <access_expr>]; • <predicate>  <macro> | <access_expr> • <quantifier>  forall | exists • <access_expr>  ACCESS (VAR) | DENY (VAR) | <access_expr> <op> <access_expr> TRUST Autumn 2008 Conference, Nashville, Tennessee

  18. Grammar Rules (cont.) • <macros>  <macros> <macro> • <macro>  <context_expr> <cmp_op> CONST IMPLIES MACRO_NAME (VAR) • <context_expr>  <CONTEXT_VAR> (VAR) | <context_expr> <op> <context_expr> • <cmp_op>  EQUALS | NE| GT| GE| LT| LE • <op>  AND | OR TRUST Autumn 2008 Conference, Nashville, Tennessee

  19. Advantages of using ARSL • Easy to express - Simple and easy to use constructs to express authorizations rules. • Scalability - Easy to adapt to the growth of authorization rules due to organizational or environmental changes. • Manageability – Modification is applied to all Web Services. • Reusability – Code can be easily understood and modified for reuse. TRUST Autumn 2008 Conference, Nashville, Tennessee

  20. Scenario-1 • Tellers do not have the access rights to open new accounts. • Rule (forall x) [Role_PBK (x) OR Role_CSR(x) OR NOT Role_TLR(x) => Access (OPEN_ACT)]; • Code generated for the above rule is: bool AccessOPEN_ACT( int userid ) { return ((Role_PBK (userid)|| Role_CSR (userid) || ! Role_TLR (userid)); } TRUST Autumn 2008 Conference, Nashville, Tennessee

  21. Scenario-2 • Branch Manager and Accountant have access to banking service after office hours, others can only access the service during office hours. • Rule: (forall x) [(Role_BRM(x) OR Role_ACC(x)) AND NOT Office_Hours(x)) => Access(ACCESS_TIME)]; • Code generated for the above rule is: bool AccessACCESS_TIME( int userid ) { return ((Role_BRM (userid)|| Role_ACC (userid)) && ! Office_Hours(userid) ); } TRUST Autumn 2008 Conference, Nashville, Tennessee

  22. Scenario-3 • Only Teller’s supervisors or managers can modify an existing transaction. • Rule: (forall x) [((Role_LTR(x) OR Role_SVM(x) OR Role_BRM(x)) AND NOT Role_TLR(x))=> Access (MODIFY_TRX)]; • Code generated for the above rule is: bool AccessMODIFY_TRX ( int userid ) { return ((Role_LTR (userid)|| Role_SVM (userid)|| Role_BRM (userid)) && (! Role_TLR (userid))); } TRUST Autumn 2008 Conference, Nashville, Tennessee

  23. Evaluation No. of rules in an input file vs. code generation time TRUST Autumn 2008 Conference, Nashville, Tennessee

  24. No. of functions in each rule vs. code generation time With increase in the number of functions in a single rule, the time taken to generate HLL increases proportionally. TRUST Autumn 2008 Conference, Nashville, Tennessee

  25. No. of predicates per rule vs. execution time for authorization function calls TRUST Autumn 2008 Conference, Nashville, Tennessee

  26. Conflict Resolution • Conflict resolution on authorization rules is achieved by conflict prevention and detection. Conflict Detection: • User (Security Admin) can use the “–D” compiler option to generate code for conflict detection. • On detecting a conflict, user can manually correct the conflicting rules. • All Access and Deny rules are evaluated to a decision to allow or deny the access of a resource. TRUST Autumn 2008 Conference, Nashville, Tennessee

  27. Conflict Prevention • It is the default option used in the ARSL compiler. • Based on the priority of input authorization rules for a given resource: • If there exists more than one rule for a given resource, the order of rule occurrences is used as the order of priority. • All resources must have a default rule at the end of input file. • ARSL uses an algorithm to prevent conflicts. TRUST Autumn 2008 Conference, Nashville, Tennessee

  28. Inputs: A set of authorization rules given in a priority order. Output: A single authorization rule resolving conflicts based on the priority. Current_Predicate = Predicate of Rule n Current_Action = Action of Rule n FOR i = n-1 to 1 DO BEGIN IF Action of Rule I == Current_Action THEN Current_Predicate = (Predicate of Rule i) OR (Current_Predicate) ELSE Current_Predicate = NOT (Predicate of Rule i) AND (Current_Predicate) ENDIF /* Convert deny rules to access rules */ IF (Current_Action == ”Deny”) THEN Current_Predicate = NOT (Current_ Predicate) Current_Action = “Access” ENDIF END ENDFOR Algorithm Used for Conflict Prevention TRUST Autumn 2008 Conference, Nashville, Tennessee

  29. Conflict Resolution Example Input Authorization Rules: Rule 1: (forall x) [CreditCard(x)=="INVALID" => Deny(Item)]; Rule 2: (forall x) [Prescription(x) == "Item" => Access(Item)]; Rule 3: (forall x) [Country(x) =="USA" AND Age < 19 AND Item == "Liquor" => Deny(Item)]; Rule 4: (forall x) [Country(x) =="GERMANY" AND Age < 21 AND Item == "Liquor" => Deny(Item)]; Rule 5: (forall x)[TRUE => Access(Item) ];//default rule TRUST Autumn 2008 Conference, Nashville, Tennessee

  30. Using the prevention algorithm, the resultant authorization rule is: i=4: NOT (Country(x) ==”Germany” AND Age(x) < 21 AND Item(x) == “Liquor”) AND True) => Access(Item) i=3: NOT (Country(x) ==”USA” AND Age(x) < 18 AND Item(x) == “Liquor”) AND (NOT ( Country(x) ==”Germany” AND Age(x) < 21 AND Item(x) == “Liquor” ) AND True ))=> Access(Item) i=2: ( Prescription(x) == “Item” ) OR (NOT (Country(x) ==”USA” AND Age(x) < 18 AND Item(x) == “Liquor”) AND (NOT ( Country(x) ==”Germany” AND Age(x) < 21 AND Item(x) == “Liquor” ) AND True )))=> Access(Item) i=1: NOT (CreditCard(x) == “INVALID”) AND (( Prescription(x) == “Item” ) OR (NOT (Country(x) ==”USA” AND Age(x) < 18 AND Item(x) == “Liquor”) AND (NOT ( Country(x) ==”Germany” AND Age(x) < 21 AND Item(x) == “Liquor” ) AND True) )))=> Access(Item) TRUST Autumn 2008 Conference, Nashville, Tennessee

  31. Features of the Algorithm • Output is a single logical expression. • Authorization function call returns as soon as one of the rules is true. • Execution time is less. TRUST Autumn 2008 Conference, Nashville, Tennessee

  32. Future Work and Conclusion • Port the compiler to generate more HLL code other than C#. • Provide options to dynamically select language and platform options. • Decoupling security policies from Web Service specific functionality helps in improving Web Service security. • The framework helps in dynamic authorization rule updates. • The proposed framework together with the specification language, ARSL, provides an effective solution for authorization implementation. TRUST Autumn 2008 Conference, Nashville, Tennessee

  33. Thank You TRUST Autumn 2008 Conference, Nashville, Tennessee

More Related