1. Identity Assurance: Can You Trust Me Now? RL "Bob" Morgan University of Washington/Internet2/InCommon CSG, San Diego, January 2010

3. CSG Identity Assurance Workshop, Jan 2010 3 Topics Basics Assurance elements Assurance infrastructure Campus issues Various nagging questions

4. CSG Identity Assurance Workshop, Jan 2010 4 A moral tale: grade submission at UW longtime paper process focused on... paper course bubble sheets distributed to departments eventually get to instructors, or someone who fills them out, and signs them someone, usually dept staff, gets them to dropbox in registrar's office registrar's staff processes, scans, nags about late sheets,...

5. CSG Identity Assurance Workshop, Jan 2010 5 Online submission process Instructors enticed by gradebook app in LMS Users sign on to LMS with UW NetID Instructor of record inserts grades into course page, reviews, clicks submit Registrar's office nags about late submissions... Many obvious improvements, but some new risks too

6. CSG Identity Assurance Workshop, Jan 2010 6

7. 7 Relying on new stuff Old process relied on longtime practices, personal relationships, physical stuff New process relies instead on: Integrity of LMS, and its connection to SIS Accuracy of authorization to course pages Reliability of UW NetID system in all its parts: signon system, password protection, client system security, user behavior, incident handling,...

8. CSG Identity Assurance Workshop, Jan 2010 8 Raising questions... Should we use two-factor authentication? extra cost, hard to use for some faculty hard to integrate into LMS (it has been working fine with single-factor only) how do our data-protection policies apply? are other schools using two-factor for this? are there regulations that tell us what to do? is someone developing standards? Do we know who the TAs are? more generally, who has what rights on a course

9. CSG Identity Assurance Workshop, Jan 2010 9

10. 10 Basics of identity assurance Starting point is risks to apps/services apps seek to manage risks cost-effectively identity risks are only one class of risks What is identity? from app point of view, it is anything about a requesting party on which access decisions can be made maybe just a userid, maybe lots of other info (group, role, usage history, location, etc) When identity is externalized service, app seeks formal guarantees, i.e. assurance

11. CSG Identity Assurance Workshop, Jan 2010 11 One size doesn't fit all Apps have many kinds of resources to protect, different budgets to do so can't afford "the best" identity practices always High-assurance practices are intrusive to users showing identity docs, coming to help desk, two-factor, etc; so even if affordable, users will revolt Hence, a range of useful identity management practices balancing costs and risks and agreements between identity management systems and apps on what the options are

12. CSG Identity Assurance Workshop, Jan 2010 12 Elements of IdM practice... about which apps might want assurance Registration and identity proofing creation of record in IdM system for a person external validation of personal information obtaining/verifying contact information Credential assignment e.g., username and password establishment so authentication acts can be tied to registered person also includes re-establishment as needed (aka password reset)

13. CSG Identity Assurance Workshop, Jan 2010 13 Elements of IdM practice Authentication services technology by which users establish authenticated sessions with applications wide range of technologies with cost/usability/effectiveness/risk tradeoffs User information management information often used by apps for decisions various kinds of identifiers roles, groups, privileges, etc.

14. CSG Identity Assurance Workshop, Jan 2010 14 Elements about IdM operators Organizational maturity documented procedures authority over population/orgs in question Operations change-management and security practices helpdesk and user support logging and records management user privacy management

15. CSG Identity Assurance Workshop, Jan 2010 15 "Levels of Assurance" Several sets of criteria by which apps might rate IdM systems and many options within each set, e.g. many different authentication technologies, proofing methods IdM systems serve many apps expensive to tailor option sets to serve each one apps are not the idM experts; they want to rely on "acceptable practices" from IdM services Better for all if standard sets of practices can be defined, roughly consistent cost/risk-wise

16. CSG Identity Assurance Workshop, Jan 2010 16

17. CSG Identity Assurance Workshop, Jan 2010 17 USG leads the way OMB 04-04, December 2003 promotes e-authentication for e-government, using external identity providers describes four levels of risk and corresponding levels of identity assurance, directs NIST to develop tech standards "important to match LoA against cost and burden of solution" chartered US E-Authentication program run by GSA, to be "US government federation"

