Idm campus developers meeting 6 18 07
This presentation is the property of its rightful owner.
Sponsored Links
1 / 71

IdM Campus Developers Meeting 6/18/07 PowerPoint PPT Presentation


  • 70 Views
  • Uploaded on
  • Presentation posted in: General

OIT/CIT Security, Identity Management Team. IdM Campus Developers Meeting 6/18/07. Introduction CUWebAuth 2.0 and K4-K5 Upgrade Central AuthZ Phase 1 ServiceID Manager Shibboleth IdM Provisioning Projects. Andrea Beesing [email protected] Opening Remarks. Fast-track projects

Download Presentation

IdM Campus Developers Meeting 6/18/07

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Idm campus developers meeting 6 18 07

OIT/CIT Security, Identity Management Team

IdM Campus Developers Meeting 6/18/07

  • Introduction

  • CUWebAuth 2.0 and K4-K5 Upgrade

  • Central AuthZ Phase 1

  • ServiceID Manager

  • Shibboleth

  • IdM Provisioning Projects


Opening remarks

Andrea Beesing [email protected]

Opening Remarks

  • Fast-track projects

  • Emergency mass notification support

  • Active Directory for Exchange


Fast track projects

Fast-track projects

  • Launched at President Skorton’s request within the past few months/weeks

  • Important for different reasons

    • Health and safety

    • Cornell’s endowment

  • July targets for IdM work to complete with August go-lives


Emergency mass notification support

Emergency Mass Notification Support

  • Charge to the Cornell Emergency Management Committee

  • Mechanism for notifying community members by voicemail, email and cell phone

  • Changes to WhoIAm by August 15 for students, affiliates, sponsored exceptions

  • Changes to self-service front end for contact info for faculty and staff in early fall from WhoIAm to Employee Essentials

  • New attributes in directory (all private)

  • Personal cell phone attribute will have privacy selection


Active directory for exchange

Active Directory for Exchange

  • Very narrow scope with attention to scalability for future

  • Integration with other IdM infrastructure

    • Kerberos

    • Provisioning/enterprise directory

  • Phase II to follow

    • Campus Steering Committee (members identified)

    • Address broader campus needs, support model

    • Please bring your concerns to my attention!


Cuwebauth 2 0 and k4 k5

Tom Parker [email protected]

CUWebAuth 2.0 and K4-K5

  • Current schedule keying on PS Student Records roll-out in Mar ’08 to reduce customer resource requirements

  • Issues with current code base used for web single sign-on argue for reassessing our approach to the Kerberos 5-only release

  • Timeline for retirement of Kerberos 4 now three to six months out


Opportunity identified

Opportunity Identified

  • Can we use additional window in K4 shutdown schedule to position ourselves to better support our web-based authentication solution for the long term?

  • Specifically:

    Should we invest resources in rewriting CUWebAuth (used with applications) and CUWebLogin (infrastructure component)?


Kerberos 5 upgrade where are we now

Kerberos 5 Upgrade: Where Are We Now?

6/14 Identity Management Rollout

Campus Rollout Complete

PS Student Launch

You Are Here

K4 Shutdown

Dec

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

2007

2008

Discretionary

migration window


Where are we now

Where Are We Now?

  • Code review (4 code bases)

6/14 Identity Management Rollout

Campus Rollout Complete

PS Student Launch

You Are Here

K4 Shutdown

Dec

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

2007

2008

Discretionary

migration window


Where are we now1

Where Are We Now?

  • Code review (4 code bases)

  • Security audit (new vulnerabilities)

6/14 Identity Management Rollout

Campus Rollout Complete

PS Student Launch

You Are Here

K4 Shutdown

Dec

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

2007

2008

Discretionary

migration window


Where are we now2

Where Are We Now?

  • Code review (4 code bases)

  • Security audit (new vulnerabilities)

  • Rollout requirements

    • (PS launch)

6/14 Identity Management Rollout

Campus Rollout Complete

PS Student Launch

You Are Here

K4 Shutdown

Dec

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

2007

2008

Discretionary

migration window


