1. Preparing For An InCommon Silver Audit – Lessons From the First Phase
Mary Dunker (Virginia Tech), Dedra Chamberlin (UC Berkeley), Jacob Farmer (Indiana University), Doreen Meyer (UC Davis)

2. An Introduction to InCommon Silver
Doreen Meyer, UC Davis
A brief description of InCommon Silver and UC Davis’s approach to working with it

3. Copyright Statement
Copyright Doreen Meyer, This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

4. What’s the problem?
Increasing need for online relationships between educational institutions, their account holders, Federal agencies, and other educational institutions
How can we streamline and secure the identity acquisition, authentication, and authorization processes that are part of these relationships?
How can we exchange appropriate information about users and resources, enabling collaborations and transactions and furthering the research missions of our institutions?

5. What is the InCommon Framework?
The InCommon Federation uses coordinated policy, technology, and business practices to establish a baseline on which to exchange identity information between Identity Providers and Service Providers.
Common goal is to mitigate risk of unauthorized access, authentication error, or credential misuse, decreasing risk of exposure of identities and sensitive data.

6. Why Now?
Universities
Gov. and Nonprofit Lab., Research Centers, Agencies
Sponsored Partners
American University
Argonne National Laboratory
Absolute Software, Inc.
Arizona State University
Energy Sciences Network
ALEKS Corporation
Augsberg College
Fermi National Accelerator Laboratory
Alexander Street Press
Baylor School of Medicine
Lawrence Berkeley Nat. Lab.
Apple – iTunes U
InCommon Federation, part of Internet2, is the recognized leader. Many participants at bronze level. (sample to the right).
Silver profile will be ready ‘soon’.
Meeting the Silver profile standards will take time.
Participants include 202 universities, 8 labs/Federal agencies, and 72 sponsored partners

7. InCommon In Action at University of California, Berkeley and Davis campuses
Potential Service Providers
Service Providers
UC campus Identity Providers
At Your Service UC Travel (Connexxus)
Learning Mgmt. System
Service Provider Determining whether a subject is eligible to gain access to a resource or service. The authorization decision is made by the service provider and is based on the attributes provided by the identity provider.
Identity Provider registration, identity proofing, credential issuance, verification Verification (via a user ID and password) that a subject is associated with an electronic identifier
Subject staff or faculty member at UC
A UCD or UCB account holder (subject)

8. InCommon Framework Is Based On Federal Guidelines
Federal Guidelines include
NIST Special Publication
Level of Assurance 2 (LOA2) as defined in OMB and FIPS 199.
LOA2: “On balance, confidence exists that the asserted identity is accurate”.

9. InCommon Identity Assurance Program
Identity Assurance Functional Areas
Business, Policy, and Operational Factors 4.2.1
Identity Proofing 4.2.2
Electronic Credential Technology 4.2.3
Credential Issuance 4.2.4
Authentication Events 4.2.5
Identity Information Management 4.2.6
Identity Assertion Content 4.2.7
Technical Environment 4.2.8
Based on two documents
Identity Assurance Assessment Framework (1.1)
Identity Assurance Profiles Bronze and Silver (1.1)
Eight functional areas to investigate

10. First Steps at UC Davis
Who will use this service? (all staff and faculty for use with UC Federation called UCTrust Basic )
Who will sponsor the first steps? (Vice Provost/CIO for IT)
What are the gaps between UCD’s identity management infrastructure and the InCommon Silver profile?
The analysis involves technology, policy, and processes
Local
University Standards
InCommon Silver
Standards

11. Sample Finding from Gap Analysis: Technical Environment (4.2.8)
Major effort
Minor effort
Complete
Purpose: Resist potential technical threats that might result in false assertions of identity
Gap
Who
Type
Effort
Inventory internal IdP systems for any communications outside of IST infrastructure, and confirm that any such communications are compliant with NIST §8.1.1 IT
Documen-tation .

12. InCommon Resources at http://incommon.org
Case Studies - learn what has worked for others ( ITunesU)
Collaboration Groups – focus on the issues that are of most value to your institution
CAMP – learn how to get started
Toolkits – use well-developed materials to state your case
Incommon Identity Assurance Program
Also CIC InCommon Silver Project – Phase 1 report

14. Framing the Standards
Jacob Farmer (Indiana University)

15. Copyright Statement
Copyright Jacob Farmer, This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

16. NIST Special Publication 800-63

17. CIO Council

18. How does a standard become a Standard?
Source:

19. Trust Framework Provider Adoption Process (TFPAP)
A way to leverage existing credentials for Federal Purposes
TFPAP evaluates non-Federal Government identity solutions and allows them to be functionally equivalent to the Federal Government Levels of Assurance.
More details:

20. How does the process work?
InCommon drafts the Identity Assurance Profile and the Identity Assurance Assessment Framework
TFPAP evaluates the documents and determines if they are equivalent to the NIST LoA
When approved, InCommon can begin certifying sites

21. The bottom line?
InCommon’s ability to make changes to Bronze and Silver is tied to the TFPAP process
This is good and bad news

23. Identity Proofing Case Study:UC Berkeley
Dedra Chamberlin (UC Berkeley)

24. Copyright Statement
Copyright Dedra Chamberlin, This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

25. How do we know if a person is who they say they are?
Cannot rely on self-asserted information only
LoA2 requires in-person identity vetting and review of valid current Government Photo ID

26. When is ID Vetted? For employees: For students:
Upon hire – the I-9 process
Sometimes upon credential issuance
For students:
Usually never
Unless they are hired as employees – see above

