Re-engineering the PERMIS Policy Management GUI

1. <RoleHierarchyPolicy> • <RoleSpec OID="1.2.3.4" Type="permis"> <SupRole Value="mapReader"/> <SupRole Value="architect"> <SubRole Value="mapReader"/> </SupRole> <SupRole Value="engineer"/> </RoleSpec> <RoleHierarchyPolicy> Re-engineering the PERMIS Policy Management GUI For more information, contact: Christian Azzopardi, I1-8, Keynes College University of Kent Canterbury, CT2 7NP. Tel. 077 0429 0205 E-mail: csa3@kent.ac.uk Christian Azzopardi University of Kent, Canterbury, UK. Abstract Objectives: To re-engineer the existing Java PERMIS Policy Management GUI software design, whilst maintaining an intuitive and easy to use User Interface for the creation of Role Based Access Control (RBAC) Policies in XML. Methods: After analyzing the existing Editor, various software design flaws were found, and new designs were drafted. Improvements to the User Interface had to be done as it lacked basic GUI functionality. Results: The new Editor is built from various components, that are reused throughout the program. Changes are easier to conduct using the better object oriented based code. Conclusions: The new design can display a whole policy in just one window, and what was previously scattered on various tabs is now integrated onto one. The Code can be re-used in other applications and is easy to extend and upgrade. Screenshot of a policy • Editor Features • Built in components that can be reused for different applications. • Users can get accustomed to the user interface easier. • Easy to upgrade, as the Editor loads the sub-policies on startup. • The application can display many policies at once in different resizable windows, each being subdivided and portrayed in tabs. • Each tab allows the user to read the policy created within, in plain English. • Undo/Redo Functions. • A Policy Validator, will inform the user when a valid PERMIS policy has been opened, and if faulty, will prompt the location of the fault, and give some hints about what to change. • The lists are sorted alphabetically. • The user can change the current LDAP server to any server that was pre-configured in the LDAP Directory configuration dialog. • The Editor can be easily translated to different languages. • Results and Conclusions • Policies created can now be used for various applications to allow/restrict access. The advantage of integrating such policies with existing technology, is that the user does not notice any difference when authenticating himself, although the policy defines much more than a username/password. • Further Work • Signing and publishing. • Printing of the Readable Policies. • Improving the help files. • Testing the new editor with novice users, and must be done to see how quickly the users adapt to use the new Editor. The 8 Editors that build up the policy could be selected when clicking on the respective tabs. The Name of the XML Policy Policy Editor Architecture English readable policy that is created with above sections. The previous editor had these three sections in three distinct tabs, and now they could be visualised all at once. XML Generated from the above screenshot: Supervisors: Prof. David W. Chadwick Dr Alexander Otenko