Notarized Federated Identity Management for Web Services
Michael T. Goodrich Roberto Tamassia Danfeng Yao

Outline
Introduction to federated identity management (FIM)
Notarized federated identity management model and protocol
STMS and its application in notarized FIM
Identity theft and proposed countermeasure

Motivation
Digital identity management (DIM)
To protect sensitive personal information in on-line transactions
Users tend to choose weak passwords
As the number of passwords to remember increases
Single sign-on (SSO) and federated identity management
A user logs in only once to a site, then is automatically authenticated
Cookie-based SSO approach (used by Microsoft Passport)
Does not support cross-domain single sign-on
Approach using cryptographic-enabled assertions
Secure Assertion Markup Language (SAML)
SSO and FIM
Provider model in SAML
Specially designed for general cross-domain single sign-on
Identity Provider (IdP)
IdP is the system that asserts information about a subject
Service Provider (SeP)
SeP is the system that relies on the information supplied to it by the identity provider
Relying party
Used in Liberty Alliance Federated Identity Management for single sign-on

Identity Federation
Websites of different admin domains need to trust each other’s access control verdicts
Circle of trust
Issues
How to securely maintain the identity federation when members may leave or join the circle of trust?
How to provide separation of IdP and SeP for the privacy protection of the user?
These questions have not been extensively studied
Existing SSO solutions assume pre-established trust relationship among providers
IdP and SeP communicate to each other during SSO process

Notarized Federated Identity Management
We introduce a trusted third-party, called notary server
The notary information of an assertion provides its trustworthiness
Distributed implementation of the notarized federated identity management framework using STMS
We also present a robust authentication protocol that is resilient against identity theft attacks, using identity-based encryption

Notarization
Notary server
Third party trusted by identity providers and service providers
Notarizes assertions submitted by identity providers
Answers queries on notarized assertions asked by the service providers
Prevents direct communication between the identity provider and the service provider
Notarized assertion
Generated by identity provider
Authenticated by notary server
Trusted by service provider
Security Requirements
Security
A polynomial-time adversary cannot forge a valid notarized assertion
Secrecy
Notarized assertion should not leak sensitive information of a user to unauthorized parties, including the notary server
Accountability
Identity providers should be held accountable for the assertions that they generate; and for any unauthorized information disclosure about the user
Overview of Notarized FIM
Protocol Design Challenges
How to protect the identity of the user from the service provider?
How to blind the content of an assertion from the notary server?
How to unblind by the service provider?
How to hold the identity provider accountable for unauthorized disclosure?
Our solution uses lightweight crypto primitives
hash function
XOR
symmetric encryption
digital signature
Implementation of Notarized FIM Protocol
Two public parameters P1, P2
The user and SeP compute a session_ID N
XOR each party’ s random string
The user requests IdP to generate assertions
Signed request to IdP for accountability
IdP blinds an assertion
Computes the hashed_ID h = Hash(N, P1)
Generates an assertion S using h for index
Computes the blinding factor K = Hash(N, P2)
Encrypts S with K using a symmetric encryption scheme
Blinded assertion is called S’
IdP submits an assertion to the notary server
Sign S’ with its private key
Notary server stores S’ , and stores the signature for accountability

Implementation of the notarized FIM protocol (Cont’ d)
The user queries for an assertion of a hashed_ID
Computes the hashed_ID h = Hash(N, P1)
Queries the notary server for assertions of h
Notary server notarizes an assertion
Retrieves the blinded assertion S’
Signature approach: Signs S’ with its private key
STMS approach: computes the proof for S’
The user unblinds and verifies an assertion
The user verifies the notary information
Computes the blinding factor K = Hash(N, P2)
Decrypts S’ with K and obtains S
Detect unauthorized information disclosure
The service provider unblinds and verifies the assertion
Privacy and Accountability
Notary server realization: STMS
The Secure Transaction Management System [Goodrich, Tamassia et al.] implements an authenticated dictionary
STMS in Notarized FIM
Outline of the talk
Introduction to federated ID
Provider model in SAML
Notarized federated identity management model and protocol
Identity theft and countermeasure

