Identity Management

1
Identity Management
Campus Developers Meeting September 6, 2006
2
Agenda

• Password Complexity Enforcement, Phase II
• Minimum Standards for Authentication Servers
• Kerberos Keytab Standards and Procedures
• Fall 06 CUWebAuth Release
• Fall 06 NetID Cleanup
• Updates
• Kerberos 4 to Kerberos 5 Migration
• Central Authorization System, Phase I

3
Password Complexity Enforcement Phase II
Andrea Beesing
4
Phase I Spring 2005 Roll-out

• Technical implementation of complexity rules
• Communication to campus using various mechanisms
• All new NetIDs issued since then have complex
  passwords
• Largely reliant on voluntary compliance for
  existing users

5
Phase II Fall 2006 Roll-out

• Create service to enable units and/or service
  owners to ensure users comply
• Service to consist of
• Tools (communication templates, for example)
• Procedures for obtaining lists of users and
  verifying compliance
• More info in coming weeks

6
Standards for Servers Using Central Authentication
7
Purpose of discussion

• Provide background on how the standards came
  about
• Outline general principles informing the
  standards
• Get feedback from you
• Are the standards clear?
• Are there additions we should consider?
• What can we do to assist with compliance?

8
Background

• Concern with risk posed by unauthorized Kerberos
  proxies
• Desire to incorporate in policy as preventative
  measure
• Some details originally included in University
  Policy 5.8, Authentication of Information
  Technology Resources http//www.cit.cornell.edu/p
  olicy/drafts/AuthenticationITR2.html

9
Background

• Existing, more comprehensive document is result
  of
• Preference to avoid technical implementation
  details in policy
• Initial confusion around which authN alternatives
  carry the strictest requirements
• Other business drivers such as adoption of SOA
  and expansion of user community

10
General principles

• Stricter standards where risk is highest (i.e.
  Kerberos proxies)
• Dual-factor authentication
• Availability of detailed logs to IT Security
• Encryption is desirable in most cases
• Attention to the security of the hosts password
  or password-equivalent

11
General principles

• Authentication and authorization should be kept
  separate
• In general, one-to-one mapping between service ID
  or principle and application

12
Comments appreciated

• Document will be posted on AADS web site in
  Developers Meeting section
• Send feedback to amb3_at_cornell.edu

13
Keytab Standards and Procedures in a K5 World

14
Defining terms

• Keytab - A keytab is a host's copy of its own
  keylist, which is analogous to a user's password.
  An application server that needs to authenticate
  itself to the KDC has to have a keytab that
  contains its own principal and key. Just as it is
  important for users to protect their passwords,
  it is equally important for hosts to protect
  their keytabs.

15
Defining terms

• ServiceID The principal which identifies the
  server or service which is authenticating itself
  to Kerberos

16
Standards and procedures

• Will cover things like
• Who is authorized to request the keytab
• Additional information required at time of
  request for tracking purposes
• Two items for you to think about
• Naming rules for ServiceID
• Annual renewals

17
ServiceID name

• Format of principle in Kerberos 5
  name/instance_at_REALM
• Proposed rules for name You choose a name which
  is relevant to the specific service
• Alternative might be a standard convention
  similar to that used for NetIDs, for example
  webapp1, webapp2

18
Keytab renewals

• Annual renewal/reissue of all keytabs?
• Two goals
• Currency of information associated with the
  keytab, especially contact names
• Security of keytab
• How would annual reissue impact you?

19
CUWebAuth 1.3.2 Release
20
CUWebAuth 1.3.2 Release

• Updated documentation
• Support for Apache 2.2
• Support for KFW 3.0 (Kerberos For Windows)
• Disabled IP checking for SSL connections, more
  usable for AOL other IP Pooling customers
• Bug fixes
• Target release date mid to late October

21
Fall 06 NetID Cleanup
22
Fall 06 NetID Cleanup

• What
• One (1) Student cleanup a year (in the Fall)
• Two (2) Staff cleanups a year (Spring and Fall)
• Who (this Fall)
• Staff, Students, and Affiliates
• Affiliates Boyce Thompson, USDA, CRESP, CUMC,
  ROTC, Public Service Center, PRI, Cornell Alumni
  Magazine, Campus Club
• When
• Notifications (HR, service owners) 9/6 - 9/13
• E-mail notification to cleanup candidates 9/21
• Tag directory records, remove permits 10/25
• HR reps can get a custom list for their dept.

23
K4 to K5 Migration
A Brief Update
24
Work Accomplished to Date

• Investigations conducted to
• Understand what our peer institutions are doing
• Identify all services using central
  authentication
• Discover services which will require special
  attention and begin focusing on potential
  solutions (e.g. Netprint)
• Identity software components with dependencies on
  Kerberos 4
• Assessment and planning of work required to move
  away from Kerberos 4
• Technical infrastructure
• User experience
• Initial design strategy

25
Discretionary Migration
New K5 Service ID
improved provisioning and management infrastruct
ure
K5 Support
current provisioning and management infrastructu
re
K4 Support (Service owners migrate at best time
for their services and Users)
Old K4 Service ID
26
Update K4 to K5 Migration
For Example Logging Solutions Identify active
srvtabs Establish srvtab ownership Identify all
K4 apps User impact of potential application
changes Non-CIT K4 services Uncover Independent
K4 realms What other institutions are doing
For Example General requirements MIT changes,
dates, and impact assessment Cornell project
Interdependencies Application-specific
requirements Naming conventions for K5 Roll-out
requirements Back-out strategy
27
(No Transcript)
28
Keeping You Posted

• http//identity.cit.cornell.edu

29
Central Authorization System
Another Brief Update Phase 1, Permit Server
Replacement
30
Work Accomplished to Date
Initiation Plan 02/10/06
Project Plan 07/06/06
Project Charter 10/24/05
31
Work Accomplished to Date

• Initial investigations
• Fit-Gap analysis between Permits and I2 Grouper
• Early versions of Grouper running in test
• Baseline requirements and use cases
• Migration strategy
• Phased approach
• Phase One Permit Server replacement (I2 Grouper)
• Phase Two Privilege Management (I2 Signet)

32
Phase One

• Transparent cutover of Permit Server to Grouper
• System owners and application developers migrate
  at their convenience

33
Requirements
34
For Example General requirements New use
cases Business processes Cornell project
Interdependencies Application-specific
requirements Name space conventions Roll-out
requirements Back-out strategy Security
For Example Fit-gap analysis Permit server log
analysis Testing with I2 Applications Working
Group participation Known use cases
35

• Project Website http//identity.cit.cornell.edu/a
  uthz/CAP/index.html