Multifactor Authentication in Higher Education (176173626)

7/27/2019 Multifactor Authentication in Higher Education (176173626)

http://slidepdf.com/reader/full/multifactor-authentication-in-higher-education-176173626 1/52



Multi-Factor Authentication in

Higher Education



Today’s Speakers

David Walker, Scalable Privacy Project

Brendan Bellina, University of Southern California

Paul Caskey, University of Texas System

Bryan Wooten, University of Utah

Bill Thompson, Unicon, Inc.



David Walker,Scalable Privacy

Project



What Is Multi-Factor Authentication?

● Multiple factors required during authentication

○ Something you know (e.g., passwords)

○ Something you have (e.g., tokens)

○ Something you are (biometrics)

● Each factor mitigates risks of other factors

○ Tokens mitigate the risk of password phishing

○ Passwords mitigate the risk of token theft



Examples of MFA● Token + PIN

● Password + cellphone confirmation

● Single-Factors that may be combined with others to

achieve MFA

○ One-Time Password

○ Biometric

○ Pass phrase



Why Deploy MFA?

● Improve on passwords by mitigating the risks of

phishing, etc .

○ Common goal for Google, Facebook, et al

○ Often provided as an option for end-users

● Require for specific applications

● Require as part of an assurance profile

○ Federal LoA 3 and LoA 4

○ Potential strategy for InCommon Silver (LoA 2)



The Scalable Privacy Project

● 2+ year NSTIC grant to Internet2/InCommon

● Multiple focal points

○ Promotion of multi-factor authentication (MFA)

○ Citizen-centric attributes and schema

○ Development and deployment of privacy managers

○ Introduction of anonymous credentials

● https://spaces.internet2.edu/display/scalepriv

https://spaces.internet2.edu/display/scalepriv



Promotion of MFA

● Three pilot deployments

○ Massachusetts Institute of Technology (MIT)

○ University of Texas System

○ University of Utah

● Software infrastructure

● The MFA Cohortium



Software Infrastructure

● Enhancements for Shibboleth and CAS

○ Coordinate sessions with services requiring differing

authentication strengths, including MFA

○ Partnership with the InCommon Assurance Program

for Bronze and Silver

● InCert

○ Open source client certificate management system

○ Includes device boarding



The MFA Cohortium

● ~40 institutions exploring multi-factor authentication

○ Most wondering what they should do

○ Many starting to deploy

○ A few with mature deployments

● Three subgroups

○ Business Case for MFA

○ Deployment Strategies

○ Technology and Product/Vendor Issues



Can I Use “Cohortium” in

Scrabble?Cohortium: "Group of institutions sharing their explorations, experiences, expertise, artifacts, and

overall journey", in this case of planning for and

deploying multi-factor authentication.

○ Cohort: In statistics and demography, a cohort is a

group of subjects who have shared a particular event together during a particular time span [cohort

(statistics) from Wikipedia].

○ -tium: added to noun base to create abstract noun,

"something connected with the act", could mean"act, condition, office of...".



Cohortium Work Products - 1

● The business case for multi-factor authentication

○ Alignment with institutional mission

○ Mitigation of risk

○ Costs and cost recovery

● Deployment strategies

○ Initial deployment strategies

○ Gaining community acceptance

○ Business continuity when tokens are not available



Cohortium Work Products - 2

● Technology issues

○ Evaluation criteria for MFA solutions

○ Architectural integration patterns

○ Usability

○ Accessibility

● Policy issues

○ How much security is enough?

○ FERPA and other compliance frameworks



More about the Cohortium

● The MFA Cohortium Wiki

○ https://spaces.internet2.edu/x/4AwwAg

● How to Join

○ https://spaces.internet2.edu/x/4wwwAg

https://spaces.internet2.edu/x/4wwwAg

https://spaces.internet2.edu/x/4AwwAg



January is Data Privacy Month!

Learn more at

http://www.educause.edu/dpm



Brendan Bellina,University of

Southern California



University of Southern California

Who needs access to our systems?