An authentication protocol robust against identity theft
Identity theft causes
Private information insecurely stored and entered
On credit card company’ s computers, in DMV’ s cabinets, in your bank, in your trash can
How to proactively control the release of your private information?
Secure storage
Prevent dumpster diving
Safe disclosure
Prevent shoulder surfing
With minimal changes to current financial and administrative infrastructure
Existing approaches
Centralized processing
Heavy-weight Zero-knowledge proofs
Our approach
To design a lightweight authentication protocol using identity-based encryption

Related work
Anonymous credentials [Camenisch Lysyanskaya 01] [Camenisch Herreweghen 02]
Federated ID management models [Camenisch et al 05] [Bhargav-Spantzel Squicciarini Bertino 05] [Pfitzmann Waidner 03]
Web service framework [Bonatti Samarati 02]
Identity theft detection [van Oorschot Stubblebine 05]
Identity-based encryption [Boneh Franklin 01]
SAML [OASIS], WS-Federation [IBM et al]
Conclusions
Notarized federated identity management is a solution for establishing trust in web services
Notary server provides an anchor of trust
Notarized FIM protocol provides accountability, privacy, and secrecy for participants
IBE-based credentials and exchanges hold promises for identity theft solutions
Acknowledgements
David Croston at IAM Technology, Inc

Generations of the model

Instructions for First Time Single Sign On Users

Go to HYPERLINK “https://sso.tamu.edu” sso.tamu.edu . The screen will look like this:

First time SSO users select the “New Employees – Set up your password” link
Enter your UIN and SSN and click “Next”. (If you do not know your UIN, please contact HR at 254-968-9128)
Enter your Date of Birth and click “Next.”
Enter your ADLOC and click “Next.” (If you do not know your ADLOC, please contact HR at 254-968-9128)
Enter your email address and click next. (This is for notification purposes and does NOT have to be a Tarleton email account)
Select a “Secret Question” and enter your “Secret Answer.” Be sure you can remember this answer exactly later. It is case sensitive. Then click “Next.”
Create your password by entering and re-entering the password you choose. This password is also case sensitive.
Click ”Next.”
Read the User Agreement. Type in your UIN and click “Agree.”
From the SSO Menu, you may choose HRConnect, LeaveTraq, TrainTraq, iBenefits or TimeTraq.

Single Sign-On
Doug Randall, III

Presentation materials available at HYPERLINK “http://csdirect.iii.com/ppt/iug2007-j12-singlesignon.zip” http://csdirect.iii.com/ppt/iug2007-j12-singlesignon.zip [CSDirect username and password required]

Single Sign-On allows OPAC and WAM to participate in institutional single sign-on, users can sign in with institutional id just once. Uses institution’s central authentication [which OHSU doesn’t have]

If user has already signed onto participating system on campus, user never sees login screen for library access.

LDAP – same credentials for all systems but have to log into each one. Single sign-on requires only one login.

Makes multiple systems behave like one. Other systems know you’re signed on.

How does it work?
Starts with introducing a single sign-on service for institution, usually with a few key participating systems (web mail and portal usually first). If there’s no single sign-on initiative underway, there’s little the library can do.

Lots of different single sign-on systems, including homegrown ones.

Innovative uses Apache web server as common ground for integration. Uses a separate Apache server trusted by Millennium.

IT usually provides central server with access to usernames and passwords + software for distributed sign-on server. They also usually provide instructions and software for other systems to hook in.

Single sign-on not strongly driven by standards. There are several popular products plus some others.

III sets up Apache server and works with IT to implement.

How do we do it?
Be sure single sign-on initiative is in place on campus, and it’s the appropriate time for the library to join
Load and maintain common ID field in patron records
Talk to III sales consultant

Apache
Very popular and extensible
Each SSO method has a way to work with Apache

