Meeting InCommon Silver Profile Standards at UCD and UCB Bob Ono, UC Davis, Dedra Chamberlin, UC Berkeley, David Walker, UC Davis, Doreen Meyer, UC Davis

Topics  Introduction to InCommon Silver Profile  UCD and UCB Gap Analysis Highlights  UCTrust Basic and InCommon Silver  Roadmap  Resources

Introduction to InCommon Silver Profile

InCommon In Action at UCD and UCB A UCD or UCB researcher accesses web-based data

InCommon In Action at UCD and UCB A UCD or UCB researcher accesses web-based data provides account

InCommon In Action at UCD and UCB A UCD or UCB researcher accesses web-based data Calendaring Local applications provides account

InCommon In Action at UCD and UCB A UCD or UCB researcher accesses web-based data Calendaring Local applications provides account applications At Your Service UC Travel (Connexxus) Learning Mgmt. System

InCommon In Action at UCD and UCB A UCD or UCB researcher accesses web-based data Calendaring Local applications applications At Your Service UC Travel (Connexxus) Learning Mgmt. System provides account applications DOE apps NSF apps NIH apps

InCommon In Action at UCD and UCB A UCD or UCB researcher accesses web-based data Calendaring Local applications applications At Your Service UC Travel (Connexxus) Learning Mgmt. System provides account applications DOE apps NSF apps NIH apps

InCommon, UC, And Moving To Silver  InCommon framework ensures that UC campuses are adequately protecting staff and faculty identities and sensitive data.  InCommon framework is consistent with the research mission of UCOP, facilitating collaboration among campuses and Federal institutions.  By acting now, UC will be in alignment with significant Federal agencies and educational institutions, and can strengthen the UCTrust Basic framework.

InCommon Framework Is Based On Federal Guidelines  Federal Guidelines include  NIST Special Publication 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”.

InCommon Identity Assurance Program  Functional areas define the standards.  Identity Providers address how to meet them.  For each functional area, identify the gaps between  UC location identity management infrastructure and  the InCommon Silver profile Identity Assurance Functional Areas Business, Policy, and Operational Factors Identity Proofing Electronic Credential Technology Credential Issuance Authentication Events Identity Information Management Identity Assertion Content Technical Environment 4.2.8

Identity Management Functional Model Identity Assurance Functional Areas Business, Policy, and Operational Factors Identity Proofing Electronic Credential Technology Credential Issuance Authentication Events Identity Information Management Identity Assertion Content Technical Environment 4.2.8

UCD and UCB Gap Analysis Highlights

Approach for Meeting InCommon Silver Standards  Gap Analysis: Determine gaps between standards; determine effort to meet gaps.  Next step: Identify participants from relevant business and technical areas.  Then: Select initial tasks based on available resources and relative complexity. Local UCB and UCD Standards InCommon Silver Standards

Summary of Gap Analysis for UC Davis and UC Berkeley (1.1) Audit CategoryUC DavisUC Berkeley Business, Policy, and Operational Factors Identity Proofing Electronic Credential Technology Credential Issuance Authentication Events Identity Information Management Identity Assertion Content Technical Environment > 60 days < 60 days complete

Business, Policy, and Operational Factors (4.2.1) Purpose: Must be an InCommon Participant in good standing. > 60 days < 60 days complete GapWhoTypeUCD Effort UCB Effort No outstanding gap.

Registration and Identity Proofing (4.2.2) GapWhoTypeUCD Effort UCB Effort Improve Account Deputy Program procedures for in person proofing IT, Depts. Business Process, Technical Improve Remote proofing program IT, Depts Business Process, Technical Purpose: Identity proofing is based on government issued ID or public records. Verified information is used to create a record for the Subject. > 60 days < 60 days complete

Credential Technology (4.2.3) GapWhoTypeUCD Effort UCB Effort Password lockout and mgmt. compliant with NIST entropy calculations ITTech., Business Process Protect Authentication Secrets: Minimize risk of exposure of Secrets to non-IDP services. ITTech., Business Process Purpose:. If other Credentials are used to authenticate the Subject to the IdP, they must meet or exceed the effect of these requirements. > 60 days < 60 days complete

Credential Issuance and Management (4.2.4) GapWhoTypeUCD Effort UCB Effort Same Subject during registration and Credential issuance IT, HR, Payroll Tech., Business Process Improvements in revoking, renewing, and reissuing Credentials ITTech., Business Process Maintain logs 180 days after Credential expires ITTech. Purpose: The authentication Credential must be bound to the physical Subject and to the IdMS record pertaining to that Subject > 60 days < 60 days complete

Authentication Events (4.2.5) GapWhoTypeUCD Effort UCB Effort Send periodic reminders to Subjects about sharing and security ITBusiness Process, Tech. confirmation of transaction to Subject ITTech. Purpose: The Subject proves that he or she is the holder of a Credential, enabling the subsequent issuance of Assertions. > 60 days < 60 days complete

Identity Information Management (4.2.6) Purpose: Subject records must be managed appropriately so that Assertions [issued by UCD or UDB] are valid GapWhoTypeUCD Effort UCB Effort No outstanding gap. > 60 days < 60 days complete

Identity Assertion Content (4.2.7) GapWhoTypeUCD Effort UCB Effort Establish procedures for assigning certified IAQs to assertions ITDocumen- tation Purpose: have processes in place to ensure that information about a Subject’s identity conveyed in an Assertion of identity to an SP is from an authoritative source. > 60 days < 60 days complete

