Can You Trust Me Now? RL “Bob” Morgan (U Washington)
Grade submission as an example – worked as a paper process, using bubble sheets which got scanned. The paper is the artifact – it’s about who’s holding it. Eventually gets back to the registrar’s office, then processed by people who are supposed to do something with the signatures but don’t really have a way to verify.
Online submission process- Instructors enticed by gradebook app in LMS, users sign on to LMS with NetID. Instructor of record inserts grades, reviews, and submits.
Old process relied on physical practices and personal relationships. New process relies on integrity of LMS and its connection to student system, accuracy of authorization, reliability of NetID system in all its parts.
What assurance do we have it’s the right person submitting the grades? Not comparable to the old process which was not about the person as much as the piece of paper.
Should we use two-factor authentication? What are instructors’ practices in protecting workstations and data? Data protection policy said that if you’re dealing with personal data then 2 factor should apply. But decided not to, based on the level of data you have access to. What are peers doing, are there standards?
That’s the assurance problem statement.
Basics of identity assurance
What are the risks to applications – they need to provide services to the world, protect their stuff, not be hacked. There are other kinds of risks – bad programming, database security, etc. What is identity? From the app point of view, anything about a requesting party that can be used to make an access control or resource allocation decision. Maybe just a userid, maybe much more. Traditionally much of the data is stored within an app, which implies practices that have to be justified to whoever oversees it. Now we like to externalize services. Motivates need for formal description – what is the app trusting, how do you talk about it?
One size doesn’t fit all – apps come in different sizes and shapes. Even if we thought there was one true identity everyone should use (popular a few years ago), evidence shows you can’t do that all the time. There are things that users just won’t do – if I have to provide a whole bunch of info about myself to use an app, I might not be willing to provide it. High assurance by its nature requires more work and information from the user. We need a range of practices. Need good ways to describe them.
Elements of IdM practice – about which apps migh want assurance. Registration and identity proofing – how does the notion of the existence of a person with an address and a relationship to the institution get into the identity system in the first place? How do we know it’s true? Relies on other information coming in from the world – photo ID, who’s doing the checking. How do we create a credential for that person? (typically userID and password). How do we know the credential is in the hands of the right person. Those processes can be expensive and rely on staff to support. Authentication services – has to work well all the time. What about managing additional user info (email address, e.g.)
End up with different practices for different kinds of people. We might present a huge matrix of possibilities to apps.
Elements about IdM operators – Organizational maturity – documented procedures, leadership consistency, authority of population/orgs in question. Operations change management, security, user support, logging, privacy.
Levels of assurance – in SAML there’s an elaborate spec about how in a authentication response you can put a megabyte of data about how assurance and identity proofing was done. Most reasonable people think that needs to be simplified.
US Government leads the way – OMB 04-04 (Dec. 2003) promotes e-authentication for e-government, using external identity providers. Characterizes risks into four levels. Support those levels with standards saying what the practices for each level should be. E-Auth esablished program to evaluate IdPs. They’ve been working on revisions ever since. Hoping to issue it this year. A set of universities were evaluated five years ago.
The four levels 1 – little or no; 2 some; 3 high; 4 very high
l1 – typical internet account – no tie to real-world identity. Use email address. Do you know that it’s a person? Is the billg account on LinkedIn really Bill Gates? You get assurance that the person coming back is the same person.
l2 – standard business practice. Identify person, know who they are, refer back to real-world docs. Don’t get it right all the time, but mostly we do. Usernames and passwords
l3 exta-secure business practice – use two factor authn
l4 – if you have to ask you can’t afford it.
The government moves on…
E-auth has some problems. Funding not stable, not serving needs of agencies. Shut down March 2009.
Working with NIH to work directly with InCommon and universities. using practices consistent with CAF/800-63.
Maybe this should be the way it works – agencies working with their constituencies (doh!) GSA now has an ICAM office endorsing that approach.
InCommon fills the vacuum – InCommon IDentity Assurance. To give us enough formality to work with the agencies we want to work with. InCommon would be certifying that an entity had met the requirements – InCommon Silver.
InCommon Assurance documents
Identity Assurance Assessment Framework – describes overall approach, processes, role of IT organization and auditors.
Bronze/Silver Profiles – details of compliance elements, much taken verbatim from E-Auth CAF, also in “auditor-friendly” checklist form
Published November 2008 – a number of campuses working on it, nobody yet saying they comply.
Gov 2.0
Obama administration seeks to transform government transparency, delivery via web
A lot of effort people coming to Washington, sharing info. A lot driven by social networking like we were discussing this morning – citizen engagement. OpenID is a big thing for citizens authenticating to government – informed the GSA to make it happen.
A big tent for protocols, trust providers – ICAM creates more modular structures – not just SAML and PKI, but a process for blessing other protocols – Identity Scheme Adoption Process – hold up protocol against 800-63. “Comparability” is the principle. There’s also a Trust Framework Provider Adoption process. Documents published summer 2009. Profiles fro OpenID (level 1 only), Information Card protocols.
Who ya gonna trust? Kantara Initiative – successor to Liberty Alliance, working in many identity areas. Has industry-oriented group working on its own Assurance Framework, also parallel to CAF. Set up operational Assurance Certification process similar to InCommon. One of the big auditing houses, for example, might offer that certification as a service. Has applied to GSA to be TrustFramework Provider. InCommon could end up being a certifier in the Kantara framework. Kantara is more of the model of big business using “auditors in white coats”. InCommon is helping to shape how the rest of the world is being created.
OpenID Foundation and Information Card Foundation – newly empowered by government interest. joined together in opposition to Kantara to develop the Open Identity Framework model – allows for self-certification. Really promoted for “open government.” Used InCommon docs as starting point. Google and Yahoo are at the table.
InCommon applying to be a TFT at some point.
Assurance and Privacy
Trust framework – new section came in about privacy principles – Adquate notice about using federated authn; users must auth in; only required info is sent.
Dealing with ICAM privacy reqs – InCommon developing privacy addendum to its assurance program. Notion is that existing university policies cover, so we don’t need to adopt the technical means mentioned.
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 – student-self-service access – want to impose standards on campuses. Working to get Silver blessed for this.
What’s a campus to do? Work to comply? Some schools are doing. Doing the practice is different than complying with regs. Define its own levels/profiles? Do the four levels really meet our needs?
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 depending on hwo they signed on. But system as a whole must meet Silver system criteria.
Can we rely on existing proesses – if we can’t, can this work?
Who does the audit? – Hoping internal university audit.
Password issues – interpreting password-protection requirements is hardest technical part of compliance.
Klara Jelnikova (Duke -> Chicago) Duke’s Identity Assurance Journey
Identity Managment joint across Duke University, Duke Medicine and Duke Health System. Card Office technology part of the identity management space. Card system shared too.
Identity Assurance – Round 1
NIH InCommon pilot as a start of a structured discussion. Research faculty cahmpions InCommon bronze compliance. Held tech expo this fall – room was packed with research faculty for id management session. Other faculty viewed some aspects (like password expiration) as “Orwellian”.
Chasm? Using IdM to manage different assurance levels within a single IdM. Business needs drive higher levels. Aligned with InCommon categories. Model has been expanded for unified DU, DM, DHS, account management.
Health System Challenges – People have legitimate need for high level assurance apps but fall otuside Duke HR – contract or temp nurses or affiliated physicians. Adding Helath System credentialing system as a system of record. Non traditional apps such as shared clinical workstations. Need for PIN tracked in core IdM (with appropriate card coding. Speed of authentication (swipe and PIN versus username and password). Highly specialized apps and equipment – tough integration.
Lessons learned – having a clear busines caseis key. Incremental approach. Working on documentation towards InCommon levels. Hard to work on documentation. Health System can be a great ally as long as you can manage the complexity.
Oren Sreebny 