Identity Management Topics
SAS ITMC Meeting
July 26, 2007
Tom Parker
Project Manager
Identity Management Team
OIT/CIT Security Office
Joy Veronneau
Technical Lead
Identity Management Team
OIT/CIT Security Office
Identity Management Topics
Tom Parker
Project Manager
Identity Management Team
OIT/CIT Security Office
Joy Veronneau
Technical Lead
Identity Management Team
OIT/CIT Security Office
Identity Management Topics
Tom Parker
Project Manager
Identity Management Team
OIT/CIT Security Office
Joy Veronneau
Technical Lead
Identity Management Team
OIT/CIT Security Office
Identity Management Topics
Kerberos upgrade and CUWebAuth work
 Central Authorization System




Internet2 Grouper and Permit Server
replacement
Internet2 Signet and privilege management
Internet2 Shibboleth
Why move from K4 to K5




Cornell’s authentication system is based on MIT
Kerberos and CUWebAuth
MIT discontinued support for Kerberos 4
- Computing power has caught up with the
encryption method used in Kerberos 4
- Kerberos 4 vulnerable to off-line attacks
Kerberos 5 addresses off-line attacks and has
stronger encryption
MIT will continue to support Kerberos 5
Kerberos 5 Upgrade: The Initial Plan
Dec Jan Feb
Mar Apr May Jun
Jul
Aug Sep Oct
2007
Nov Dec Jan Feb
2008
Discretionary
migration window
Mar Apr
May Jun
Where Are We Now?
•Code review (4 code bases)
Dec Jan Feb
Mar Apr May Jun
Jul
Aug Sep Oct
2007
Nov Dec Jan Feb
2008
Discretionary
migration window
Mar Apr
May Jun
Where Are We Now?
•Code review (4 code bases)
•Security audit (new vulnerabilities)
Dec Jan Feb
Mar Apr May Jun
Jul
Aug Sep Oct
2007
Nov Dec Jan Feb
2008
Discretionary
migration window
Mar Apr
May Jun
Where Are We Now?
•Code review (4 code bases)
•Security audit (new vulnerabilities)
•Rollout requirements
(PS launch)
Dec Jan Feb
Mar Apr May Jun
Jul
Aug Sep Oct
2007
Nov Dec Jan Feb
2008
Discretionary
migration window
Mar Apr
May Jun
Where Are We Now?
•Code review (4 code bases)
•Security audit (new vulnerabilities)
•Rollout requirements
(PS launch)
Dec Jan Feb
Mar Apr May Jun
Jul
Aug Sep Oct
2007
Nov Dec Jan Feb
2008
Discretionary
migration window
Mar Apr
May Jun
Where Are We Now?
•Code review (4 code bases)
•Security audit (new vulnerabilities)
•Rollout requirements
(PS launch)
Dec Jan Feb
Mar Apr May Jun
Jul
Aug Sep Oct
2007
Nov Dec Jan Feb
2008
Discretionary
migration window
Mar Apr
May Jun
Where Are We Now?
•Code review (4 code bases)
•Security audit (new vulnerabilities)
•Rollout requirements
(PS launch)
Dec Jan Feb
2007
Mar Apr May Jun
Jul
Aug Sep Oct
Nov Dec Jan Feb
Mar Apr
2008
Discretionary
migration window
May Jun
Where Are We Now?
•Code review (4 code bases)
•Security audit (new vulnerabilities)
window of opportunity
•Rollout requirements
(PS launch)
Dec Jan Feb
2007
Mar Apr May Jun
Jul
Aug Sep Oct
Nov Dec Jan Feb
Mar Apr
2008
Discretionary
migration window
May Jun
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)?

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
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

Impact of change on campus developer community




Predictability of user experience
Long-term viability of CIT’s authentication solution for webbased services





Minimal work required to migrate to new versions
Support for required functionality
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
Results of our investigation



High-level design for a rewrite of CUWA and
CUWL
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)
Our Recommendation to SRM
•We develop CUWebAuth 2.0
•Late Fall 2007 deployment
•Maintain migration window
Dec Jan Feb
2007
Mar Apr May Jun
Jul
Aug Sep Oct
Nov Dec Jan Feb
Mar Apr
2008
Discretionary
migration window
May Jun
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?

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 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?

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?
Lower maintenance cost, 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?




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
Other solutions reviewed: Stanford WebAuth, CoSign,
PubCookie, Yale CAS, the list goes on..
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




