The document discusses authorization at the University of Pennsylvania. It describes Penn's Kerberos deployment with two main realms and various departmental Windows realms in a one-way trust relationship. It also discusses the central Kerberos servers, software and hardware configuration, and additional authorization systems used. The document outlines Penn's efforts to establish a unified user namespace across the university and centralize authentication and authorization to facilitate single sign-on, simplify access management, and stay compliant with policies. Challenges of centralization include gaining buy-in for change and translating local policies to a new centralized format.

1. Authorization
at Penn
Shumon Huque
University of Pennsylvania
Kerberos Conference, October 31st 2012
Massachusetts Institute of Technology
Cambridge, Massachusetts, USA

2. [Kerberos Conference, October 2012, MIT]
Kerberos Deployment
• Two main realms:
• UPENN.EDU : the main one
• A central Windows based realm (1-way trust with UPENN.EDU)
• Various other departmental Windows server based realms
that mostly also have 1-way cross realm relationship with
the central Kerberos servers
2

3. [Kerberos Conference, October 2012, MIT]
Software & Hardware
• Central servers run MIT Kerberos 5 version 1.5.x
• Central servers run on Intel hardware and Red Hat Enterprise
Linux 4.x (current generation > 4 years old)
• Three servers, distributed on 3 distinct IP subnets, located in 3
distinct machine rooms around the campus
• One active master (kadmin server); manual procedure in place to
reconfigure alternate as master
• Servers physically secured in machine rooms; run no extraneous
network services, and provide limited access to the OS via an
OOB console network protected by hardware token
authentication
3

4. [Kerberos Conference, October 2012, MIT]
Authorization Systems
• Kerberos: authentication only
• Applications need to consult separate authorization
system (ours is based on Grouper)
• http://www.internet2.edu/grouper/
• Many windows systems also use their usual methods
(AuthZ data/PAC etc) for additional local policies
• We’re interesting in looking at the PAC/PAD work in
progress in the IETF
4

5. [Kerberos Conference, October 2012, MIT]
Multi-factor Authentication
• Investigated and piloted (but no production use yet):
• CRYPTOCard (using SAM-2 Kerberos pre-authentication)
• RSA SecurID (using 2nd input to CoSign web SSO)
• (We do use SecurID to authenticate access to out-of-band
console sharing networks, but this doesn’t involve Kerberos)
5

6. [Kerberos Conference, October 2012, MIT]
6
Unified Namespace
• Decided in 1995 to unify disjoint user namespaces at
Penn
• Developed a basic name registry service (PennNames)
and tools for applications
• Coordinated with application owners from throughout
Penn
• Group effort to resolve name conflicts over the course
of 6 or 7 years (fairly painful)

7. [Kerberos Conference, October 2012, MIT]
7
Why do we care about
Unified Namespace?
• Reduces confusion and misdirected
communications
• Provides a simpler handle for a broad range of
campus IT services
• Simplified design of campus-wide authentication
system
• Probably simplifies future work on centralized
authorization

8. [Kerberos Conference, October 2012, MIT]
8
Authentication &
• The act of verifying someone’s identity
• The process by which users prove their identity to a
service
• (and vice versa “Mutual authentication”)
• Doesn’t specify what a user is allowed or not allowed
to do (Authorization)

9. [Kerberos Conference, October 2012, MIT]
9
What do we have so far?
• We “know” that the user is who they claim to be
(authentication)
• We don’t know anything about them (roles, affiliations)
• We don’t know what they can do (privileges)

10. [Kerberos Conference, October 2012, MIT]
10
Simple Scenario
• “Hi! I’m Mark!” (Identity)
• “… And here is my PennKey and password to prove
it.” (Authentication)
• “I want to connect to the IMAP server to read my
mail.” (Authorization)
• “And now I want to shut down the DNS
server.” (Authorization)

11. [Kerberos Conference, October 2012, MIT]
11
Authorization Decisions
• Is the user on a list of approved users?
• Is the user a member of an approved group?

12. [Kerberos Conference, October 2012, MIT]
12
The Not-So-Good Old Days
• Every application on its own to make authorization
decisions
• In practice, many assumed that authentication was good
enough (“if you can log in, you’re in”)
• Every application must maintain its own access control
lists or eligibility/ privilege rules

13. [Kerberos Conference, October 2012, MIT]
13
A Better Way
• Make authorization decisions according to local eligibility
policy using central role and privilege definitions
• “All Senior Law Faculty”
• “Any staff in my department, except the birthday boy”

14. [Kerberos Conference, October 2012, MIT]
14
High Level AuthZ Design
AuthZ
Service
Distributed
Management,
Local Data
App
Servers
University
Source
Systems
Access Control
Lists

15. [Kerberos Conference, October 2012, MIT]
15
High Level AuthZ Design
AuthZ
Service
Distributed
Management,
Local Data
App
Servers
University
Source
Systems
Access Control
Lists
AuthN
Service
(usually after an AuthN)

16. [Kerberos Conference, October 2012, MIT]
16
Likely Components
• Grouper and Signet as elements of the AuthZ service
• Web UI that allows distributed management of central
store of local data
• Application access to the AuthZ service by widely
available mechanisms/protocols like LDAP

17. [Kerberos Conference, October 2012, MIT]
17
Benefits of Centralization
• Consistent application of authority rules
• (Many) privileges for an individual can be viewed in one place
• Allows for a historical view of privileges over time
• Allows for automatic revocation based on status or affiliation
changes
• Facilitates hierarchical control of authority

18. [Kerberos Conference, October 2012, MIT]
18
Making the case for
• Stay in compliance with a growing list of policy mandates
• Consistent rules
• Easy auditing
• Save both dollars and time
• Automated privilege changes
• Less specific knowledge needed for every application

19. [Kerberos Conference, October 2012, MIT]
19
Challenges of centralization
• Sufficient motivation for change
• Users and application providers may need related
education
• Resources, control
• Centralized authentication forces units to relinquish control
• Perhaps some software engineering required to separate
authentication from authorization

20. [Kerberos Conference, October 2012, MIT]
20
Challenges of centralization
• Units must understand current authorization/privilege
policies
• This will likely trigger a thorough review of those policies
(probably not a bad thing, but takes time)
• Units must translate those policies into new format

21. [Kerberos Conference, October 2012, MIT]
21
Summing up
• Unified user name space (PennNames)
• Addressing several password issues (many
passwords, varying rules, poor password handling
practices) with central AuthN
• Driving towards secure and practical single signon
through the native use of Kerberos
• Working on two-factor AuthN possibilities
• Pulling together relevant directory,AuthN,AuthZ
technology pieces, plus policies, and physical
identification, towards early stage Identity
Management

22. [Kerberos Conference, October 2012, MIT]
22

23. [Kerberos Conference, October 2012, MIT]
Questions?
Shumon Huque
shuque -@- upenn.edu
23