18. CSG Identity Assurance Workshop, Jan 2010 18 E-Auth and NIST 800-63 E-Auth established program to evaluate IdPs aka "credential service providers" based on the four levels NIST developed "Electronic Authentication Guideline", SP 800-63, in 2004 technical guidance on identity proofing and authentication technology, specifying the four levels E-Auth incorporated this into its Credential Assessment Framework several universities evaluated under it, in 2005

19. CSG Identity Assurance Workshop, Jan 2010 19 The Four Levels OMB 04-04 says: (1) "little or no", (2) "some", (3) "high", (4) "very high" in more useful terms: L1: typical Internet account  no tie to real-world identity, just repeatable authentication L2: standard business practice  person identified, good password practices L3: extra-secure business practice  small number of users, two-factor authn L4: if you have to ask, you can't afford it

20. CSG Identity Assurance Workshop, Jan 2010 20

21. CSG Identity Assurance Workshop, Jan 2010 21 The USG moves on... E-Auth has some problems funding not stable, not serving needs of agencies... shut down March 2009 Agencies succeed in federation on their own e.g. NIH working with InCommon Federation, using technologies/practices consistent with CAF/800-63 GSA reorganizes, promotes this approach new ICAM office centralizes identity work agencies OK if practices "comparable" InCommon Federation fills the vacuum...

22. CSG Identity Assurance Workshop, Jan 2010 22 InCommon Identity Assurance "our version" of E-Auth CAF improved, a little HE-specific supports InCommon certifying IdPs as compliant with assurance profiles consistent with E-Auth levels 1 and 2 motivated initially by interest in working with higher- sensitivity apps at NIH and NSF 2 documents: framework and profiles will be supported by InC program processes, fees, support, etc. taking applications in 2010...

23. CSG Identity Assurance Workshop, Jan 2010 23 InCommon Assurance documents Identity Assurance Assessment Framework describes overall approach, processes role of IT organization, auditors Bronze/Silver Profiles details of compliance elements much taken verbatim from E-Auth CAF also in "auditor-friendly" checklist form published November 2008 accepted by USG for use with agencies? well...

24. CSG Identity Assurance Workshop, Jan 2010 24 Gov 2.0 Obama administration seeks to transform government transparency, delivery via web new federal CIO is big fan of Web 2.0, social networking, encourages agencies to adopt new techniques social networking depends on identity, is closely associated with OpenID OpenID now supported by major consumer services: Google, Live, Yahoo, Facebook, Paypal, etc, with hundreds of millions of users mandate from CIO to support OpenID

25. CSG Identity Assurance Workshop, Jan 2010 25

26. CSG Identity Assurance Workshop, Jan 2010 26 A big tent for protocols, trust providers ICAM creates more modular structures not just SAML and PKI, but process for blessing other identity protocols, aka "Identity Scheme Adoption" not just GSA evaluating IdPs, but a process for blessing other entities to create trust criteria and do certifications, aka "Trust Framework Provider Adoption", mostly copied from CAF/800-63 "comparability" is the principle documents published summer 2009  profiles for OpenID (Level 1 only), Information Card protocols some organizations rev up to be TFPs...

27. CSG Identity Assurance Workshop, Jan 2010 27

28. CSG Identity Assurance Workshop, Jan 2010 28 Who ya gonna trust? Kantara Initiative successor to Liberty Alliance, working in many identity areas has had industry-oriented group working on its own Assurance Framework, also parallel to CAF, for several years; docs published mid-2009 setting up operational Assurance Certification process quite similar to InCommon, taking applications now has applied to GSA to be Trust Framework Provider may be useful resource for InCommon going forward

29. CSG Identity Assurance Workshop, Jan 2010 29 Who ya gonna trust? (2) OpenID Foundation and Information Card Foundation industry groups promoting protocol adoption newly empowered by government interest developed "Open Identity Framework" model, promoting it in various venues; used InCommon docs as starting point channeling interests of many commercial providers: Google, Yahoo, Equifax, others vision to "add the trust to OpenID" applying to GSA to be TFP

30. CSG Identity Assurance Workshop, Jan 2010 30 Who ya gonna trust? (3) InCommon applying to be TFP... at some point Formal approval necessary... at some point some uncertainty re SAML protocol a little privacy issue...

