NERCOMP SIG

1
Deploying Identity and Access ManagementA work
in progress

• NERCOMP SIG
• Identity Management
• Christopher Misra
• 26 September 2005

2
Outline

• History/background
• Current system design
• Current challenges
• IdM Project design
• Project Assumptions
• Project design
• Project deployment
• Where next?

3
Campus Statistics

• Academics
• 10 schools and colleges
• 88 undergraduate majors
• 68 masters and 50 doctoral programs
• 142 Buildings
• 42 Residence Halls (3 under construction)
• Campus size
• 1,450-acres

4
Campus Statistics

• User base
• 25,000 students
• 35,000 user accounts
• Infrastructure
• 1400 Switches, 300 Wireless APs
• 8000 Academic building connections
• 11000 Residence hall connections
  (port-per-pillow)
• Bandwidth
• 400Mb/s - Commodity Internet connections
• 155Mb/s - Internet2 connection

5
Definitions

• Authentication is the process of establishing
  whether or not a real-world subject is who or
  what its identifier says it is. Identity can be
  proven by
• Something you know, like a password
• Something you have, as with smartcards,
  challenge-response mechanisms, or public-key
  certificates
• Something you are, as with positive photo
  identification, fingerprints, and biometrics
• http//middleware.internet2.edu/core/authenticatio
  n.html

6
Definitions

• Authorizations express the characteristics of an
  identifier. These attributes can be used to make
  access control decisions about the use of
  resources. These can include
• Class of user (faculty, staff, student)
• Role
• Group membership
• Etc

7
Current Account Management

• Home-grown provisioning system
• DB-backend with custom mgmt apps
• Original system designed 12 years ago
• Accounts populated to MIT Kerberos DB
• Authorizations maintained by each application
• Modified via provisioning code
• Quotas, email routing, etc

8
Account Management Challenges

• System 12 years old
• No capability for provisioning authorization
  attributes
• Original system designed around only
  authenticators
• Organizational and staffing changes have raised
  questions of sustainability

9
Current Authentication Systems

• Most central IT services authenticate against MIT
  Kerberos
• Originally deployed 1994 beta code
• Added RADIUS lt-gt Kerberos backend 1997
• Multiple kerberos realms
• Some legacy services use Unix passwords

10
Current Authentication Systems
11
Authentication System Challenges

• Architectural changes required due to legacy
  deployment decisions
• Centralizing authentication led to default
  authorizations
• If a user is granted a Kerberos authenticator
  they gain access to more than one service
• No capability to individually limit these
  services
• Disabling a user account for a security violation
  may lead to unnecessary service outages

12
Authentication System Challenges

• New service deployments require LDAP for
  authentication
• Generally, no native Kerberos support
• Need to leverage existing authentication systems
• Limit changes to provisioning processes
• No capabilities to provide user-based
  authorizations to application
• Groups, roles, service profiles

13
Toward Identity Management

• Identity management (IdM) infrastructures
  consolidate information about individuals and
  provide a nexus for policy, security, and
  resource access management
• http//www.educause.edu/ir/library/powerpoint/EAF0
  502.pps
• This reflects the goals and outcomes for our
  directory project.

14
Directory Project Assumptions

• Data will be sourced from existing resources
• Recent campus-wide project to update these data
  sets and systems
• Peoplesoft Student/HR data
• Directory design will be consistent with best
  practices in higher education

15
Directory Project Assumptions

• Provisioning system will also be updated/replaced
• Developed within consistent framework of
  HR/Student systems
• Must reproduce current functionality
• Add capabilities for provisioning of
  authorization attributes

16
Directory Project Assumptions

• Directory schema will be based on EduPerson
• Consistency with other efforts in higher ed
• http//www.educause.edu/eduperson/
• Local schema will be child of EduPerson schema
• UMassEduPerson
• Schema still being refined
• Coordinated with activities of the University
  System

17
Project design

• All new services will authenticate via LDAP
• Based on authenticator and authorizations
• Each new service will be issued authentication
  credentials
• All attribute released will be controlled to
  authenticated applications
• Current services will be migrated to LDAP authn/z
  over time
• Network Access
• Access to HR/Student system

18
Planned Authentication/Authorization Design
19
Project Deployment

• Constraints
• Limited LDAP experience on staff
• Limited staffing caused a temporal shift in
  deployment schedule
• Strengths
• Deep experience with Kerberos, provisioning
  software, service deployment and migration
