Lessons Learned from AuthZ Project an Authorization Center Carnegie Mellon University Parviz Dousti

Driving Forces Alumni Email For Life Central Administration of Policies

Services Network Access Cluster Login Access Portal Access Netreg Dialup VPN Cluster Login Access Portal Access Library Access Software Download Email Access

Policies e.g: Softdist: accounts where owner's affiliation is in {Faculty, Special Faculty, Staff} + accounts where owner's affiliation is Student and owner's SIS category is "Enrolled“. Policy: accounts where owner's affiliation is in {Faculty, Special Faculty, Staff, Student} + accounts where owner's affiliation is Alum and owner's Student Class is "2004"

Conceptual Design

Priorities Easiest for Applications and Services Extensibility Using Standards

Why LDAP Standard and unambiguous protocol Already used by most apps. Existing Authentication/Authorization Env. Most policy attributes are already there

LDAP at CMU Openldap Trigger Server SQL(Oracle) backend

Trigs

SQL-back LDAP Uses ODBC to contact an RDBM Can add, modify, delete LDAP entries LDAP users don't know the difference … So we can use RDBM to help with data consistency.

First Design Using LDAP Group Membership as Authorization Service = Group Maintaining static aclGroups Using Oracle triggers Using XACML for policy

First Design

First Design Problems Notion of time not allowed in Policy Policy/Attributes mapping Oracle 9i and Java 1.4 Transactional Problem

Latest Design

Latest Design AuthZ queations: isAuthorized authorizedTo allAuthorized whenAuthorizedThen