1 / 14

Access Control for the JCOP Framework

Access Control for the JCOP Framework. Sascha Schmeling IT/CO. Overview. Goals of Access Control Context JCOP Framework Guidelines SASG Guidelines PVSS Boundary Conditions A Proposal Outlook and Planning. Goals. What to protect? What to protect against? malicious attacks

kerry
Download Presentation

Access Control for the JCOP Framework

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. Access Controlfor the JCOP Framework Sascha Schmeling IT/CO

  2. Overview • Goals of Access Control • Context • JCOP Framework Guidelines • SASG Guidelines • PVSS Boundary Conditions • A Proposal • Outlook and Planning Sascha Schmeling, IT/CO

  3. Goals • What to protect? • What to protect against? • malicious attacks • typing (clicking errors) Sascha Schmeling, IT/CO

  4. Inside the PVSS System • connections between managers will be secure … • What about external connections? • DIM • OPC • What about scripts, panels, libraries? Sascha Schmeling, IT/CO

  5. What to protect against? • malicious attacks • attacks from hackers from outside • “attacks” from ambitious users from inside • non-malicious mistakes • typing mistakes like Ecal instead of Hcal • typing mistakes in settings • ambitious system testers Sascha Schmeling, IT/CO

  6. JCOP Framework Guidelines (I) • Users • all operators and developers will be given a PVSS user account • Groups • PVSS user groups will be established with privileges corresponding to specific roles • Privilege • a user may be allocated a set of privileges directly or indirectly through his association with a particular group • Object • what is accessed in the system (in general this would refer to a CU or a DU) • Domain • this is some user defined grouping of objects, e.g. sub-detector • Object Access Rights • it will be possible to assign a required privilege level to an object or category within the system Sascha Schmeling, IT/CO

  7. JCOP Framework Guidelines (II) • Privilege Levels • Monitor • the user is allowed to view the object but cannot change any parameters • Control • the user is required to have this privilege level to be able to change a restricted range of a particular object’s parameters • Debug • the user is required to have this privilege level to be able to change all parameters of a particular object • Modify • the user is required to have this privilege level to be able to modify the structure of this particular object Sascha Schmeling, IT/CO

  8. JCOP Framework Guidelines (III) • A user will be assigned a privilege level for each object or category defined for that experiment. • Access control should be applied via the HMI, i.e. on buttons, list box items, etc., whose actions need access protection. • A Framework function will be provided to check whether the current user has the privilege to perform an action: • fwGetUserPermission(string privilegeLevelRequired, string domain, boolean &granted, dyn_string &exception) • A Control System developer should use the above function on opening a panel to check whether the current user has the necessary privilege to access the actions possible from this panel and if not to grey out the buttons, list box items, etc., which correspond to actions for which this user does not have the required privilege level. Sascha Schmeling, IT/CO

  9. SASG Guidelines • definitions for Users, Groups, Privilege, and Domain match the JCOP guidelines • privilege levels are stricter than in the JCOP guidelines, and privileges are inclusive • the bits in the permissions word are already defined: • everybody has monitor rights everywhere • 3 bits for Basic, Expert, and Configure • 8 domains • application via the HMI as in the JCOP guidelines is foreseen Sascha Schmeling, IT/CO

  10. PVSS Boundary Conditions • 64 groups with up to 1024 users each • maximum 32 authorization levels (privileges) • 5 standard authorization levels (privileges) • privilege concept per group Sascha Schmeling, IT/CO

  11. Open Questions • Where do we want to protect? • HMI level? • DP level? • How many domains? • How many users? • Shall we use the PVSS permissions? Sascha Schmeling, IT/CO

  12. A First Concept • Protection by Licensing • production system licenses should not contain para entries • Protection by Limited Network Access • production machines should not have outside access capabilities, ssh-tunnels are possible • Protection by File System Rights • have central file server(s) for needed files • Protection by HMI • only propose functions that the particular user may execute • Protection by Relocation • put the functionality into encrypted libraries • Protection on DP level • only for very special DPs Sascha Schmeling, IT/CO

  13. A First Component The JCOP Framework Access Control Component will consist of • panels for user management • a function • fwGetUserPermission(levelRequired,domain) • guidelines • where to put functionality • how to secure the system (files, …) • legacy functions Sascha Schmeling, IT/CO

  14. Project Planning Sascha Schmeling, IT/CO

More Related