A Closer Look at CAS

SRM Update

Identity Management TeamOIT/CIT Security

May 14, 2007

Review: 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

Review: 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 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

Feb Mar Apr May Jun

Review: IdM Recommendation

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

9/1

Iden

tity M

anag

emen

t Roll

out

PS Stu

dent

Lau

nch

Develo

p CUW

ebAut

h 2.

0

•CUWebAuth 2.0 Implementation•Fall 2007 deployment•Increase migration window

Discretionary migration window

2007 2008

K4 Shu

tdow

n

Campu

s Roll

out C

omple

te

Early Adopters

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. Would an outside solution be

smarter?5. What are the longer-term

implications?

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. Would an outside solution be smarter?

Assessment is “no” based on more than 100 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

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

In Review: 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 IUPosting 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 expample 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

UConn, Matt Smith: “Glad I could help -- allow me to muddy the waters a bit, though: our original spec required that the SSO/ISO solution support multiple backends for authentication, and CAS fits the bill *very* well (and was really the only solution to do so). However, we have since decided to try to move to a pure "Kerberized" (MIT v5 KDC) environment. CAS still fits very well, but solutions like CoSign or WebAuth may have been simpler, plus would have given us a few extra Kerberos bonuses, such as SPNEGO and back-channel ticket delegation. Pure Kerberos is a bit of a Holy Grail for us (particularly where certain NTLM-only Microsoft products come into play), but for environments that are already Kerberized, CoSign or WebAuth may offer more than CAS, without the Java overhead (Tomcat or another servlet container)….”Stanford, Heather Flanagan: “…frankly, we have a good group supporting WebAuth at Stanford so there is no compelling reason at this time to change to anything else.  We don't need to make more work for ourselves when what we has meets our needs AND is supported.  I just came to Stanford from Duke, and there the look at CAS was a bit more thorough, tho' at the time they also decided to hold off.  In that case, Duke's webauth program (also written in house) was no longer supported by anyone, which made CAS a bit more compelling.  Still, with a lack of resources and a bigger learning curve, as well as the amount of change required by the campus community if they abandoned webauth, no change was made there either. Duke, Shilen Patel: “We haven't moved towards deploying CAS, but instead are more interested with Shibboleth.  We have Shibboleth deployed at Duke, but it cannot replace Duke Webauth right now since Shibboleth does not have many of the functionalities we require.  We are looking more towards being involved in the Shibboleth community to hopefully get some of our required functionalities integrated with Shibboleth. ..”

Comments of Particular Interest

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

Questions?

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

Identity Management

aadssupport@cornell.edu