To Authentication and BeyondAn update on C&C’s authentication-related middleware services

UW Computing Support Staff MeetingDecember 16, 2004

http://www.washington.edu/computing/infra/

Topics

• Authentication in Context– within identity management– toward our communities of service

• Authentication Infrastructure Services– UW NetID, Kerberos, SecurID (for people)– UW Services CA (for servers and services)– Pubcookie– Shibboleth

• Authorization Infrastructure Services– UW Groups– ASTRA

Identity Management?

• “Identity management is the set of business processes, and a supporting infrastructure, for the creation, maintenance, and use of digital identities.”

- The Burton Group (market research firm specializing in enterprise IT infrastructure)

• How does this compare with, and fit into, our conception of C&C’s (middleware) infrastructure services?

Basic functions of IdM

Reflect Data of interest from SoR

Join Match identity across SoR

Credential NetID, password, SecurID

Manage Affil/Groups Basic/flat AuthZ info

Manage Privileges Structured AuthZ info

Provision For apps w/ attitude

Deliver Get AuthZ info to app

Authenticate Check identity claims

Authorize Make allow/deny decision

Log Track usage for audit

Original source: Keith Hazelton, Univ of Wisconsin

IdM functions & big picture

Reflect

Join

Credential

Deliver

(AuthN)

Provision

AuthZ

Mng Grps

Mng Priv

Log

Source: Keith Hazelton, Univ of Wisconsin;

Tom Barton, Univ of Chicago

Many communities to serve

• Central Services– C&C maintained, administrative services

• Local Community, that’s you!– enabling departmental services

• Federated Communities– external partnerships, virtual organizations– some 3rd-party hosted applications– this is you too!

C&C’s infrastructure services need to serve the unique requirements of each community.

Another view…

Image source: Keith Hazelton, Univ of Wisconsin

Definitions

• Basic:– Authentication says who you are.– Authorization says what you can do.

• Something geekier:– Authentication is the establishment of a security

context based on evaluation of evidence.– Authorization is configuration and operation of

systems so actions in support of organizational goals are permitted and other actions are prohibited.

UW NetIDs

• Primary digital credential for online services at the UW

• About 225,000 active UW NetIDs• 3-8 characters in length• They’re a service to users

– single id, single password, maybe even some single sign-on

• Get in the game!– namespace first, authentication if you can

UW NetID passwords

• Uniform policy for all passwords

• 8 characters or longer

• Must pass strength test

• Regular changing recommended

• Not externally provisioned

UW NetID types

• Personal– belongs to a single person for life

• Shared/supplemental– group id; actions not easily audited

• Reserved– system account

• Tremporary– use by one person, temporarily

• Other– kerberos host principals, @u mailing list names

UW NetID populations

• All employees in UW payroll– including HMC, HHMI, affiliate faculty, UWRP

retirees

• All UW students– including matriculated, non-matriculated, UW

extension, UWT and UWB; and applicants too

• Some Clinicians– e.g., UW Medical Center, from Cancer Care

Alliance, Children’s hospital, UW Physicians network

UW NetID populations…

• C&C Information additions– including sponsored and supplemental ids,

temporary ids (guest wireless)

• UW Alumni ID holders– e.g., graduates in the alumni db, UW donors

• and others too, e.g.– some Digital Learning Commons users– Cascadia Community College students and

employees (very soon)

Kerberos infrastructure

• UW’s Enterprise Authentication Service• Fundamental credential store• MIT Kerberos V (version 1.3.5)• Do departments need service principals

and host keys for departmental systems?– If so, we haven’t seen the demand– If so, we can create a storefront, similar to the

UW CA and Weblogin registration services, based on UW DNS ownership info

SecurID infrastructure

• High-assurance authentication service based on SecurID technology

• Provides “two-factor” authentication– something you know + something you have

• Use is primarily administrative systems

• About 5,600 SecurIDs in use

• About $60 per device

• Use is not likely to expand much

UW Services CA

• Issues digital certificates for– Traditional web server uses– Systems and services using SSL/TLS

• 767 certificates in use

• What best practices are emerging in departments to trust the UW CA?

• Support calls? Very few (our perception, yours too?)

UW CA growth

Pubcookie/Weblogin

• Purpose– Normalize web-based user authentication– Deliver UW NetID authentication info to apps

• Participation– Registration based on UW DNS ownership– Requires trusted SSL server certificate– Over 790 participating servers

Pubcookie 3.2.0

• New functionality– POST-based cross-dns-domain messaging– Custom login messages– Keyserver supports wildcard certs – Keyserver supports Subject Alt Names

