1 / 35

Identity Management

Identity Management. Campus Developers Meeting September 6, 2006. 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

hovan
Download Presentation

Identity Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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/policy/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 host’s 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@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@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 infrastructure K5 Support current provisioning and management infrastructure 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. Keeping You Posted http://identity.cit.cornell.edu

  28. Central Authorization System • Another Brief Update • Phase 1, Permit Server Replacement

  29. Work Accomplished to Date Initiation Plan 02/10/06 Project Charter 10/24/05 Project Plan 07/06/06

  30. 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)

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

  32. Requirements

  33. For Example: Fit-gap analysis Permit server log analysis Testing with I2 Applications Working Group participation Known use cases 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

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

More Related