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
CalendaringEmail
Local applications
provides account
InCommon In Action at UCD and UCB
A UCD or UCB researcher accesses web-based data
CalendaringEmail
Local applications
provides account
applications
At Your ServiceUC Travel (Connexxus)Learning Mgmt. System
InCommon In Action at UCD and UCB
A UCD or UCB researcher accesses web-based data
CalendaringEmail
Local applications
applications
At Your ServiceUC Travel (Connexxus)Learning Mgmt. System
provides account
applications
DOE appsNSF appsNIH apps
InCommon In Action at UCD and UCB
A UCD or UCB researcher accesses web-based data
CalendaringEmail
Local applications
applications
At Your ServiceUC Travel (Connexxus)Learning Mgmt. System
provides account
applications
DOE appsNSF appsNIH 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 800-63 Level of Assurance 2 (LOA2) as defined in OMB-
04-04 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 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
Identity Management Functional Model
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
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.
LocalUCB and UCDStandards
InCommon Silver Standards
Summary of Gap Analysis for UC Davis and UC Berkeley (1.1)
Audit Category UC Davis UC Berkeley
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
> 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
Gap Who Type UCD Effort
UCB Effort
No outstanding gap.
Registration and IdentityProofing (4.2.2)
Gap Who Type UCD 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)
Gap Who Type UCD Effort
UCB Effort
Password lockout and mgmt. compliant with NIST entropy calculations
IT Tech., Business Process
Protect Authentication Secrets: Minimize risk of exposure of Secrets to non-IDP services.
IT Tech., 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)
Gap Who Type UCD Effort
UCB Effort
Same Subject during registration and Credential issuance
IT, HR, Payroll
Tech., Business Process
Improvements in revoking, renewing, and reissuing Credentials
IT Tech., Business Process
Maintain logs 180 days after Credential expires
IT Tech.
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)
Gap Who Type UCD Effort
UCB Effort
Send periodic reminders to Subjects about sharing and security
IT Business Process, Tech.
Email confirmation of transaction to Subject
IT Tech.
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 InformationManagement (4.2.6)
Purpose: Subject records must be managed appropriately so that Assertions [issued by UCD or UDB] are validGap Who Type UCD
Effort
UCB Effort
No outstanding gap.
> 60 days
< 60 days
complete
Identity Assertion Content (4.2.7)
Gap Who Type UCD Effort
UCB Effort
Establish procedures for assigning certified IAQs to assertions
IT Documen-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)
Gap Who Type UCD Effort
UCB Effort
Inventory internal IdP systems for any communications outside of IST infrastructure
IT Documen-tation
• Purpose: Resist potential technical threats that might result in false assertions of identity
• Statement 4.2.8.2.1: 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 ProviderAssertion with appropriate IAQsId
PO C
ertifi
catio
n
IdP Certification Status
Comparing The UCTrust Basic and InCommon Silver Certification Models
IdP Operator
IdP Operation
InCommon
Service ProviderAssertion with appropriate IAQsId
PO C
ertifi
catio
n
IdP Certification Status
Comparing The UCTrust Basic and InCommon Silver Certification Models
IdP Operator
IdP Operation
InCommon
Service ProviderAssertion with appropriate IAQsId
PO C
ertifi
catio
nIdP Certification Status
Comparing The UCTrust Basic and InCommon Silver Certification Models
IdP Operator
IdP Operation
In Common
Service ProviderAssertion with appropriate IAQs
IdP Certification StatusSu
mm
ary
Repo
rt
Auditor
IdP Certification Status
Detailed and Summary
IdPO
Cer
tifica
tion
Roadmap For Moving To SilverRoadmap 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 2010 - 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 2011.
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 http://incommonfederation.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
UCTrust Resources
UCTrust http://www.ucop.edu/irc/itlc/uctrust/
UCTrust University of California Identity Management Federation Service Description and Policies
http://www.ucop.edu/irc/itlc/uctrust/trustpolicy032707.html
Questions and Contact Information
Bob Ono, UC Davis, [email protected]
Dedra Chamberlin,UC Berkeley, [email protected]
David Walker, UC Davis, [email protected]
Doreen Meyer, UC Davis, [email protected]
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 applications
Local UC email, wireless network, workstation login, calendaring
NSF, DOE, NIH apps, UCTrust apps
Identity Proofing, Credential Issuance
self-asserted Government photo ID verified
Authentication Methods
User name and password
Multi-factor authentication
KEY Gap: Category (4.2.criteria section number)
Gap Who Type Effort
Issues requiring significant effort for a particular audit category (from UCD and/or UCB analysis)
Units to resolve issueIT Information Technology including IdM HR Human ResourcesIA Internal AuditDept. 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.
Top Related