Where are we now3

Where Are We Now?

  • Code review (4 code bases)

  • Security audit (new vulnerabilities)

  • Rollout requirements

    • (PS launch)

6/14 Identity Management Rollout

Campus Rollout Complete

PS Student Launch

You Are Here

K4 Shutdown

Dec

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

2007

2008

Discretionary

migration window


Where are we now4

Where Are We Now?

  • Code review (4 code bases)

  • Security audit (new vulnerabilities)

  • Rollout requirements

    • (PS launch)

6/14 Identity Management Rollout

Campus Rollout Complete

PS Student Launch

You Are Here

K4 Shutdown

Dec

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

2007

2008

Discretionary

migration window


Where are we now5

Where Are We Now?

  • Code review (4 code bases)

  • Security audit (new vulnerabilities)

  • Rollout requirements

    • (PS launch)

6/14 Identity Management Rollout

Campus Rollout Complete

PS Student Launch

You Are Here

K4 Shutdown

Dec

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

2007

2008

Discretionary

migration window


Where are we now6

Where Are We Now?

  • Code review (4 code bases)

  • Security audit (new vulnerabilities)

  • Rollout requirements

    • (PS launch)

window of opportunity

6/14 Identity Management Rollout

Campus Rollout Complete

PS Student Launch

You Are Here

K4 Shutdown

Dec

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

2007

2008

Discretionary

migration window


Current state

Current State

  • Age of code = complexity = support burden for CIT and the customer

  • High potential for introducing security vulnerabilities when changes are made both to code itself and individual app config files

  • Difficulty providing product support for standard tools and new releases of operating systems


The reasonable options

The Reasonable Options

  • CUWA/CUWL 1.5 – Attempt to fix what we have

  • CUWA/CUWL 2.0 – Re-build it the way it should be

  • Move to an outside solution

    • Yale CAS

    • Stanford WebAuth

    • CoSign


Service goals considered

Service goals considered

  • Impact of change on campus developer community

    • Minimal work required to migrate to new versions

    • Support for required functionality

  • Predictability of user experience

  • Long-term viability of CIT’s authentication solution for web-based services

    • Performance and scalability as use of CUWA and CUWL increase

    • Support for new server operating systems and web servers (Apache, IIS)

    • Support for future enhancements to authentication and authorization

  • Security of central authentication services

  • Efficient use of scarce CIT resources


Proposal

Proposal

  • Consider rewrite of CUWA and CUWL based on high-level design reviewed by ATA, IS, IT Security and campus development partners

  • Advantages identified to date

    • Merging CUWA into one code base, down from two

    • Separate security configuration from other configuration parameters, leading to fewer security issues for apps

    • Ability to routinely support new operating systems

    • Compatibility with standard tools (ex: PHP)


Recommendation

Recommendation

  • CUWebAuth 2.0 Implementation

  • Late Fall 2007 deployment

  • Maintain migration window

Identity Management Rollout

Campus Rollout Complete

Develop CUWebAuth 2.0

PS Student Launch

Ide

K4 Shutdown

Dec

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Apr

May

Jun

2007

2008

Discretionary

migration window


Five questions from srm

Five Questions from SRM

  • Why not go with CUWA 1.5?

  • What do we get by writing CUWA 2.0?

  • Will we have to give up other work?

  • What are the longer-term implications?

  • Would an outside solution be smarter?


1 why not go with cuwa 1 5

1. Why not go with CUWA 1.5?

Condition of 8-year-old code has become a support burden

Significant work required for even minor changes

Impact of change on other portions of code difficult to test prior to release, results in more problems for campus service providers

More bugs and security vulnerabilities as a result

Currently requires 2 FTE’s

Increasing campus dependency on CUWebLogin = scalability and performance issues

SideCar limitations and scheduled retirement

Preference for web-based applications


2 what do we get by writing cuwa 2 0

2. What do we get by writing CUWA 2.0?

Product that is easier to maintain

Simpler protocol

Legacy dependencies eliminated

Less code duplication (one code base instead of four)

More extensible code (and all within local control)