Technical Environment (4.2.8) GapWhoTypeUCD Effort UCB Effort Inventory internal IdP systems for any communications outside of IST infrastructure ITDocumen- tation Purpose: Resist potential technical threats that might result in false assertions of identity Statement : Appropriate measures shall be used to protect the confidentiality and integrity of network communications supporting IdMS operations. > 60 days < 60 days complete

UCTrust Basic and InCommon Silver

Comparing the UCTrust Basic and InCommon Silver Framework  It is possible to replace most but not all of UCTrust Basic with InCommon Silver policy.  InCommon Silver policy has more specific requirements for IdP than UCTrust Basic. InCommon Silver’s IdP requirements can replace UCTrust Basic’s IdP requirements.  InCommon Silver does not have requirements for Service Providers; UCTrust Basic does have requirements for Service Providers.  InCommon Silver requires an audit; UCTrust Basic does not require an audit.

Comparing The UCTrust Basic and InCommon Silver Certification Models IdP Operator IdP Operation UCTrust Service Provider Assertion with appropriate IAQs IdPO Certification IdP Certification Status

Comparing The UCTrust Basic and InCommon Silver Certification Models IdP Operator IdP Operation InCommon Service Provider Assertion with appropriate IAQs IdPO Certification IdP Certification Status

Comparing The UCTrust Basic and InCommon Silver Certification Models IdP Operator IdP Operation InCommon Service Provider Assertion with appropriate IAQs IdPO Certification IdP Certification Status

Comparing The UCTrust Basic and InCommon Silver Certification Models IdP Operator IdP Operation In Common Service Provider Assertion with appropriate IAQs IdP Certification Status Summary Report Auditor IdP Certification Status Detailed and Summary IdPO Certification

Roadmap For Moving To Silver Roadmap to using InCommon Silver profile identities for UCTrust and InCommon applications

InCommon Silver Roadmap: Past Work  UC Trust Working Group discussed issues, including how to proceed (December 2010-March 2011)  UC Berkeley and UC Davis performed a gap analysis and a level of effort analysis (October March 2011)  UC Berkeley and UC Davis participated with CIC (Virginia Tech and Indiana U) on a joint panel presentation at the Educause Security Professionals Conference in April  UCTrust Working Group provided feedback to the InCommon Federation TAC on their 1.1 draft documents via David Walker (December 2010 – March 2011)  ITPS and UCTrust Working Group are discussing InCommon Silver in April 2011

InCommon Silver Roadmap Spring 2011  Ask each campus location to perform a high level gap analysis and report results to the UCTrust Working Group by mid-May. (See slide 16).  ITPS and UCTrust Working Group to share high level gap analysis and proposed project plan to move to InCommon Silver with the ITLC at June 2011 meeting

InCommon Silver Roadmap: Next Steps If Plan is Approved  Each UC location to perform a detailed gap analysis and create their local project plan for InCommon Silver certification and report results to their CIO. UCTrust will collect the UC location project plans.  Based on the UC location project plans, ITPS and UCTrust Working Group to provide a UC-wide plan to ITLC.

InCommon Silver Roadmap: Next Steps  UCTrust Working Group to update the UCTrust Policy document to align with the use of InCommon Silver Policy for IdP’s and UCTrust Basic Policy for Service Providers  UC locations to initiate work to meet InCommon Silver profile standards.  UCTrust Working Group to ask SPs to accept InCommon Silver and UCTrust assertions  UC locations run a campus audit to meet InCommon Silver profile standards, then request certification from InCommon Federation.

InCommon Silver Roadmap: Next Steps  After approval from InCommon Federation, UC locations can begin to use InCommon Silver identities for UCTrust and InCommon applications.  UCTrust Working Group to tell SPs that they no longer need to accept UCTrust Basic assertions

Resources

InCommon Resources at  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 reportCIC InCommon Silver Project – Phase 1 report

UCTrust Resources  UCTrust  UCTrust University of California Identity Management Federation Service Description and Policies UCTrust University of California Identity Management Federation Service Description and Policies

Questions and Contact Information  Bob Ono, UC Davis,  Dedra Chamberlin,UC Berkeley,  David Walker, UC Davis,  Doreen Meyer, UC Davis,

Additional Information for Review

Federal Assurance Framework LOA2 Adopted by InCommon and UCTrust  Level of Assurance (LOA) is based on a risk assessment of unauthorized access, authentication error, or credential misuse Risk criteria (OMB-04-04) include:  Inconvenience, distress, or damage to reputation  Financial loss or liability  Harm to agency programs or public interest  Unauthorized release of sensitive information  Personal safety  Civil or criminal violations

Levels of Assurance (LOA) at UC Campuses Lower Risk of Unauthorized Access Higher Risk of Unauthorized Access Sample applicationsLocal UC , wireless network, workstation login, calendaring NSF, DOE, NIH apps, UCTrust apps Identity Proofing, Credential Issuance self-assertedGovernment photo ID verified Authentication Methods User name and password Multi-factor authentication

KEY Gap: Category (4.2.criteria section number) GapWhoTypeEffort Issues requiring significant effort for a particular audit category (from UCD and/or UCB analysis) Units to resolve issue IT Information Technology including IdM HR Human Resources IA Internal Audit Dept. Campus Depts. Type of Work Business Process, Documen- tation, Technical Color code repre- senting level of effort in days. Key at top right. > 60 days < 60 days complete

InCommon  InCommon provides a framework of shared policies, trust- establishing processes, and technology standards for universities and service partners to follow.