• Authentication system designed to accommodate
  authorization services

20
Project Deployment

• Experimental application required LDAP for
  authentication
• Web-based file service
• Initial applications migrated to reproduce
  current functionality
• Authenticated, authorized web-space limited to
  staff in a particular department
• Authorization list currently managed manually
• First production application
• Web-based file service

21
Project Deployment Plans

• LDAP as authentication service for HR/Student
  system
• However, this poses some challenges of
  integration of provisioning with these systems
• Desire to unify a high visibility service under a
  consistent authenticator
• Likely integrated with a planned software upgrade

22
Project Deployment Plans

• Migrate campus RADIUS infrastructure to use LDAP
• LDAP service authenticates users against KDC
• Allows individual services to granted/denied
  based on identity attributes
• E.g. Wireless access may be granted to some all
  users, while dialup is limited to faculty and
  staff.
• Many services benefit with limited infrastructure
  migration

23
Project Deployment Plans

• New authenticators will be deployed for directory
  service.
• Some identifies do not map cleanly in to current
  authenticator namespace
• Will pose some operational complexities
• Opportunity to have users enable new services
• We only have a chance to do this once every 10
  years or so

24
Project Deployment Plans

• Completion of near-real time provisioning
  infrastructure
• To accommodate some services.
• Deployment of a new suite of self-service account
  management tools
• Required to solve previous provisioning system
  integration problems
• Management of user-controlled attributes requires
  a set of tools
• Possibly including dynamic service provisioning

25
Outstanding Challenges

• Designing processes to accommodate migration of
  users to new authentication system
• Deeper involvement in with Help Services
• Deployment of replacement provisioning systems
• Provisioning is at the heart of all our IT
  services
• But it all just works now

26
Outstanding Challenges

• Not making design assumptions that we will regret
  in 10 years
• We may not being necessarily doing the right
  thing, but we are trying hard to not do the wrong
  thing

27
Where next Directory Software

• Deploying provisioning system in coordination
  with our HR/Student system
• DB design
• Process changes driving software changes
• Developing software evaluation criteria for more
  thorough evaluation of software
• Possibly using commecial directory packages
• Though our initial rollout will be focused on
  open source software, we are not committed to
  either direction

28
Where next Group Management

• Designing a group management strategy
• Current deployment is focused on basic
  user-centric attributes
• We plan to integrate group management for IT
  services on the this directory project
• Complete evaluation of packages for managing
  groups and namespaces
• Related to our software evaluation
• Possibly using Grouper
• http//middleware.internet2.edu/dir/groups/grouper
  /

29
Where next Extending Web Services

• We are currently using a web-based initial
  sign-on service to protect access to web
  applications
• Some questions of long term sustainability of
  current software package
• Currently authorizations are controlled by local
  data on the application server
• Need to integrate data in the directory
• Possibly with mod_ldap through apache

30
Where next Shibboleth

• Shibboleth leverages institutional sign-on and
  directory systems to work among organizations by
  locally authenticating users and then passing
  information about them to the resource site to
  enable that site to make an informed
  authorization decision.
• http//shibboleth.internet2.edu/

31
Where next Federations

• We have some projects that involve access to
  protected resources shared among communities of
  trust
• Several regional consortium of colleges
• Shared wireless access
• Contractual access to library resources
• Possible (probably) using Shibboleth as technical
  trust infrastructure
• Need policy framework

32
Where next Federations

• A federation is an association of organizations
  that come together to exchange information as
  appropriate about their users and resources in
  order to enable collaborations and transactions.
• http//www.incommonfederation.org/glossary.cfm

33
Where next InCommon

• A formal federation of organizations focused on
  creating a common framework for trust in support
  of research and education
• Supports web-based distributed authentication and
  authorization services
• Preserves privacy since the home institution
  controls when identity is disclosed
• http//www.incommonfederation.org

34
Where next But first, InQueue

• A federation of organizations interested in using
  the Shibboleth technology and exploring how
  federations work
• A transitional phase for organizations before
  joining another federation
• Intended to prepare organizations to join other
  federations by facilitating experience with
  federations and federated authentication
  technology
• http//inqueue.internet2.edu/

35
Project Success

• To be determined
• These services have been discussed in various
  forums on campus and within the system for 5
  years.
• Hopefully we have made the right decisions, weve
  certainly talked about it an awful lot.
• We now have good energy and a positive direction
• A sense of inevitability

36
Questions?