Parviz Dousti IT Consulting Engineer Computing Service Carnegie Mellon University

1. S3 Authorization Framework“Managing Access in Student Information System at Carnegie Mellon University” Parviz Dousti IT Consulting Engineer Computing Service Carnegie Mellon University Oct. 1st 2012

2. Background • Student Services Suite (S3) • A Brownfield development of SIS • Completely new Authorization • Had a Discovery Project to answer: • Have a Central Authorization System? • Use an Open Source Solution? • Buy a Product? • Write our own?

3. Requirements • Modularized :Complete Independence from the Application • Configurable: i.e. not hard-coded • Flexible and Powerful: Capable of Handling Complex User Stories in SIS • Time based authorizations • e.g. add/drop period • Quantity/Amount based authorization • e.g. refunding • Relation based authorization. • Department Admins Access to Students of a Certain Program • Advisor – Advisee relation. • Original Creator of a Memo

4. Framework Design Goals • Powerful (RBAC, ABAC, filtering) • Encapsulated, isolated • Reusable • Simple • Scalable, fast

5. High Level Architecture

6. Authorization Vocabulary • Permission: • User/Group can do Action on a Resource [based on Qualifier(s)] • Examples: AcademicAdmins can Update/cmu/s3/admin/course_grades [if course belongs to their department]

7. Entities(Abstract) User Group Action Permission Qualifier Resource

8. Entities(Implemented) User Qualifier Values Group (61) Permission Qualifier (33) Resource:Action (199)

9. S3 Authz Building blocks Developer Business Owner • Resource • Qualifier • Users • Groups • Qualifier Values • Permissions

10. Resources • Identifier of any “thing” to be protected • Adheres to standard form: <cmu namespace>:<system>:<resource type>:<resource>=<action> • For example: urn:mace:cmu:edu:andrew:s3:admin:screen:students:grades=view

11. More on Qualifiers • Fixed Attribute and custom Qualifiers • May use user’s inherit attributes or affiliations • May use existing authorization tables in SIS • Can be combined in a Boolean expression • Not all are meaningful for a permission

12. Custom Qualifiers • Implemented as simple Java classes public class IsEnrolled implements Qualifier { public booleanisSatisfied(String userId, Map ctx) { return dao.isEnrolled(ctx.get(“studentId”)); } }

13. Fixed-Attribute Qualifiers public class StudentDeptAR implements AttributeRetriever { public AttributeSetfetchAttributes(Map ctx) { Student student = dao.fetchStudent( ctx.get(“studentId”); AttributeSet as = new AttributeSet(); as.setAttribute1(student.getDepartment()); return as; } }

14. API // API public interface AuthorizationEngine { booleanisAuthorized(String userId, String resource, Map<String, Object> context); } // Example call context.put(“studentId”, “northrop”); authzEngine.isAuthorized(“dl2b”, “screen:student:grades=view”, context);

15. Evaluating Design Goals • Powerful (RBAC, ABAC, filtering) • Yes! groups + qualifiers • Encapsulated, isolated • Yes!authz engine + resource + custom qualifiers • Reusable • Yes! qualifiers applied to any resource • Simple • Yes! must only “tag” resources + write qualifiers • Scalable, fast • Yes! optimizations for caching and aggregating calls

16. Some UI Screenshots

17. Authorization Console

23. Thanks To: • Darleen LaBarbera- VP for Campus Affairs, Carnegie Mellon University • Ben Northrop - Distinguished Technical Consultant, Summa

24. Questions?