- 40,000 current students (45% undergraduate)

- 3,500 active faculty

- 12,000 active staff

- 6,400 sponsored affiliates (“VIPs”)

- 300 external guests (self-registered)

- 2,600+ organization/dept/class accounts

- Over 120,000 accounts



Why Considering Multi-Factor?Even Strong Passwords are insufficient to protect:

- access to protected machines

- users with elevated privileges

- applications that contain sensitive data

- application functions that require additional security

Due to:

- Phishing and poor password handling practices

- Weaknesses in account lifecycle management

- Shared accounts



General Technical Challenges- Scalability

- Distribution and management of hardware tokens

- Affordability

- Initial purchase and replacement costs

- Supportability

- Remote users, staffing requirements

- Ease of use

- It is very difficult to implement in a way that people will

not complain about.



General Policy Challenges- How to determine what users should be affected?

- How to determine what applications should be affected?

- How to determine what systems should be affected?

- How to manage the above as:

- users change roles and positions

- applications alter functionality and data

- systems alter connectivity, platform, and OS

Far, far more to this than just setting up a pilot.



Things to Consider - Alternative to password should be:

- ubiquitous

- zero cost

- easy to use

- Hardware tokens? How scalable?

- Smart phone/cell phone? If given the number.

- Personal Email? If given the address.

- Social Logins (Facebook, Twitter). If registered.



Current Implementation- Hardware tokens have been used by Information

Security, Auxiliary Services, and Hospitality for over a year.- ITS Information Security will be deploying soft tokens

(app on smart phone) to hundreds of people for PCI

compliance in the next few weeks.

- ITS Information Security will be deploying the same soft

tokens to system administrators of financial systems, the

Student Information System, and core infrastructure in the

very near future.



Future Plans- 2014 Pilot using cell/email/oAuth for Self-Service

Password Reset functionality.- CIO is very interested in pursuing multiple levels of

security based on risk, with emphasis on value and risk

mitigation.

- Determination of how applications, users, and systems

should be selected and managed will come from

Information Technology Services leadership to the USC

Information Risk Committee (proposed by the CIO).- Pilot a selected set of applications and users.

- Plan further expansion.



Paul Caskey,University of Texas

System



Driving Factors■ Phishing

■ Malware/Keystroke loggers

■ Passwords alone, in any form, have rapidly delining

utility for protecting anything from a determined

attacker.

■ Confidential data

■ Scope of access

■ Strengthening of social IDs?



Where We’re At Now

■ NSTIC MFA grant for piloting Duo Security

■ Also piloting Toopher technology (location awareness)

■ A few pilots started across 5 or 6 institutions

■ Some limited production deployments

■ Public computers

■ Remote access

■ No mass deployment yet

■ System-wide policy likely to include some MFA



Impediments to Broad Deployment

■ User convenience still rules?

■ Non-tech users?■ Password strength “denial”

■ Who owns authentication?

■ Proactive vs Reactive?

■ Rapid change of technology

■ Consumerization

■ Increasing sophistication of criminals/malware

■ Cost?

■ Technology deployment challenges

■ No cell phone, lost/forgotten tokens, etc.



Bryan Wooten,University of Utah



University of Utah Current Tech●

WEB SSO CAS○ 200+ Applications Internal and Cloud (ie Canvas)

● OpenDJ LDAP

● Shibboleth

○ External / Cloud Applications Only

● Active Directory

● Grouper (early Alpha)



Current MFA Projects●

Cisco Routers / Switches /○ TACACS - RSA

● EPIC Electronic Medical Records

○ AIX Backend Servers - DUO

● Payment Card Servers (PCI)

○ Evaluations in progress



NSTIC Challenges● UofU is only CAS pilot

● CAS Client vs Shibboleth SP

○ Many clients vs. one code base

○ Different feature set

● Funding

○ MFA Licenses vs. Development

● Add value to broader CAS community

● Collaboration

○ Unicon, UC Berkeley, UC Riverside, Evergreen College



NSTIC Use Cases / Requirements● Application configured to force all users authenticate with MFA

