1. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 1 Beyond the LAMP - Moving authentication and access control into the database LCA 2009 – Hobart

2. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 2 Overview the traditional LAMP model motivation postgresql authentication and access control hierarchical groupings views, functions and triggers normalising the hierarchy at connection time issues

3. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 3 Traditional LAMP model LAMP - Linux, Apache, MySQL, Perl/PHP/Python or Linux, Apache, Middleware, Postgresql don't confuse with WIMP - Windows, IIS, MySQL, Perl/PHP/Python! typical paradigm for most web-based applications middleware (Perl, PHP, Python, Java, Ruby etc.) does authentication and access control and connects to database as a single universally privileged user

4. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 4 New Model web (and other) applications attempt to connect to database as a particular user (with credentials) database maintains strong (non-repudible) notion of ”who” is on each database connection database imposes access control over what each user can read/write/modify/delete not really new - most big-iron database apps have been doing it this way for decades...

5. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 5 Motivation for change Faculty Administrative Information System single (PostgreSQL) database multiple applications (some web-based, others not) multiple languages: mainly PHP, also Perl, Python, C and some Java some IT-savvy users want to write other apps or just to have access to (some) data in database need to impose privacy and integrity over data

6. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 6 Some use cases Forums - mix of staff and student access with various read/post/moderate etc. permissions Students registering into small group teaching (tutorials, labs, group projects etc.) Student marks - read and modify access by students, tutors, lecturers and administrators of course there are many others...

7. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 7 PostgreSQL project started about 9 years ago needed foreign keys, functions, views etc. chose PostgreSQL mainly due to open-source (Oracle was an option at the time...) triggers and support for multiple (many) users has become very useful...

8. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 8 Authentication Can't do access control without robust authentication PostgreSQL has notion of current_user Several authentication methods: password file - hard to securely update pg_authid table / pg_shadow, pg_user views LDAP and PAM Kerberos others

9. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 9 Access Control 101 need to control access to data in the database prefer a generic model which is easy to parse in SQL functions (eg. easily machine readable) makes sense if same model/data used for access control and actual representation of people and their roles within the organisation PGACE - PostgreSQL Access Control Extensions postgresql-selinux...

10. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 10 Access Control Models Initially trialled a ”Role/Capability/Area” model each user allowed one or more roles in one or more areas (divisions/departments etc.) each role allowed one or more capabilities neatly reflects organisation for staff

11. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 11 Access Control Models 2 some issues with getting clean SQL functions to work some issues with hierarchy of roles: people in central areas with wider responsibility do not automatically inherit access to sub-areas main issue with students where we don't have a clean notion of an area need more granularity: courses, small groups etc.

12. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 12 Hierarchical Groups Currently trialling a hierarchical groups model each person (users and non-users) in own private group groups can belong to one or more other groups ie. each group can have multiple parents and multiple children (except leaf nodes!) loops not allowed various accesses can then be granted to a group

13. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 13 Hierarchical Groups 2 sort of reflects the PostgreSQL system users and roles tables and views (pg_users, pg_shadow etc.) alas, can't foreign-key reference system tables also, groups (roles in PostgreSQL) need to include finer-grained access controls

14. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 14 Core schema three core tables grp - the group table - primary key gid mem - the member table - links parent and child groups person - actual people - primary key pid references gid in grp

15. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 15 Data Security Model all raw data belongs to one super-user (eg. postgres) and is not directly exposed to other users use views and triggers/functions to expose selected parts of raw data to users functions can run as the function definer or as the function invoker cf. traditional LAMP model...

16. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 16 need a way to recursively determine group membership (not a normal ”relational” concept)

17. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 17 Performance improvements running recursive functions (with non-deterministic run-time) for each access is a performance problem most accesses are reads (SELECT) so data not changing maintain an indexed table of all groups that a currently connected user is a member of checking access control is now an O(1) operation run a triggered update at connection time

18. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 18 Performance alternatives alternative to connection time flat-file update: keep the ”flat_file” current all the time and use triggers on insert/update/delete of mem table could be really expensive as need to update all users (not just those connecting).

19. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 19 Hacking PostgreSQL handy to automatically create normalised list of member groups at database connection time add a new trigger to PostgreSQL to run a function at connection time currently a work in progress...

20. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 20 Issues single user namespace in PostgreSQL server for all databases in the cluster persistent connections performance development/debugging (esp. on ”live” data) violates KISS

21. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 21 Alternatives introduce a new application between middleware and database to impose access control use SQL between access control app and database what to use between middlewares and AC app? could use SQL... XML/HTML other

22. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 22 Where next? Need to investigate proposed PostgreSQL Access Control Extensions (may already have been adopted) need to finish a real application with many simultaneous users and deploy it into production... look at pushing some of the group-based access control into the database engine itself (extend the existing system roles and auth tables)

23. LCA 2009 - 22 Feb.Bob Edwards - School of Computer Science, ANU 23 The end. Thanks!