They’ve worked with:
Sun Access Manager
IBM Tivoli
CAS (Central Authentication Services)
Shibboleth
Pubcookie (U of Washington)
Arizona State University system: ASU local, ASU-Rite (PERL-based)
Michigan State University local system – Sentinal (CAS-derived)

These schools have used single sign-on for awhile:
Arizona State University
University of Washington
University of Scranton
Yale Law School

Getting going
Bringing in new server
To user, looks just like web OPAC but with different authentication
2 server names; one uses SSO; other one has native authentication if needed
Usually SSO gets name of existing catalog server. Staff users pointed to renamed server.

No authentication required for public pages. When accessing private pages: With LDAP, Millennium prompts for authentication, then looks up elsewhere.

Can still serve non-SSO users by accessing other server. They have to connect to other name [so we’d have to offer 2 links and differentiate between them].

Identifier doesn’t have to be a particular tag (e.g. unique ID) but it does have to be indexed.

Can have scope creep, e.g. updating patron data in real time, other kinds of integration with IT.

SSO vs. LDAP
Many institutions start with LDAP as stepping stone. These are separate products, not exchangeable.

For community borrowers, need to think about how to present alternative link to users.

Shibboleth
Primary focus – a “federated” authentication method
As an idealized implementation of a local SSO
Single sign-on across institutions. Visitors can use credentials from home.
Institutions have own Web Initial Sign-on
With Shibboleth, local university should never need to know anything about visitor as an individual in order to give visitor rights.
User clicks visitor link which goes to local university’s Shibboleth system
User chooses her university when asked
User transferred transparently to home system to authenticate
After sign-on, referred back to local with token that indicates she’s a student
Local system then grants rights appropriate for visiting student

Some institutions use Shibboleth as local SSO system. Framework allows that, but it shouldn’t be confused with interinstitutional authentication for which Shibboleth standard was designed.

Most of what web OPAC and WAM do are targeted to individual rather than group identity as communicated by Shibboleth.

Group identity more relevant for WAM -> group access rights.

Q & A
Only username (or common identifier) needs to be in patron record—NOT password. Millennium never even handles the password. Authentication done through campus single sign-on service.

Patron record expiration, other patron record stuff/functionality doesn’t change at all. SSO only deals with how you prove your association with your patron record.

Multiple patron records with same identifier: SSO considers this an error.

Just expanding SSO to include INNReach. Campuses that use Shibboleth locally would be able to authenticate to INNReach. But no Shibboleth authentication for INNReach now (i.e. INNReach system would refer back Shibboleth-style).

With SSO for INNReach, sign-on would be valid for INNReach too; wouldn’t be prompted again.

Self-check would work as before, using native authentication. LDAP would also continue to work as before.

Pverify screen – needs to be adjusted for LDAP (split screen—one side for campus credentials and other side for barcode). For SSO, don’t use pverify.

Single Sign-On – p. PAGE 3

You can set up and/or change your personal data on-line, no forms to fill out, no having to get signatures, no running to College Hall. Do it yourself on-line, anytime!

PAYROLL DATA
Set up/Change Direct Deposit Information
Form W-4 Employee’s Withholding Allowance Certificate**
Form W-2 Wage & Tax Statement
Wages: Year-to-Date Totals
Pay Stubs
Total Compensation Report
PERSONAL DATA (Edit/Update My Personal/Address/Phone Information Tab)
Email Address
Address: Home & Work
Phone Numbers
Privacy Code
Much More…

Logon Instructions to Single Sign On:
1. Open up your Internet Explorer.
2. Go to HYPERLINK “https://sso.tamu.edu/logon.aspx” sso.tamu.edu/logon.aspx
3. You should get the BCS Single Sign On main page.
If you are new to this website go to “New Employees set up your password”
Then you will need your UIN number, ADLOC and birth date.
UIN: A university assigned number unique to you. It can be obtained from the Payroll Department.
ADLOC: Administrative Location-This is a number assigned to the department that you work in. It also can be obtained from the Payroll Department.
Birth date: Your birth date must be entered in MM/DD/YYYY format.
4. Once you are logged on to the Single Sign On site you can go to:
Time Traq (bi-weekly payroll)
Leavetraq (benefits-eligible employees only)
HRConnect – click on “Payroll Data” or “Personal Data” to access the items listed above.