○ HIPAA, FERPA

● Individual Users must always authenticate with MFA

○ Users with Elevated Privileges

● Application allows either Single Factor or MFA authentication

○ Functionality determined by authentication method

● User Opt-in / Opt-out

○ Stretch goal

● Token or Mobile MFA

● Backward compatible



Bill ThompsonUnicon, Inc.



Theme: boutique → commodity■

2fa is currently boutique and custom rather thancommodity and ubiquitous.

■ moving from custom to commodity

■ experimentation and innovation supports and

complements commoditization

■ (without interesting experiments, how do you know

what is worth commoditizing?)



Licensing costs?

From the abstract:■ “More competitive licensing options for MFA, as well as

expanding MFA technologies (e.g. mobile/app/phone-

based solutions), are helping to address a significant

factor -- cost -- for deploying and supporting MFA.”



No. Complexity cost.■

Licensing cost (or other costs of 2fa tokens) is aproblem, but it’s not the problem.

■ The problem is what would you do with 2fa if you had

it?

■ Who uses what to access what, how? And how is this

experience usable enough that this actually works?

■ What problem are we solving here?



Example 1: Ryerson 2fa■

Boutique and awesome. Crafted with love.■ Ryerson-specific smartphone app based on open

source Google Authenticator.

■ Web-based second password solution for folks bereft of

smart phones.

■ Zero licensing costs to anyone (that was never the

problem)

■ Backed by Ryerson’s custom SIS services.







Boutique■ What we have here is a lovingly crafted solution that

works for Ryerson.

■ And some (open source!) starting points for your 2fa

implementation.

■ But not commoditization

■ To replicate: Just add love, sweat, thought, care,

craft, institutional policy, user education, support,

and processes. No biggie!



Who, what, what, how?■ Who should be prompted when accessing what?

■ Dunno. Ask the (custom) SIS!

■ What’s the additional authentication factor?

■ OATH TOTP as implemented by Ryerson-custom

smartphone app. Fallback on second static

password for the smartphone have-nots.

■ How is the authentication factor experienced?

■ Customizations to CAS single sign-on login.





Example 2: Evergreen:

commodity?■ Multi-factor authentication add-on for CAS 3.5

■ Free and open source software

■ https://github.com/unicon/cas-mfa



Factors are sub-flows■ Spring Web Flow sub-flows

■ Combine:

■ UI

■ Logic

■ Backing Java

■ Plugged into the regular CAS login flow

■ Modularity. Pluggability. Commoditization.



Who authenticates how to what?■ Specified just-in-time via a request parameter, set by

the relying party

■ Very CAS-like. Lightweight. Adhoc.



What’s the authentication factor?■ It happens to be one-time passwords generated by

proprietary tokens and validated via RADIUS against a

proprietary token management server

■ But it’s just a CAS AuthenticationHandler.

■ Could have been another AuthenticationHandler. Like,

say, the developed-for-Ryerson OATH TOPT

AuthenticationHandler.

■ Pluggable.



How is it experienced?■ CAS sub-flow.

■ So, as part of single sign-on

■ CAS remembers fulfilled authentication methods within

the single sign-on session. Requires any given method

at most once.

■ That’s an experience decision. Think about it.

Boutique.



Moving towards commoditization■ You can do a lot with JIT decision-making by the relying

party about authentication method

■ But that’s not the same thing as LOA

■ And more generally you may want to centralize

configuration. Service registry?

■ Methods are just AuthenticationHandlers

■ With experiences via Spring Web Flow sub-flows

■ Commoditization.



Open Two Factor ■ https://www.youtube.com/watch?v=0LOTu5jylwg

■ Free and open source software

■ Self-service user binding to OATH tokens

https://www.youtube.com/watch?v=0LOTu5jylwg



Commoditization■ More and better open source starting points

■ Next versions of CAS and of Shibboleth IdP modeling

more complexity and nuance in the core product

■ Local implementation becomes more feasible



Documents

Multifactor Authentication in Higher Education (176173626)