CAS works close to the application layer. This is
fundamentally different from CUWA.
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 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
Initial Estimate


We have roughly 212 services actively using
CUWebAuth.
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 and STARS project work
> Active Directory/Exchange Server deployment
Hey, what about Sidecar?
Cornell University
Central Authorization
Replacing a System that (sorta) Works
Cornell’s Permit System
Also a permit
Central Authorization at Cornell is
generically handled by a Permit Server
 Developed at Cornell and has been in use
for over a decade
 The Permit Server maps groups of NetIDs
to “permits”
 A permit is just a string token, such as
“cit.staff” or “cu.student”

It’s a List-based System
Also a permit
On the Permit Server, we might see
something like this table:
PERMIT NAME
LIST OF NETIDs
cit.staff
bbb1, cjm5 , jtp5, rd29 , jv11, …
cu.employee
aba1, cjm5 , jtp5 , rd29 , jv11, …
cu.student
cit.update.eudora
fbc4, gv455, rb553, tgm4, …
fbc4, gv455, jtp5, rd29 , jv11, …
How are Permits Obtained?



Whenever a new NetID is created
during the hiring process (staff)
Whenever a new NetID is created
during the the admissions process
(students)
Service owners wishing to restrict a
specialized service may request a
permit for their application



They are given tools to manage their
permit
They decide when to assign or revoke a
permit for a particular user
That is, if they remember to do so…
Permit Server Stats







Cornell has approximately 175,000 active NetIDs.
There are over 800 permits but only about 325
are active.
Those active permits have about 500,000
memberships.
On our busiest day, there are about 375,000
queries to the permit server.
On that day the busiest minute has about 1,650
queries.
Creation of new permits generally limited to sys
admins
Not used for personal groups like mailing lists
Current Limitations





AdminUI designed for the 1990s
No limitations, expirations
Limited delegation features
Users can’t see what permits they have
Permits can’t do negative authorizations



For example, an institution may want to offer a service to all
active students but only within the United States due to
export regulations..
No self-enrollment options
Anyone (or anything) can be included in a Permit
List


Also a permit
No checks for misspellings or formatting errors
Regardless of whether a permit is centrally or locally
owned, the permit is maintained manually
Internet2* Authorization Initiatives
Grouper (group-based membership)
 Signet (privileges and limitations)
 Shibboleth (open source
implementation to support interinstitutional sharing of web resources
subject to access controls)

* Internet2 is a consortium being led by 207 universities working in partnership with industry
and government to develop and deploy advanced network applications and technologies
Cornell’s Project Mgt. Methodology








Bringing some corporate rigor to campus but in a
way that remains appropriate to a university
environment
Requirements
Use Cases
Communication Plans
Project Planning
Migration strategies
Thorough testing
Rollout Planning
Lots of Up-Front Document Work
Project Charters
Initiation Plans
Project Planning
Understanding the Requirements
http://identity.cit.cornell.edu/authz/CAP/documents.html
Steering Committee, a Key Component
Department
Role
Stakeholder
Office of the Univ. Registrar
Director, Technical Services
Rob Bandler
Johnson School/JGSM
Chief Technology Officer
Kevin Baradet
CIT Information Systems
IT Architect
Steve Barrett
CIT Customer Svcs & Marketing
Manager, Help Desk/Contact Center
JP Brannan
CIT Systems & Operations
Technical Lead/Manager
Laurie Collinsworth
CIT Adv Tech & Architectures
Technical Lead/Manager
Ron DiNapoli
College of Ag & Life Science
IT Security Officer, CALS
Daniel Elswit
HR Info Systems & Records Adm
Director, HR Records Administration
Lyman Flahive
Campus Facilities Services
Associate Director of IT
Debra Howell
Digital Library Info Tech
Director, Library Systems
Pete Hoyt
CIT Information Systems
Manager, Peoplesoft Applications
Jolene Scaglione
School of Hotel Administration
Sr. Web Systems Analyst
Jason Woodward
Grouper Overview




A grouper
Manages groups, not privileges (however a group can be
authorized to do something…)
Privileges and limitations can be added to a group later
via Signet…
Grouper gets its information on NetIDs from the
directory and maintains group information in an Oracle
database. (can use other DBs but that’s more
complicated at this stage and we like Oracle anyway…)
Group information can in turn be pushed out to other
repositories (such as a directory...)
Main development effort at: University of Chicago, University of Bristol
Some Grouper Features that
our Permit Server Doesn’t Have