More secure protocol

More scalable web single sign-on solution

No loss of required functions and features

Relatively minimal impact on campus developers


3 will we have to give up other work

3. Will we have to give up other work?

Overall development effort not much different

-CUWA 1.5 estimated 23.8 FTE weeks

-CUWA 2.0 estimated 25.6 FTE weeks

CUWA 1.5 work requires the skill-set of four members of current IdM team

CUWA 2.0 work will require skill-set of only two members of current IdM team

CUWA 2.0 choice frees up skill set required for key projects like Active Directory, PS/STARS, Automated Provisioning, Grouper/Signet


4 what are the longer term implications

4. What are the longer-term implications?

Lower maintenance cost, from 2 FTE’s to 1

Better security

More predictable user experience

Positions us better for future enhancements to authentication and authorization services

Opportunity for open-source release


5 would an outside solution be smarter

5. Would an outside solution be smarter?

Assessment is “no” based on more than 150 hrs of research

Alternatives may offer short-term wins for IdM development team

But would have significantly higher impact on user community

Using these solutions off-the-shelf, without mods:

-we give up features we currently have (ex: POST data support)

-or we accept the same vulnerabilities we have with CUWA 1.5

Making mods to these outside solutions

-may take as much or more time as re-writing CUWA 2.0

-requires unknown level of cooperation with other institutions

-may cause entanglements and dependencies beyond our control


Summary pros and cons

Summary Pros and Cons

Webauth 1.5

Lowest short-term risk

Limited benefit

Webauth 2.0

Best long term solution

Slightly more short-term work

  • CAS

    • Great java integration

    • Most expensive for the rest of campus. Security not great

  • Stanford

    • Lowest deployment cost for Identity Management

    • Complex infrastructure and missing features


A closer look at the cas experience

A Closer look at the CAS Experience

Initial contacts with Rutgers and Indiana University

Posting to the Yale CAS mailing list

Results from:

Rutgers

Cal Poly

University of Connecticut

Indiana University

Virginia Tech

University of Hawaii

Stanford

Duke


General findings

