identity management

Identity Management

Campus Developers MeetingSeptember 6, 2006

Agenda

Password Complexity Enforcement, Phase II Minimum Standards for Authentication ServersKerberos Keytab Standards and ProceduresFall ‘06 CUWebAuth ReleaseFall ’06 NetID Cleanup Updates Kerberos 4 to Kerberos 5 Migration Central Authorization System, Phase I

Password Complexity Enforcement – Phase II

Andrea Beesing

Phase I – Spring 2005 Roll-out

Technical implementation of complexity rulesCommunication to campus using various mechanismsAll new NetIDs issued since then have complex passwordsLargely reliant on voluntary compliance for existing users

Phase II – Fall 2006 Roll-out

Create service to enable units and/or service owners to ensure users complyService to consist of Tools (communication templates, for

example) Procedures for obtaining lists of users and

verifying compliance

More info in coming weeks

Standards for Servers Using Central Authentication

Purpose of discussion

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

Background

Concern with risk posed by unauthorized Kerberos proxiesDesire to incorporate in policy as preventative measureSome details originally included in University Policy 5.8, Authentication of Information Technology Resources: http://www.cit.cornell.edu/policy/drafts/AuthenticationITR2.html

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

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 casesAttention to the security of the host’s password or password-equivalent

General principles

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

Comments appreciated

Document will be posted on AADS web site in Developers Meeting sectionSend feedback to amb3@cornell.edu

Keytab Standards and Procedures in a K5 World

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.

Defining terms

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

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

ServiceID name

Format of principle in Kerberos 5: name/instance@REALMProposed rules for name: You choose a name which is relevant to the specific serviceAlternative might be a standard convention similar to that used for NetIDs, for example webapp1, webapp2

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?

CUWebAuth 1.3.2 Release

CUWebAuth 1.3.2 Release

Updated documentation Support for Apache 2.2Support for KFW 3.0 (Kerberos For Windows) Disabled IP checking for SSL connections, more usable for AOL & other IP Pooling customersBug fixesTarget release date: mid to late October

Fall ’06 NetID Cleanup

Fall ’06 NetID CleanupWhat:

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.

K4 to K5 Migration

A Brief Update

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

Discretionary Migration

Old K4 Service ID

New K5 Service ID

current provisioning and

managementinfrastructure

improved provisioning and

managementinfrastructure

K4Support

(Service ownersmigrate at besttime for their services and

Users)

K5Support

Update: K4 to K5 Migration

For Example:General requirementsMIT changes, dates, and impact assessmentCornell project InterdependenciesApplication-specific requirementsNaming conventions for K5Roll-out requirementsBack-out strategy

For Example:Logging SolutionsIdentify active srvtabsEstablish srvtab ownershipIdentify all K4 appsUser impact of potential application changesNon-CIT K4 servicesUncover Independent K4 realmsWhat other institutions are doing

http://identity.cit.cornell.edu

Keeping You Posted

Central Authorization System

Another Brief UpdatePhase 1, Permit Server

Replacement

Initiation Plan 02/10/06

Project Plan 07/06/06

Project Charter 10/24/05

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)

Work Accomplished to Date

Transparent cutover of Permit Server to GrouperSystem owners and application developers migrate at their convenience

Phase One

Requirements

For Example:General requirementsNew use casesBusiness processesCornell project InterdependenciesApplication-specific requirementsName space conventionsRoll-out requirementsBack-out strategySecurity

For Example:Fit-gap analysisPermit server log analysisTesting with I2 ApplicationsWorking Group participationKnown use cases

Project Website: http://identity.cit.cornell.edu/authz/CAP/index.html