• Release info– Beta 1 release available now (Apache only)– Beta 2 release available tomorrow(ish)

• Will be the recommended version for UW!

Custom login messages

Example: ESS login

Shibboleth

• Purpose– An architecture, project, and software

components for standards-based federated authentication and attribute exchange.

– Like Pubcookie on steroids (mostly SAML standard)

• User support profile– Should be similar to Pubcookie…– Except now there are Attribute Release

Policies (ARPs) involved

Shibboleth…

• UW is a Shibboleth “Identity Provider” (IdP)– Running Shibboleth IdP 1.2– Production service status with first real Service

Provider (CreateHope.com, e-academy.com)– User authentication by Pubcookie/weblogin– User attributes from UW EDS Person directory– Participating in InCommon (R&E) federation;

“authenticate locally, act federally”– UW NetID credential services undergoing USG E-

Authentication Program credential assessment

What can our Shib IdP deliver?

• Answer: in general, user attributes of broad cross-community interest:– eduPersonPrincipalName (based on UW NetID)– eduPersonAffiliation (faculty, student, staff,

alum, member, affiliate, employee)– eduPersonEntitlement– eduPersonTargetedID– uwPersonAffiliation– uwEmployeeID

• Qualifier: but only if an Attribute Release Policy allows release to a given service provider.

Authority management

• Why externalize authorization?– To save development time and cost

• ASTRA is built and ready for use• UW Groups are coming

– To distribute management of authorization• If you want to hand it off to others, you can• Put business people in charge of managing authority

– To leverage well designed and maintained solutions– To use standard UIs for managing authorization data– To increase visibility of access control policy– To improve policy adherence and auditing

UW Groups

• UW EDS Groups directory under development– Institutional– Departmental– Adhoc

• Pairing with new UW Authorization module (for Apache, known as mod_uwa)

• Infrastructure alone, not enough…• Need to study institutional triggers and indicators

for departmental-level group creation

ASTRA Mission

ASTRA provides Web-based management of authority for UW administrative applications. ASTRA removes systems administrators and operations teams from the business of implementing authorization requests. Instead, using ASTRA, the appropriate decision makers within the University community can easily distribute authority to the appropriate people.

ASTRA authority elements example

By authority of Rupert B., authorizor

Nathan Dors, user

within Financial Desktop, application

in the role of Designee, role

may inquire about budget information

level of access

for budget 012345 access restriction

from 12-16-04 to 01-01-06. condition

ASTRA authority elements example…

ASTRA UI: initial Authorizor view

ASTRA authority elements example…

ASTRA UI: defining new authorization

ASTRA authority elements example…

ASTRA UI: adding new authorization

ASTRA authority elements example…

ASTRA UI: new authorization added

ASTRA authority elements example…

<?xml version="1.0" encoding="utf-16"?><authz xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <authCollection> <auth> <party uwNetid="dors" regid="23DA66146A7D11D5A4AE0004AC494FFE" /> <environment code="eval" /> <privilege code="FINDesktop" /> <role code="Designee" codeDescription="Designee" /> <action code="Inquiry" /> <spanOfControlCollection> <spanOfControl type="DesigneeBgtCd" code="012345” codeDescription="" /> </spanOfControlCollection> </auth> </authCollection></authz>

ASTRA API: attributes received in XML view

ASTRA: Clients in Production

• SAGE• Ariba System Administration• E-Procurement• Online Work Leave System• Affirmative Action• Department Tools for Time Schedule• FS-Works• Employee Self-Service

ASTRA: Clients in Development

• Financial Desktop

• Space Inventory Management System

• Online Accident Reporting System

• Year End Tax Form

• VEBA

• PUC Maintenance Application

• Vendor Payment System

ASTRA: Clients in Discussion

• MyGradProgram

• Online Payroll Update System

• UW Project Tracker

• Cognos Tools (Data Warehouse)

• Keynes Applications (PAS, FIN, etc.)

ASTRA: Usage Since LaunchASTRA Consuming Applications

Number of Users, Authorizers, and Delegators By Month

0

1000

2000

3000

4000

5000

6000

7000

8000

Jan-03 Mar-03 May-03Jul-03

Sep-03 Nov-03 Jan-04 Mar-04 May-04Jul-04

Sep-04 Nov-04

Delegators

Authorizers

Users

To Authentication and Beyond…How far out do C&C’s various infrastructure services reach?

Kerberos

Pubcookie

Shibboleth

UW Groups

ASTRA

Answer: the necessary roadmaps are being defined now.

Image source: Keith Hazelton, Univ of Wisconsin