General Findings

  • CAS has an enthusiastic following and an active developer community

  • CAS works well for institutions which have no significant authentication and authorization infrastuctures already in place

  • CAS works close to the application layer. This is fundamentally different from CUWA

  • CAS doesn’t address authorization at all

    • Cornell is ahead of most on the AuthZ front

    • Going to CAS would be a significant step backwards on AuthZ

  • The Indiana University experience is likely a good example of what would happen if we attempted to make CAS work for us:

    • Post Data support

    • GuestID and TokenID support

    • IIS and Apache mods

    • IU is now working from its own code base, rooted in CAS 2.0


  • Converting to cas

    Converting to CAS

    • We have roughly 212 services actively using CUWebAuth. 

    • Of these services 50% would be simple conversions to CAS, averaging 1 day each for application plus 2 days for training; 3 days total. 

    • Another 25% (50+ services) would be relatively easy conversions, but would need to add code to do central authorization.  Add 5 days for that; 8 days per service

    • The remaining 25% (50+ services) would be in the more difficult category.

      • some of this involves static content

      • some involves vendor integration

      • some would have special central authorization needs

      • some are currently supported by non-programmers who will need to outsource the deployment

      • some are a combination of some or all of these..

    • Time required to convert these services: unknown, but we are conservatively estimating 25 days (or roughly one FTE month per service to develop, test, deploy..)


    Initial estimate

    Initial Estimate

    • CUWebAuth 2.0

      • FTE weeks per service: 0.5 weeks or less

      • 0.5 x 212 = 106 FTE weeks

      • FTE weeks IdMgt: 25.6

      • FTE ongoing Maint: 1

    • CAS

      • FTE weeks per service: 2 weeks on average

      • 2 x 212 = 424 FTE weeks

      • FTE weeks IdMgt: 23

      • FTE ongoing Maint: 1


    Current assumptions

    Current Assumptions

    AuthZ Project Dependency

    > Permit Server replacement complete

    > I2 Grouper in production

    No significant higher priority projects tap our current (very limited) resource pool

    > Emergency Notification Service

    > Applicant Provisioning

    > Active Directory/Exchange Server deployment


    Central authorization phase 1

    Tom Parker [email protected]

    Central Authorization Phase 1

    • Transparent cutover of Permit Server to Grouper

    • New UI for service owners and application developers


    Under development

    Under Development

    Permit Shim

    Permit migration application

    Organizational namespace

    Grouper UI

    ServiceID Manager application

    User documentation and training

    Detailed test plan

    Detailed launch and back-out plan

    Load testing


    New serviceid manager application

    Joy Veronneau [email protected]

    New ServiceID Manager Application

    • What is a ServiceID?

    • People are going to be requesting keytabs to replace their srvtabs as we move to Kerberos 5

    • Needed a more automated process

    • Needed better information about who owns ServiceIDs and what they are used for

    • ServiceIDs will need to be available in the Directory for the Grouper Authorization Project (Permit server replacement.)


    Shibboleth update

    Joy Veronneau [email protected]

    Shibboleth Update

    “Shibboleth is standards-based, open source middleware software [from Internet2] which provides Web Single SignOn (SSO) across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.”


    What does shibboleth look like

    What Does Shibboleth Look Like?


    Federations

    Federations

    • Think about your ATM card and various bank federations like: NYCE, PLUS

    • They trust each other.

    • InCommon Federation: a group of 50+ Higher Education institutions (including Cornell-Ithaca) and sponsored participants (including EBSCO, Napster.)

    • InCommon uses Shibboleth as its federating software.


    Why we re interested in shibboleth

    Why we’re interested in Shibboleth:

    • (Napster used Shibboleth.)

    • We would like to eventually have a “Cornell Federation” with Ithaca, Weill and Qatar.

    • Solves other problems. (example coming up!)

    • Shibboleth fits in well with our electronic directory, CUWebLogin, and Grouper.


    Shibboleth simplified

    Shibboleth Simplified

    • Identity Provider (IdP) - protected by CUWebLogin

    • Service Provider (SP) - protects an application like the EBSCO website. Knows how to ask “Where are you from?” and then talks to your Identity Provider.

    • Both an IdP and an SP can be configured to talk to more than one Federation.


    Idm provisioning projects

    Bill Turner [email protected]

    IdM Provisioning Projects

    • Alumni NetID Creation

    • Application Changes

    • STARS Applicant Provisioning

    • Staff NetID Provisioning


    Alumni netid creation

    Alumni NetID Creation

    • Alumni NetID creation began 12/12/2006 and was completed 12/22/2006

    • 189,661 records were identified by AAD as Alumni with mailable addresses

    • 66,974 had existing NetIDs

    • 121,562 new NetIDs were created

    • Final count for mailing after deduping etc. was 188,782


    Cleanup processes

    Cleanup processes

    • Lots of work identifying and dealing with duplicate and problem records

      • And lots more to go

    • After further discussion and consideration, project sponsor decided to remove Activation Code for all active non-Alumni NetIDs


    Applications changes

    Applications changes

    • New version of WhoIAm that is Alumni-friendly

    • Retired old “CU-Connect” process

    • New NetID Management Web application implemented 2/20/2007

      • Jointly developed by IS and Identity Management

      • Owned by Identity Management

      • To be phased in for use by all


    User processes

    User processes

    • Letters went out beginning 2/16

    • NetID activation by Alumni began 2/20

      • Actual use by newly-provisioned Alumni

    • Authenticated trustee balloting began 2/20

      • Actual use by newly-provisioned Alumni


    Project timeline

    Project timeline


    Effects on campus

    Effects on campus

    • All mailable living alumni now have a NetID, an entry in the “cu.alumni” permit, and a Directory entry with type “alumni” (if not staff etc.)

    • Alumni processes for Email forwarding etc. now the same as for students and staff


    Effects on campus1

    Effects on campus

    • Still a lot more “cu-connect - directory” type individuals in the Directory

    • Elimination of “cu.alumni_directory” permit yet to be accomplished

    • Storage of Email addresses in the Directory, PS, etc. yet to be accomplished


    Pending work

    Pending work

    • Further de-duping of records

      • 1000+ records that are known duplicates

      • “cu-connect” records that are difficult to match


    Project successes

    Project Successes

    • Provisioning went quite smoothly

    • A lot of data cleaned up

    • Manual processes now automated

      • CU Connect

      • Batch NetID creation by Production Control

    • Applications updated

    • Security questions/Forgotten password utilities in place


    Stars applicant provisioning

    STARS applicant provisioning

    • Beginning in Fall 2007, applicants will be processed in PeopleSoft

    • Instead of custom provisioning in the Undergraduate Admissions self-service application, applicants will authenticate with Kerberos both to PeopleSoft self-service and to the Undergraduate Admissions self-service application


    Applicant provisioning

    Applicant provisioning

    • Applicants will be given an “ApplicantID”

    • ApplicantID will be analogous to NetID

    • The format will be “app” plus the 2-digit year for which the person is applying, followed by a period, followed by what the person’s NetID will be should they attend Cornell

    • Example: app08.wrt1


    Applicant provisioning1

    Applicant provisioning

    • ApplicantID will be a Kerberos principal

    • It will be created in the “guest KDC”

      • The “guest KDC” is somewhat of a misnomer, but it’s the Kerberos server that we use for Blackboard “guest IDs”


    Applicant provisioning2

    Applicant provisioning

    • Using the guest Kerberos server means that campus applications are not automatically opened up to applicants

      • CUWebAuth can already be configured to use the prod Kerberos and/or the guest Kerberos

      • Application owners and service providers can decide whether they want to accept applicant credentials


    Applicant provisioning3

    Applicant provisioning

    • Applicants will be in the Directory, but in their own branch

      • ou=Applicants not ou=People

      • They will not show up in existing Directory searches

      • The same schema will be used, but not fully populated

    • This is needed because PeopleSoft self-service relies on the Directory for authorization


    Applicant provisioning4

    Applicant provisioning

    • Applicants will be in a cu.applicants permit

    • This allows the standard permit checks that are built into infrastructure components such as CUWebAuth


    Applicant provisioning5

    Applicant provisioning

    • ApplicantIDs will be a less secure credential

      • ApplicantIDs and activation codes will be communicated to the end users via Email

      • ApplicantIDs can be used only for less secure information such as checklists

      • ApplicantIDs cannot be used to communicate financial or other sensitive information


    Applicant provisioning6

    Applicant provisioning

    • ApplicantID management will be very similar to NetID management

      • Activation

      • Change password

      • Set security questions

      • Reset forgotten password

    • Web application will be a clone of http://netid.cornell.edu


    Applicant provisioning7

    Applicant provisioning

    • When an applicant is accepted and pays the deposit, the NetID will be created as at present

      • NetID and activation code will be communicated via US mail

      • When the NetID is activated, the ApplicantID will be deactivated

    • All ApplicantIDs will be deleted at the end of the annual admissions cycle


    Project timeline1

    Project timeline

    • August 2007: ApplicantID management Web application in place, NetID Admin software changes to support ApplicantID creation

    • September 2007: ApplicantID creation begins with STARS go-live

      • Undergraduate Admissions self-service application Kerberized and accepts ApplicantIDs for authentication

      • PeopleSoft self-service accepts ApplicantIDs for authentication


    Staff netid provisioning

    Staff NetID provisioning

    • Beginning June 2006, NetIDs and activation codes for new staff are communicated to hiring offices via HR Online

      • Not all units use HR Online

      • Paper process of requesting an initial password still in place

    • Results have in general been good


    Staff netid provisioning1

    Staff NetID provisioning

    • Over the past year, use of HR Online has increased

    • Paper “initial password” form does not pass Audit requirements

    • HR planning to phase out paper form this Fall


    Idm campus developers meeting 6 18 07

    http://identity.cit.cornell.edu/projects/index.html


    Identity management

    Identity Management

    [email protected]


  • Login