identity management
Post on 20-Jan-2016
23 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related