Payroll Department 361-593-3701, 3706, 3900, 3006, 3906

**Employment of Foreign Nationals may require additional forms, contact the Payroll Office

TAMUK Confidential January 2006 PAYROLL-05

Using Technology to Bridge the Chasm of Quality in Healthcare
Facts Driving SDCMS Foundation Concerns
Medical bills = #1 cause of personal bankruptcy in the U.S
U.S. has 45 million uninsured and 40 million underinsured
U.S. spends 1.5-3X more per capita as countries with universal healthcare and yet the outcomes are no better
Healthplans collectively profited $4 billion last year
Patient are shouldering more of the costs of healthcare with deductibles and copays increasing & benefits decreasing
Plans are dropping out of non-profitable markets.
Corporate corruption / Obscene executive salaries
Medical errors have not decreased despite cost increase
VA-like bidding would yield Medicare savings of $1 billion/yr
On average, 30% of premiums are not spent on patient care
SUMMARY OF FOUNDATION PRIORITIES

Improve access to quality medical care
Increase the quality of health care
Improve the health of San Diego County residents
Improve patient safety and reduce medical errors
Improve the coordination and timeliness of care
Improve access to all information necessary to make the best decisions for patients at the point of care
Improve health literacy
Help ALL physicians in the county achieve these goals
Physician Goals for Technology

Improve quality, service, and safety of medical care
Increase the efficiency of workflow
Secure single sign on tool to import ALL data to the point of care in an easy to read integrated format
Clinical guidelines and decision support
Continuing education
Patient risk assessment
Community continuity of care records & registries
Automated patient reminders
Eligibility/Benefits/Claims verification
e-Rx: eliminate handwriting error & adverse reactions
Maintain privacy and confidentiality

Barriers to MD Adoption of Technology
Cost: Most of the Savings Accrue to the Healthplans
History of false starts
Time: Physicians are swamped with regulations (HIPAA)
Lack of standards and interoperability (HL-7)
Privacy and Security: Fear of profiling
Stakeholder commitment: Silo mentality & Competition
Healthcare industry in general is slow to change

Physicians are technophiles and recognize the value of Technology in Patient Safety and Quality Improvement

HIPAA Health Insurance Portability and Accountability Act
Administrative Simplification
Common interchange structure
Standard employer/provider identifier
Electronic signature with specific transactions
Data transmission for benefits/claims

Information Privacy
Rights of individuals to records
Authorized uses and disclosures of information
Requires identity authentication of requestor/provider of health records

SureScripts = single portal to all SD Pharmacies Increases the efficiency, quality and safety of prescribing
Based in Alexandria,VA
Formed in August 2001
Formed by:
NACDS
NCPA
Strategic industry alliance to:
Promote true electronic connectivity between physicians and pharmacies
Enable widespread prescribing connectivity (local and national)
Reduce medical errors
Current System Plagued by Serious Quality and Patient Safety Problems
Patient safety
*1.5% to 4.0% of Rx’ s have errors with potential for serious patient risk
Quality of care
*1.1 billion scripts never filled
* Patient satisfaction issues
Potential Savings: $ 2 billion / yr
Impact on productivity
*Physician time:1 hour per day
*Pharmacy: 4 hours per day

Illegible handwriting
Phone tag and fax tag
Patient waiting in the pharmacy

Predictors of Health
Racial +/- Ethnic Group
Income
Education Level
Literacy
Income
Employment status
Age
Geographic Location of Home

Consequences of Poor Health Literacy
Lack of compliance with medical regimen including missed appointments
Medication errors and medication noncompliance
Late diagnosis
Limited preventive care
Malpractice suits

Physicians agree that one of their most important tasks is PATIENT EDUCATION
HOWEVER
more than half of our patients are unable to understand
PHYSICIAN COMMUNICATION