idm campus developers meeting 6/18/07

IdM Campus Developers Meeting 6/18/07

IntroductionCUWebAuth 2.0 and K4-K5 UpgradeCentral AuthZ Phase 1ServiceID ManagerShibbolethIdM Provisioning Projects

OIT/CIT Security, Identity Management Team

Opening Remarks

Fast-track projectsEmergency mass notification supportActive Directory for Exchange

Andrea Beesing [email protected]

Fast-track projects

Launched at President Skorton’s request within the past few months/weeksImportant for different reasons Health and safety Cornell’s endowment

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

Emergency Mass Notification Support

Charge to the Cornell Emergency Management CommitteeMechanism for notifying community members by voicemail, email and cell phoneChanges to WhoIAm by August 15 for students, affiliates, sponsored exceptionsChanges to self-service front end for contact info for faculty and staff in early fall from WhoIAm to Employee EssentialsNew attributes in directory (all private)Personal cell phone attribute will have privacy selection

Active Directory for Exchange

Very narrow scope with attention to scalability for futureIntegration 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-K5Current schedule keying on PS Student Records roll-out in Mar ’08 to reduce customer resource requirementsIssues with current code base used for web single sign-on argue for reassessing our approach to the Kerberos 5-only releaseTimeline for retirement of Kerberos 4 now three to six months out

Tom Parker [email protected]

Opportunity IdentifiedCan 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)?

Feb Mar Apr May Jun

Kerberos 5 Upgrade: Where Are We Now?

Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan

Campu

s Roll

out C

omple

te

K4 Shu

tdow

n

PS Stu

dent

Lau

nch

You A

re H

ere

Discretionary migration window

6/14

Iden

tity M

anag

emen

t Roll

out

2007 2008

Feb Mar Apr May Jun

Where Are We Now?


Campu

s Roll

out C

omple

te

K4 Shu

tdow

n

PS Stu

dent

Lau

nch

•Code review (4 code bases)


2007 2008

6/14

Iden

tity M

anag

emen

t Roll

out

You A

re H

ere

Feb Mar Apr May Jun

Where Are We Now?


Campu

s Roll

out C

omple

te

K4 Shu

tdow

n

PS Stu

dent

Lau

nch

•Code review (4 code bases)•Security audit (new vulnerabilities)


2007 2008

6/14

Iden

tity M

anag

emen

t Roll

out

You A

re H

ere

Feb Mar Apr May Jun

Where Are We Now?


Campu

s Roll

out C

omple

te

K4 Shu

tdow

n

PS Stu

dent

Lau

nch

•Code review (4 code bases)•Security audit (new vulnerabilities)•Rollout requirements

(PS launch)


2007 2008

6/14

Iden

tity M

anag

emen

t Roll

out

You A

re H

ere

Feb Mar Apr May Jun

Where Are We Now?


PS Stu

dent

Lau

nch

Campu

s Roll

out C

omple

te

K4 Shu

tdow

n



(PS launch)

2007 2008

6/14

Iden

tity M

anag

emen

t Roll

out

You A

re H

ere

Feb Mar Apr May Jun

Where Are We Now?


PS Stu

dent

Lau

nch

K4 Shu

tdow

n



(PS launch)

2007 2008

Campu

s Roll

out C

omple

te

6/14

Iden

tity M

anag

emen

t Roll

out

You A

re H

ere

Feb Mar Apr May Jun

Where Are We Now?


2007 2008

PS Stu

dent

Lau

nch

K4 Shu

tdow

n



(PS launch)

Campu

s Roll

out C

omple

te

6/14

Iden

tity M

anag

emen

t Roll

out

You A

re H

ere

Feb Mar Apr May Jun

Where Are We Now?


PS Stu

dent

Lau

nch

K4 Shu

tdow

n

window of opportunity



(PS launch)

2007 2008

Campu

s Roll

out C

omple

te

You A

re H

ere

6/14

Iden

tity M

anag

emen

t Roll

out

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

CUWA/CUWL 1.5 – Attempt to fix what we haveCUWA/CUWL 2.0 – Re-build it the way it should beMove to an outside solution

- Yale CAS- Stanford WebAuth- CoSign

Service goals consideredImpact of change on campus developer community Minimal work required to migrate to new versions Support for required functionality

Predictability of user experienceLong-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 servicesEfficient use of scarce CIT resources

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)

Feb Mar Apr May Jun

Recommendation


Ide

PS Stu

dent

Lau

nch

Develo

p CUW

ebAut

h 2.

0