27. The Registration Authority (RA) vs. the Identity Provider (IdP)
The RA officially establishes the relationship between a given person and the institution. This is typically the HR department
The Identity Provider issues identity assertions to Service Providers and typically manages the institutions Identity Management Systems

28. Maintaining the Chain of Trust between the RA and the IdP
In many cases, the RA vets identity through the I-9, but does not issue an employee’s digital credential
The digital credential is often issued by the IdP
How does the IdP know that the person receiving the credential is the same person who was hired?
The IdP can ask the employee to self-assert private information that was entered into the HR system of record upon hire. Will this meet InCommon Silver standards?
The IdP can require a renewed in-person vetting

29. UC Berkeley’s CalNet Deputy Program
Over 300 trained departmental deputies
Deputies confirm an employee can provide a unique identifier from the HR system (Employee ID) and then vets the new employee’s identity in person, reviewing a person’s government ID
Deputies then issue the new employee a token which can be used for a maximum of 3 days to create a “CalNet ID”
The employee receives notification when the credential is set
Employees are required to visit deputies in person again if they forget their passphrase.

30. How Do People Become Deputies?
Managers must submit and approve a request to assign an employee CalNet Deputy status
Deputies must attend a 1 hour training before they are granted deputy privileges
Deputies must sign a privileged access agreement
Deputies are subscribed to a mailing list where the IAM staff can post necessary updates

31. CalNet Deputy Training Content
The importance of the CalNet deputy function in managing access to sensitive university resources
Overview of federated identity management and the requirements of the federations we belong to: InCommon and UCTrust
The expanded responsibility of deputies for managing access to resources provided by our federated partners
Hands-on explanation of how to use CalNet Deputy tools

32. Continued InCommon Silver Gaps
Need better documentation of existing procedures, especially in HR
Modify existing deputy applications to store information about the type and issuer of the ID used in the vetting process
Records retention to meet requirements
Audit approval that the RA/IdP link is adequate
Remote proofing to meet same standards

33. Remote Proofing
Work with external agencies to verify legitimacy of identifying information provided?
Piggyback on remote I-9 process for ID vetting and then use self-assertion of private attributes? Will this meet the standard?

34. Thoughts on Future Improvements
Tie credential issuance to the hiring process: train HR administrators as CalNet Deputies
Ask employees security questions when they first create their CalNet credentials to avoid a second in-person visit if they forget their credentials.

36. Preparing For An InCommon Silver Audit – Authentication Options
Mary Dunker (Virginia Tech)

37. Copyright Statement
Copyright Mary Dunker, This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

38. Authentication options
Credentials
Infrastructure
Scope
Applications
User community
What do you need to consider regarding authentication? The credentials are usually what people think of first.

39. Shift the order… Scope (applications and user community) Credentials
Infrastructure
For the purpose of InCommon Silver, you probably need to reverse your thinking.

40. Scope: applications What applications require Silver?
NIH, NSF research-related sites
Tiaa-Cref
Local applications?? Eg., services that enable someone other than the owner to change sensitive personal information
Before you worry about how you are going to meet Silver, consider what applications will require Silver.

41. Scope: users Who will use those applications?
NIH, NSF: researchers (faculty)
Tiaa-Cref: employees (faculty and staff)
Local applications?? Who are your users? Do students need Silver?
Who will use the applications that will require Silver.

42. Scope: Narrow vs. Broad Narrow
Use Silver only for those applications that need it.
Limited user community -- probably faculty, staff
Broad
Use Silver for all university applications.
Faculty, staff, students, retirees, etc…
Are you going to start small, trying to meet Silver for specific applications and users, or do you want to have all university applications meet Silver?

43. Scope: Narrow vs. Broad Examine existing: Credentials Infrastructure
ID/password
Certificates
Multi-factor tokens, one-time password devices
Infrastructure
How do you decide? Evaluate existing credentials and infrastructure. What kinds of credentials do you issue? Who is eligible for those credentials?
Does your infrastructure support issuing those credentials to those who need to use Silver?

44. Gap analysis Where are the gaps? How big are they? Credentials
Review InCommon Silver IAP 4.2.3, and NIST
Infrastructure
Review InCommon Silver 4.2.2, 4.2.4, 4.2.5
What is the effort and return on investment to improve existing technology and processes vs. build new ones?
If existing credentials do not meet Silver, how much effort would it take to bring them into compliance? Where gaps occur, can you strengthen existing credentials, or will you need to issue new ones?
One area where credentials and infrastructure are closely bound relates to password entropy. If your passwords are not strong enough, can they be strengthened? Will your infrastructure support the password complexity rules, lockouts, and/or history? How about revocation? If not, are there mitigating steps can you take?
Does your existing infrastructure support the Silver registration process? How will you identify a person who has a Silver credential at authentication time?
Are you ready for new infrastructure anyway, or do you already have you robust identity management and authentication solutions?

45. Virginia Tech’s Plan Narrow scope for Silver applications
Use existing credential available to employees: personal digital certificate on SafeNet USB eToken device
Use existing in-person issuance process
Pass LoA from CAS to Shibboleth to determine Silver
Tweak procedures if needed
Document in VTCA User CPS
Virginia Tech sees no need to require all university applications to use Silver. Issues personal certificates to employees on FIPS level 2 devices, compliant with NIST LoA 4, with in-person identity proofing. We front-end Shibboleth with CAS, which recognizes LoA of credential and includes it in the SAML payload. LoA will be translated to Silver assertion for Shibboleth to pass to service provider.