1. Application Index/Framework Security A. Petrov, 11/21/02

2. Obstacles Various types of executable codes (Java classes, HTML, SVG, JScript, … ). Various code sources (shared drives, Apache and Tomcats). Various types of user authentication (via web browser, Kerberos, … )

3. Obstacles - II It is seemed to be possible to create a manual bypass in almost every case. System is under permanent change and is not understandable as a whole ( at least, for me… )

4. Goals 1) Create a core application security system to distribute permissions on/for applications. 2) Implement several borders of protection, based on this core system.

5. Borders Of Protection Application Index – list of available programs depends on actual user privileges. Code sources – against unauthorized code download Security check in App. Framework – against unauthorized launch

6. Borders Of Protection - II DAE connection – against unauthorized data usage and modification

7. Application Browser Downloading Code DB From shared drive Static HTML, JARs, … JNLP Generator Launching Based on Framework Not based on Frwrk Servlets Based on Framework Not based on Frwrk Servlets DAE Connection Is implemented Will be implemented

8. Users A generic VMS table of login names is used, dbo.console_user. APPiX has an additional table with encripted passwords (for web access). GUI to edit users is not provided.

9. User Privileges VMS classes are used; they considered to be groups in Application Index. Two pseudo-classes are added: PUBLIC and INSIDER; “dynamic” membership, depending on access mode. INSIDER is a subset of PUBLIC.

10. nameclasses… apetrov console_user_id 807$800… a dbo.console_user record: 1. MCR 2. RemoteMCR 3. CHL 11. AccelPrgrmmer … … INSIDER PUBLIC APPiX groups: Depends on access mode

11. Application Privileges A special APPiX table is used; every application may have membership in several groups + is_writable flag. Application privileges are used: 1) to define who can start an application 2) as service privileges for DAE 3) to define whether an app. is “writable”.

12. AppFramework Test Application: 1. MCR 3. CHL 11. AccelPrgrmmer INSIDER APPiX groups: 1 0 1 0 is_writable Service privileges: $802 May start May start: MCR, CHL, AccelPrgrmmer, INSIDER May write May write: MCR, AccelPrgrmmer

13. Servlet Privileges A special AppixRealm module is developed for Tomcat. Privileges are checked: 1) by Tomcat itself ( web.xml file) 2) by servlets

14. Servlet Privileges - II All interaction between Application Index database and Application Framework (and Console Application Launcher) takes place via servlets.

15. User Authentication For servlets – through Tomcat’s AppixRealm. For DAE – through Kerberos. It still looks unclear how to implement Kerberos security when the web-client is a browser (but it’s probably possible for framework-based applications).

16. User Authentication - II In general, user authentication is not required: a default user has some privileges (through PUBLIC and INSIDER pseudo-classes).

17. Secure Socket Layer (SSL) DOE does not allow purchasing “real” SSL certificates. (?) … and so: Entering password in Application Index is now forbidden for outside users (all outside users belong to PUBLIC pseudo- class).