•CUWebAuth 2.0 Implementation•Late Fall 2007 deployment•Maintain migration window


2007 2008

K4 Shu

tdow

n

Campu

s Roll

out C

omple

te

Iden

tity M

anag

emen

t Roll

out

Five Questions from SRM

1. Why not go with CUWA 1.5?2. What do we get by writing CUWA

2.0?3. Will we have to give up other work?4. What are the longer-term

implications?5. Would an outside solution be

smarter?

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?

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 protocolMore scalable web single sign-on solutionNo loss of required functions and featuresRelatively minimal impact on campus developers

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 teamCUWA 2.0 work will require skill-set of only two members of current IdM teamCUWA 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?

Lower maintenance cost, from 2 FTE’s to 1Better securityMore predictable user experiencePositions us better for future enhancements to authentication and authorization servicesOpportunity for open-source release

5. Would an outside solution be smarter?

Assessment is “no” based on more than 150 hrs of researchAlternatives may offer short-term wins for IdM development teamBut would have significantly higher impact on user communityUsing 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

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

Initial contacts with Rutgers and Indiana UniversityPosting to the Yale CAS mailing listResults from:

Rutgers Cal Poly University of Connecticut Indiana University Virginia Tech University of Hawaii Stanford Duke

General FindingsCAS has an enthusiastic following and an active developer communityCAS works well for institutions which have no significant authentication and authorization infrastuctures already in placeCAS 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 CASWe 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 serviceThe 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

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

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

Transparent cutover of Permit Server to GrouperNew UI for service owners and application developers

Central Authorization Phase 1

Tom Parker [email protected]

Under DevelopmentPermit ShimPermit migration applicationOrganizational namespaceGrouper UIServiceID Manager applicationUser documentation and trainingDetailed test planDetailed launch and back-out planLoad testing

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

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.”

Joy Veronneau [email protected]

What Does Shibboleth Look Like?

FederationsThink about your ATM card and various bank federations like: NYCE, PLUSThey 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:

(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 SimplifiedIdentity Provider (IdP) - protected by CUWebLoginService 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

Alumni NetID CreationApplication ChangesSTARS Applicant ProvisioningStaff NetID Provisioning

Bill Turner [email protected]

Alumni NetID CreationAlumni NetID creation began 12/12/2006 and was completed 12/22/2006189,661 records were identified by AAD as Alumni with mailable addresses66,974 had existing NetIDs121,562 new NetIDs were createdFinal count for mailing after deduping etc. was 188,782

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

New version of WhoIAm that is Alumni-friendlyRetired old “CU-Connect” processNew 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

Letters went out beginning 2/16NetID 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

3/5/2006 3/31/2007

4/1/2006 5/1/2006 6/1/2006 7/1/2006 8/1/2006 9/1/2006 10/1/2006 11/1/2006 12/1/2006 1/1/2007 2/1/2007 3/1/2007

3/06 - 10/06Planning

10/06 - 1/07Design and Implementation

1/07 - 2/07Batch

& mailings

2/07 - 3/07Activations

& voting

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 campus

Still a lot more “cu-connect - directory” type individuals in the DirectoryElimination of “cu.alumni_directory” permit yet to be accomplishedStorage of Email addresses in the Directory, PS, etc. yet to be accomplished

Pending work

Further de-duping of records 1000+ records that are known duplicates “cu-connect” records that are difficult to

match

Project Successes

Provisioning went quite smoothlyA lot of data cleaned upManual processes now automated CU Connect Batch NetID creation by Production Control

Applications updatedSecurity questions/Forgotten password utilities in place

STARS applicant provisioning

Beginning in Fall 2007, applicants will be processed in PeopleSoftInstead 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

Applicants will be given an “ApplicantID”ApplicantID will be analogous to NetIDThe 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 CornellExample: app08.wrt1


ApplicantID will be a Kerberos principalIt 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”


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


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


Applicants will be in a cu.applicants permitThis allows the standard permit checks that are built into infrastructure components such as CUWebAuth


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


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


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 timelineAugust 2007: ApplicantID management Web application in place, NetID Admin software changes to support ApplicantID creationSeptember 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

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 provisioning

Over the past year, use of HR Online has increasedPaper “initial password” form does not pass Audit requirementsHR planning to phase out paper form this Fall

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

Identity Management

[email protected]

idm campus developers meeting 6/18/07

Documents

current code base

ps student records roll

k4 shutdown schedule

idm campus developers

idm work

k4k5current schedule

track projectslaunched

support modelplease