31. CSG Identity Assurance Workshop, Jan 2010 31 Assurance and privacy TFP document is mostly traditional assurance material, but adds new privacy criteria motivated by privacy concerns of, e.g., people using Google accounts to access government services New requirements on IdPs: Adequate notice: users must be notified about use of federated authn Opt-in: users must opt in before info is sent Minimalism: only required info is sent not clear how these apply to business-to-gov situations

32. CSG Identity Assurance Workshop, Jan 2010 32 Dealing with ICAM privacy reqs InCommon developing privacy addendum to its assurance program notion is that universities (a) have privacy policies that say only minimal info is sent, (b) do inform users about use of federated signon with third parties, and (c) participation in business/academic processes constitutes opt-in university IdPs would assert they do these things seeking comments on this soon... likely a useful part of federation program going forward, even with non-USG apps

33. CSG Identity Assurance Workshop, Jan 2010 33 Assurance on the wire: NIH and InC working with NIH on federation since... researchers from ~25 universities accessing CTSA since 2008, several other apps level what? agreement to consider all InCommon members to be Level 1, for now working on pilot for eRA research-admin app, requires Level 2, working out tech details now will converge with some campuses being approved for Silver in... 2010? will converge with InCommon being approved by ICAM as TFP in... 2010?

34. CSG Identity Assurance Workshop, Jan 2010 34 Assurance standards in action New FERPA rules 2009 suggest that student data protection requires "good" authentication practice, but how good is good? working to get InCommon Silver blessed for this National Student Clearinghouse new student-self-service access, raises authentication quality issues, they want to impose standards on campuses working to get Silver blessed for this also for access to Meteor student loan system

35. CSG Identity Assurance Workshop, Jan 2010 35

36. CSG Identity Assurance Workshop, Jan 2010 36 What's a campus to do? Work to comply with standard (e.g. InC Silver)? maybe; some campuses are doing this, such as CIC is "achieving compliance" the same as "making a better campus IAM system"? up to a point... useful for engaging communities: CISO, audit, medical, research, finance, etc, about IAM importance/reqs define its own levels/profiles? do the four levels really meet your (our) needs? some think there may be use in a 1.5, or some non- numeric label: "useful for applying to university" e.g.

37. CSG Identity Assurance Workshop, Jan 2010 37

38. CSG Identity Assurance Workshop, Jan 2010 38 What means compliance? To meet Silver do all users have to be Silver? no: it is fine for one IdM system to have user entries at many different levels one user might be at different levels at different times depending on how they signed on (e.g. two-factor, or location) but system as a whole must meet Silver system criteria lifecycle considerations of moving between levels; need to label entries with assurance-related data? e.g. "process used to identity-proof"? but still: lots of people all at once, or one at a time?

39. CSG Identity Assurance Workshop, Jan 2010 39 Can we rely on existing processes? If we can't... can this work at scale? IAF permits orgs to use "existing relationships" Employees  federal I-9 should be universal, and good enough, for id proofing, but account setup? Students  student lifecycle starting very early now, does this compromise, or imply explicit L1->L2 transition? Alum/Affiliates/Armies of Gray  many looking at aligning sponsorship with formal levels Remote proofing an issue across all populations

40. CSG Identity Assurance Workshop, Jan 2010 40

41. CSG Identity Assurance Workshop, Jan 2010 41 Who does the audit? InCommon permits university internal audit if sufficiently independent from IT organization and if auditor meets qualifications: knowledgeable about IdM issues and InC framework, etc. need for training/engagement with university audit community Could be that industry auditors fill the need e.g. those approved by Kantara program Can audits we already do serve the purpose?

42. CSG Identity Assurance Workshop, Jan 2010 42 Password issues Interpreting password-protection requirements is hardest technical part of compliance model assumes service set up just for federation, with only one store and one service interface, but this is unrealistic in any organization of any size e.g., if passwords are synced with Google or Windows Live, is that a non-compliant exposure? how about LDAP authentication used with many campus/external applications? how about password reset??? who will make these judgment calls?

43. CSG Identity Assurance Workshop, Jan 2010 43