150 likes | 246 Views
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 Netreg Dialup VPN Cluster Login Access Portal Access Library Access
E N D
Lessons Learned fromAuthZ Projectan Authorization Center Carnegie Mellon University Parviz Dousti
Driving Forces • Alumni Email For Life • Central Administration of Policies
Services • Network 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"
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
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 Problems • Notion of time not allowed in Policy • Policy/Attributes mapping • Oracle 9i and Java 1.4 • Transactional Problem
Latest Design • AuthZ queations: • isAuthorized • authorizedTo • allAuthorized • whenAuthorizedThen