Distributed group management
Composite groups - groups whose membership is
determined by the union, intersection, or relative
complement of two other groups
Traceback of indirect membership
A future version of Grouper will include aging of groups and
memberships
Self enrollment and unenrollment
Users can easily see what groups they are members of
Users can create and manage their own groups
Uses existing repositories for subject sources
Clearer ownership hence more accountability
Better administration tools
Why Grouper for CU?
Grouper’s LDAP provisioning connector
plays nicely with our campus-wide
electronic directory.
 For other in-house applications we can
use a web-service to obtain group
membership information directly from
Grouper.
 A big one for us: Grouper supports a
delegated model of control

Initial Investigations






Fit-Gap analysis between
Permit Server System
and Grouper
Early versions of
Grouper running in test
Built and tested scripts
to migrate permits into
Grouper
Modified UI for Cornell
look and feel
Emphasis on discovery
and use cases
Requirements gathering
Requirements,
some easy, some not…
Requirements,
some easy, some not…
Major Discussion Points

Defining a namespace


Migration strategy


Of 30 Requirements-gathering meetings, eight
were devoted to defining the namespace
How would we roll out a new campus-wide
system without causing undue interruption to
current services (or for that matter, any
interruption whatsoever..)
Query mechanisms and LDAP security
Do you REALLY want to hear more about the namespace?
Our Migration Strategy

Phased approach



Staged rollout of new features



Phase One: Permit Server replacement (I2 Grouper)
Phase Two: Privilege Management (I2 Signet)
New features come later
Incl. addition of automatically provisioned groups
Making the Permit Server replacement as
transparent to users as possible


Application administrators can switch to native Grouper
at their convenience (if they don’t take *too* long maybe a little over a year)
Builds credibility
Transparent Cutover (Current view)


Transparent cutover of Permit Server to Grouper
System owners and application developers migrate at their
convenience
- We’re building a shim
which is actually just
an emulator
- Runs on same server and
port as permitd
- Understands Cornell’s
Stateless Server
protocol (cussp)
- Translates cussp queries
and updates into
Grouper API calls
- Translates Grouper
messages into cussp
- Applications talking to the
Permit Server won’t
know the difference
Transparent Cutover (Cutover view)


Transparent cutover of Permit Server to Grouper
System owners and application developers migrate at their
convenience
- We’re building a shim
which is actually just
an emulator
- Runs on same server and
port as permitd
- Understands Cornell’s
Stateless Server
protocol (cussp)
- Translates cussp queries
and updates into
Grouper API calls
- Translates Grouper
messages into cussp
- Applications talking to the
Permit Server won’t
know the difference
Transparent Cutover (Cutover view)


Transparent cutover of Permit Server to Grouper
System owners and application developers migrate at their
convenience
- We’re building a shim
which is actually just
an emulator
- Runs on same server and
port as permitd
- Understands Cornell’s
Stateless Server
protocol (cussp)
- Translates cussp queries
and updates into
Grouper API calls
- Translates Grouper
messages into cussp
- Applications talking to the
Permit Server won’t
know the difference
Our Current Timeline
Service owner testing with Grouper complete
Grouper development work complete
Permit Server replacement
(you are here)
‘07
Oct Nov Dec Jan Feb Mar Apr May Jun
Signet available
for testing?
‘08
Jul
Aug Sep Oct Nov Dec Jan Feb Mar
Signet Overview
•
•
•
•
•
Central repository and toolkit for privilege information...
Management analysts define privileges in Signet based on
previously defined policy decisions and then specify the
relevant set of permissions to go with them…
Signet has a Web-based UI where users assign privileges
and delegate authority across all areas for which they have
authority…
Signet internally maps assigned privileges into systemspecific terms needed by applications…
Privileges are exported into applications and infrastructure
services using the appropriate notification mechanisms (email, xml, webmethods, etc…)
Main development effort at: Stanford University
View privileges assigned to yourself
Adding a privilege
Shibboleth Overview
•
•
•
Provides a framework for shared trust
among institutions within the higher
education community.
Supports inter-institutional sharing of web
resources subject to access controls.
Access controls = Authentication &
Authorization based on attributes in the
electronic directory and/or grouper.
Main development effort at: Ohio State University, Brown, others
Federations
A group of institutions that agrees to trust
the credentials issued by the other
members.
 Sort of like how your ATM card works at
