1 / 22

EN gine FOR C ontrolling E mergent H ierarchical R ole- B ased A ccess (ENforCE HRBAccess)

EN gine FOR C ontrolling E mergent H ierarchical R ole- B ased A ccess (ENforCE HRBAccess). Osama Khaleel Thesis Defense May 2007 Master of Science in Computer Science University of Colorado, Colorado Springs.

carlaf
Download Presentation

EN gine FOR C ontrolling E mergent H ierarchical R ole- B ased A ccess (ENforCE HRBAccess)

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. ENgineFORControllingEmergent HierarchicalRole-BasedAccess(ENforCE HRBAccess) Osama Khaleel Thesis Defense May 2007 Master of Science in Computer Science University of Colorado, Colorado Springs okhaleel/Enforce

  2. ENgineFORControllingEmergent HierarchicalRole-BasedAccess(ENforCE HRBAccess) Committee Members: Dr. Edward Chow, Chair Dr. Terry Boult Dr. Xiaobo Zhou okhaleel/Enforce

  3. Thesis Defense Outlines • Intro & Background • Design • Implementation • Performance Analysis • Future Work • Contribution • Demo • Q & A okhaleel/Enforce

  4. Introduction • Roles in any organization are Hierarchical by their nature. • Resources in any organization vary: • From a simple HTML web page, • To RDP/SSH access in which a user can gain full control. • Mission becomes more complicated when users should access resources: • Securely • And based on their ROLES. • Password-based protection is way far from satisfying high-level security requirements. okhaleel/Enforce

  5. Background Public Key Infrastructure (PKI) • Authentication • Public Key Certificate (PKC) • Certificate Authority (CA) • Certificate Revocation List (CRL) • Authorization • Attribute Certificate (AC) • Attribute Authority (AA) • Role-Based Access Control (RBAC) • Core • Hierarchical • eXtensible Access Control Markup Language (XACML) • Policy Enforcement Point (PEP) • Policy Decision Point (PDP) • Active Directory (AD) • ISAPI Filter • ASP.NET Application File (Global.asax) • Iptables Privilege Management Infrastructure (PMI) okhaleel/Enforce

  6. Authentication: the process in which someone provides some kind of credentials to prove his or her identity. • CA: a trusted third party that issues digital certificates to be used by other parties. It guarantees that the individual granted the certificate is really who claims to be. • PKC: a digitally signed document that binds a public key to a subject (identity). This binding is asserted by a trusted CA. • CRL: a list signed by the issuing CA that contains the serial numbers of the revoked certificates. • Authorization: the process that is used to determine whether the subject has the required permissions to access some protected resources. • AC: a digitally signed document that binds a set of attributes like membership, role, or security clearance to the AC holder. • AA: a trusted third party that is responsible for issuing, maintaining, and revoking ACs. okhaleel/Enforce

  7. AD: a distributed directory service included in the Windows server 2000/2003 • The Microsoft's implementation of LDAP • Used to store and manage all information about network resources across the domain: computers, groups, users, … • ISAPI filters: DLLs that can be used to enhance and modify the functionality of IIS. • Powerful -> they can modify both incoming and outgoing DataStream for EVERY request. • Global.asax: a file resides in the root directory of the ASP.NET application. • Contains code to handle application-level and session-level events raised by ASP.NET. • Iptables: a generic table structure for defining a set of rules to deal with network packets. • Rules are grouped into chains. • Chains are grouped into tables • Each table is associated with a different kind of packet processing. okhaleel/Enforce

  8. RBAC: a mechanism/model for restricting access based on the role of authorized users. • Core: roles are assigned to users, and permissions are associated with roles – not directly with users. • Hierarchical: an enhancement to the core, in which senior roles inherit permissions from more junior roles. • XACML: an XML-based OASIS standard that describes: • A policy language • A request/response language • The main three components in XACML are Rule, Policy, and PolicySet • XACML RBAC profile has two main components: • Permission PolicySet (PPS) • Role PolicySet (RPS). • One PPS and one RPS for each defined Role . okhaleel/Enforce

  9. RPS: • defines the Role name • includes ONLY one PPS to associate this Role with its permissions defined in the corresponding PPS. • PPS: • defines Policies and Rules needed to the Permissions associated with a certain Role. • Contains a set of PPS references using "<PolicySetIdReference>" to inherit permissions from a junior role associated with this PPS reference • Define What is a Junior role. Before using it. <PolicySet PolicySetId="CFOPermissions"> <Policy PolicyId="PolicyForCFORole"> <Rule RuleId="FinanceManagementRule" Effect="Permit"> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <Resource> <ResourceMatch MatchId="function: regexp-string-match"> <AttributeValue DataType=“string"> https://ncdcrx3.uccs.edu/financial/finMgmt.aspx </AttributeValue> </ResourceMatch> </Resource> </Resources> </Target> </Rule> </Policy> <PolicySetIdReference>SalesMgrPermissions</PolicySetIdReference> <PolicySetIdReference>AccMgrPermissions</PolicySetIdReference> </PolicySet> <PolicySet PolicySetId="RPS:CFO"> <Target> <Subjects> <Subject> <SubjectMatch MatchId="function: string-equal"> <SubjectAttributeDesignator DataType="string" AttributeId="role"/> <AttributeValue DataType="string"> CFO </AttributeValue> </SubjectMatch> </Subject> </Subjects> </Target> <PolicySetIdReference>CFOPermissions</PolicySetIdReference> </PolicySet> okhaleel/Enforce

  10. Design • By taking advantage of the concepts & technologies just mentioned, the goal is to build a structure/engine that provides: • Authentication • Authorization • Secure access based on users ROLES • Protection for ANY type of resources • Fine grained control based on active sessions • PKI & PMI management tool okhaleel/Enforce

  11. Protected web resources User Request IIS Authentication ISAPI Http request Http request XML response RPS XML response Policy Decision Point Policy Enforcement Point Get Decision XACML POLICY Check session policy Session policy source PPS Open/Close commands Get User's AC FC4 machine (Firewall) Iptables Control Service Domain Controller Active Directory Protected Network resources ASP.NET Application Global.asax Network- resource Access ENforCE “Big Picture” okhaleel/Enforce

  12. 128.198.162.53 128.198.162.52 128.198.162.51 128.198.162.50 FedoraCore4 Gateway/Firewall Main switch 10.0.0.1 Local switch 10.0.0.11 10.0.0.13 10.0.0.12 10.0.0.10 Win2003 IIS Windows XP Win2003 DC ENforCE Test-Bed okhaleel/Enforce

  13. Implementation: • Two types of access: • Web-based resources (http://ncdcrx3.uccs.edu) • Network-based resources (http://ncdcrx4.uccs.edu) • Web resources: accessed directly through IIS using https (port 443) • Network resources: • Activate a web-session first • ENforCE will open the firewall for the specified service • Physically access the service through the firewall. • Service port varies (e.g. SSH:22, RDP:3389) • ISAPI Filter  web-access entry point (C/C++ - MFC) • Global.asax  Manage web sessions (C#/ASP.NET) • Policy Engine  PEP, PDP, Policy, RBAC (XACML - Java) • Firewall Daemon  Update Iptables Rules (Java - JSSE) okhaleel/Enforce

  14. 1) Web request IIS IIS Authentication Policy Enforcement Point 2) Http request with attributes ISAPI 5) XML response with decision 6) Permit/Deny access 4) Get Decision 3) Get User's AC Protected web resources Policy Decision Point Domain Controller Active Directory Web resources (ISAPI) okhaleel/Enforce

  15. IIS 1) Request a session ASP.NET Application Global.asax IIS Authentication 2) Http request with attributes 7) XML response with decision 8) Physically access the services FC4 machine (Firewall) Policy Enforcement Point 6) Open/Close commands Iptables Control Daemon 3) Get User's AC 5) Check session policy 4) Get decision Protected Network resources PDP Session policy source DC AD Network resources (Global.asax) okhaleel/Enforce

  16. Requests to PEP • From ISAPI (Access a web resource): http://localhost:8080/sispep/servlets/sispep ? • subject= CN=Edward Chow, C=US, S=CO, ...., E=chow@sis.uccs.edu, OU=Computer Science & • URL=https://ncdcrx3.uccs.edu/it/img.jpg & • method=GET & • service=web • From Global.asax (Open a network resource): http://localhost:8080/sispep/servlets/sispep ? • subject= CN=Edward Chow, C=US, S=CO, …., E=chow@sis.uccs.edu, OU=Computer Science & • URL=https://ncdcrx4.uccs.edu/ssh/session.aspx & • service=ssh & • IP=128.198.55.11 & • sessionID=23hjhY43& • action=open • From Global.asax (Close a network resource): http://localhost:8080/sispep/servlets/sispep ? • subject= CN=Edward Chow, C=US, S=CO, …., E=chow@sis.uccs.edu, OU=Computer Science & • URL=https://ncdcrx4.uccs.edu/ssh/session.aspx & • service=ssh & • IP=128.198.55.11 & • sessionID=23hjf73G2& • action=close okhaleel/Enforce

  17. Conditional Active-Session Access (CASA) • Idea : Junior role can ONLY access a network resource IF its Senior role has an active session for that resource. • Why? To add finer access control • How? PEP maintains a table. An entry looks like: <Service name “SSH”> <Senior>ProjectMngr </Senior> <Junior>Developer </Junior> </Service> • PEP reads an XML policy file (session policy). • The session policy file supports 3 cases: • 1) A CERTAIN Senior Role is required • 2) ANY Senior Role is required • (including itself?) • 3) N-Senior Roles are required <Service name=“ MySQL”> <Senior>ANY</Senior> <Junior>Accountant </Junior> </Service> <Service name=“SSH”> <Senior>ITManager </Senior> <Junior>DB Admin </Junior> </Service> <Service name=“SSH”> <Senior>CEO </Senior> <Junior>DB Admin </Junior> </Service> okhaleel/Enforce

  18. CASA (cont’d) 1) Hierarchical-Role tree To answer: Is Role A senior to Role B ? 2) Session Policy Table To decide:For the requested service,Is Junior’s access constrained by Senior’s ? • PEP reads the session policy file and creates two things: Senior : Junior okhaleel/Enforce

  19. Performance Analysis Web resources (ISAPI) Unit: ms Network resource (Global.asax) – new session Network resource (Global.asax) – session refresh okhaleel/Enforce

  20. Future Work • Extend the system to work in a multi-agency environment. • Develop more services that can take advantage of the existing RBAC architecture. For instance: • RBAC E-Voting: users can vote based on their roles. • RBAC Instant Messenger: users can chat based on their roles. • RBAC E-Mail: users can send e-mails based on their roles. • RBAC XXX and so on… • Support more Operating systems (Mac, Solaris …) • Improve the Admin tool to initialize and modify Active Directory, and to be able to generate XACML policies. • Support Wireless access. okhaleel/Enforce

  21. Thesis Contributions • Provide a robust architecture for large-scale companies to address accessing sensitive resources securely according to hierarchical role-based access policy. • Extend XACML to handle Hierarchical Role-Based Access Control (HRBAC) model. • Add a totally new concept of secure access in which a Senior Role can restrict its Junior Role's access using active session's management. • Enhance IIS 6.0 with two components, ISAPI filter and Global.asax. • Simplify PKI and PMI management, therefore, reducing management cost and errors. okhaleel/Enforce

  22. ENforCE DemoQ & A okhaleel/Enforce

More Related