many banks.

Federation
InCommon Federation


“InCommon eliminates the need for researchers,
students, and educators to maintain multiple,
password-protected accounts. Online service
providers no longer build and manage account
provisioning systems. InCommon uses innovative
Shibboleth® authentication and authorization systems
to enable cost-effective, privacy-preserving
collaboration among its community of participants.”
http://www.incommonfederation.org/
InCommon Federation (more)
Cornell was one of the first higher
education institutions to join InCommon.
 InCommon now has 42 higher ed
members plus 16 vendors.

Current Shibboleth Activities




Past: Napster initial sign-on.
Shibboleth Identity Provider running in
production, hope to have fully configured for
production by the end of the summer.
Internet2 Wiki - participants of Internet2 working
groups use Shibboleth to log onto their Wikis.
Testing - we are currently working with the
library and testing shibbolized online journal
websites. (Improves licensed access from offcampus.)
Try EBSCO!

search.ebscohost.com/Login.aspx?authtype=
Resume
Demo-mania
Future Possibility:
A Cornell Federation

Ithaca, Weill, Qatar, ?
I2 Overview Maps Nicely to CU
Separates the management of the policy, business rules, and groups from the technical system…
http://identity.cit.cornell.edu/authz/CAP/index.html
What’s up with Sidecar?

What is Sidecar?
Sidecar is a program written at Cornell. It extends Kerberos protection to
online services that don’t have Kerberos built in.

Why is Sidecar going away?
Sidecar was tightly coupled to Kerberos 4 which is being retired. A review
of the SideCar architecture as well as the proliferation of NATs has shown
that a similar solution for Kerberos 5 would not have acceptable
functionality or security.

When will this happen?
With the retirement of K4, currently scheduled for May-June ‘08

What is the new key that I see in the system tray?
There will be a new key in the system tray. It is a reminder that your
workstation is logged into Kerberos. Current plan is to call it Kerberos
Viewer

There’s an updated FAQ
www.cit.cornell.edu/services/identity/kerberos/NEWabout.html

Whom do I contact if I have more questions?
aadssupport@cornell.edu
Now, where were we?
Defining a Namespace

Grouper will likely handle many different types of
groups.




Some groups will be used to make authorization
decisions
Some may be used for non-authorization activities such
as generating email lists and calendaring.
Grouper organized with “groups” and “stems”
When someone requests that a new group or
stem be created, we will need a process for
defining


where in the Grouper name-space the new stem or
group should be placed
what it should be named.
Our Namespace Strategy



Define a basic name-space of stems in which new
groups can be created so that as soon as we
switch from using the Permit Server to using
Grouper, we will be ready to create new groups.
Designate one or more people from each unit as
the “owner” or “stem administrator” of their
unit’s name-space.
In this way, we push authority to the
departmental units and each unit can decide how
they want to administer their Grouper stem.
Multiple Views of Delegated Authority

HR View of Delegated Authority




Fiscal Responsibility View(s)






College, Department, Program, etc.
Statutory vs. endowed
Project-based (crosses all of the above)
Research View(s)





Role-based: Fiscal Officer, Account Manager, Account Supervisor
Org Hierarchies: Responsibility Centers, Divisions, Departments, Units
Account-based: Chart of Accounts, Account, Sub-Account, Object Codes, Project
Codes, etc.
Academic View(s)


Division Department, Unit, Job, Position,
Also Role, Project, or other notions of responsibility
Matrixed & non-matrixed
Closely related to, sometimes the same as, Academic view(s)
Based on Funding Source or…
Based on Signature Authority
Or Project-based
Issues For All



Delegation, Matrixing, Effective-dating (time boxing), etc.
Resolution of orthogonal views (cross-walking multiple Orgs)
Base the multiple views on administered data in enterprise sources
Research Unit Reference Chart

Office of Institutional Planning







Structure designed to provide a view of delegated
authority at the organizational entity level from the
Board of Trustees view
Currently updated once a year (every Spring)
Willing to maintain this if users sign up to the idea
RURC has 48 Units
Decent representation (ITMC)
Makes sense because the structure below Unit
Name is political not logical, and therefore
unfathomable…
Affiliates (have their own tree)
So, for example
So, for example
48 RURC Units
So, for example
48 RURC Units
about 12 of these
So, for example
HR nests its own
org structure here
So, for example
HR nests its own
org structure here
OK, where were we?