InCommon Participant Operating Practices: Friend or Foe?

Slides:



Advertisements
Similar presentations
Appropriate Access InCommon Identity Assurance Profiles David L. Wasley Campus Architecture and Middleware Planning workshop February 2008.
Advertisements

1 Leveraging Your Existing Campus Systems to Access Resource Partners: Federated Identity Management and Tales of Campus Participation EDUCAUSE 2006 October.
Bronze and Silver Identity Assurance Profiles for Technical Implementers Tom Barton Senior Director for Integration University of Chicago Jim Green Manager,
InCommon Assurance Certification VA-SCAN October 3, 2013 Mary Dunker.
Getting to Silver: Practical Matters for CIC Universities Tom Barton University of Chicago © 2009 The University of Chicago.
Functional component terminology - thoughts C. Tilton.
Enterprise Architecture 2014 EAAF as a vehicle for LoA Using EAAF processes to incrementally approach InCommon/UCTrust certification.
How Do You Establish Student Identity Remotely: A Survey Keith Hazelton, University of Wisconsin-Madison Ann West, Internet2/InCommon Federation 2010 Fall.
Federated Identity, Levels of Assurance, and the InCommon Silver Certification Jim Green Identity Management Academic Technology Services © Michigan State.
Information Resources and Communications University of California, Office of the President UCTrust Implementation Experiences David Walker, UCOP Albert.
CSE 4482, 2009 Session 21 Personal Information Protection and Electronic Documents Act Payment Card Industry standard Web Trust Sys Trust.
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.
Appropriate Access: Levels of Assurance Stefan Wahe Office of Campus Information Security.
The University of California Strengthening Business Practices: The Language of Our Control Environment Dan Sampson Assistant Vice President Financial Services.
SAS 112: The New Auditing Standard Jim Corkill Controller Accounting Services & Controls.
Identity Management What is it? Why? Responsibilities? Bill Weems Academic Computing University of Texas Health Science Center at Houston.
Federal Requirements for Credential Assessments Renee Shuey ITS – Penn State February 6, 2007.
Credential Provider Operational Practices Statement CAMP Shibboleth June 29, 2004 David Wasley.
Policy, Trust and Technology Mitigating Risk in the Digital World David L. Wasley Camp 2006 © David L. Wasley, 2006.
Chapter © 2012 Pearson Education, Inc. Publishing as Prentice Hall.
Functional Model Workstream 1: Functional Element Development.
Cloud Security Myths, Legends and Reality Cloud Security Paul Schopis CTO OARnet Joint Techs.
The InCommon Federation The U.S. Access and Identity Management Federation
IDENTITY ASSURANCE PROFILES AND FRAMEWORK DOCUMENTS: PEEK INTO PROPOSED FICAM CHANGES 12/12/12 1.
Learning Objectives LO5 Illustrate how business risk analysis is used to assess the risk of material misstatement at the financial statement level and.
Federated or Not: Secure Identity Management Janemarie Duh Identity Management Systems Architect Chair, Security Working Group ITS, Lafayette College.
Stuff, including interfederation stuff Dr Ken Klingenstein, Director, Middleware and Security, Internet2.
ITU-T X.1254 | ISO/IEC An Overview of the Entity Authentication Assurance Framework.
Ning Zhang, the University of Manchester, UK David Groep, National Institute for Nuclear and High Energy Physics, NL Blair Dillaway, OGF Security Area.
Identity Assurance: When it Matters David L. Wasley Internet2 / InCommon.
Using Levels of Assurance Well, at least thinking about it…. MAX (just MAX)
Credentialing in Higher Education Michael R Gettes Duke University CAMP, June 2005, Denver Michael R Gettes Duke University
INTRODUCTION: THE FIRST TRY InCommon eduGAIN Policy and Community Working Group.
Advanced CAMP: BoF Summaries. 2 Role-based Access Control (RBAC)
INTERNAL CONTROLS What are they? Why should I care?
Federated Identity in Texas Paul Caskey The University of Texas System HEAnet National Conference Kilkenny, Ireland 13 November 2008.
Transforming Government Federal e-Authentication Initiative David Temoshok Director, Identity Policy and Management GSA Office of Governmentwide Policy.
University of Washington Collaboration: Identity and Access Management Lori Stevens University of Washington October 2007.
Identity Federations: Here and Now David L. Wasley Thomas Lenggenhager Peter Alterman John Krienke.
Attribute Delivery - Level of Assurance Jack Suess, VP of IT
Chapter © 2012 Pearson Education, Inc. Publishing as Prentice Hall.
INTRODUCTION: THE FIRST TRY InCommon eduGAIN Policy and Community Working Group.
The Policy Side of Federations Kenneth J. Klingenstein and David L. Wasley Tuesday, June 29, CAMP Shibboleth Implementation Workshop.
Introduction to Shibboleth Attribute Delivery for Campuses New to Shibboleth Paul Caskey The University of Texas System.
Leveraging Campus Authentication to Access the TeraGrid Scott Lathrop, Argonne National Lab Tom Barton, U Chicago.
INFORMATION ASSURANCE POLICY. Information Assurance Information operations that protect and defend information and information systems by ensuring their.
1 EDUCAUSE Mid-Atlantic Regional Conference Top Strategies for Working with Stakeholders: Synopses of Recommendations from the Identity Management Summit.
The Federal E-Authentication Initiative David Temoshok Director, Identity Policy GSA Office of Governmentwide Policy February 12, 2004 The E-Authentication.
LoA In Electronic Identity Jasig Dallas Levels of Assurance In Electronic Identity Considerations for Implementation Benjamin Oshrin Rutgers University.
Auditing Concepts.
The Demand for Audit and Other Assurance Services
Audit of predetermined objectives
The Demand for Audit and Other Assurance Services
University of Texas System
John O’Keefe Director of Academic Technology & Network Services
InCommon Steward Program: Community Review
ServiceNow Implementation Knowledge Management
Service Organization Control (SOC)
Federal Requirements for Credential Assessments
PASSHE InCommon & Federated Identity Workshop
Supporting communities with harmonized policy
Identity & Access Management
InCommon Participant Operating Practices: Friend or Foe?
Fed/ED December 2007 Jim Jokl University of Virginia
Moving forward with assurance
Appropriate Access InCommon Identity Assurance Profiles
Shibboleth 2.0 IdP Training: Introduction
Internal Control Internal control is the process designed and affected by owners, management, and other personnel. It is implemented to address business.
Baseline Expectations for Trust in Federation
Presentation transcript:

InCommon Participant Operating Practices: Friend or Foe? InCommon CAMP 21 June 2010 Paul Caskey, U.T. System

Agenda Introducing the InCommon POP document Why is the POP Important? Examples of POPs Why might the POP be inappropriate? Introducing “Level of Assurance” (LoA) InCommon assurance framework and profiles Issues/Questions/Discussion…

Introducing the InCommon POP Document What is it? Am I required to have a POP? What goes into the POP? Who writes it? Who looks at it? Does anyone ever check its accuracy? How do you change it? What is it? Description of how identities are managed at your institution Contains practice statements that describe how users are identified and how credentials are issued Am I required to have a POP? yes, InCommon requires this However, InCommon does not check the content What goes into the POP? actual documented practices about your IdM system categories: General Info, Community, Credentials, Identity Data, Credential Use, user attributes, privacy Who writes it? Your identity mgmt group, if you have one. Otherwise, Information Security frequently champions that role. Many stakeholders: registrar, HR, legal, IT, Audit Who looks at it? External entities (educational institutions, vendors) who will rely on your identity mgmt system Auditors, so they can verify that you are doing what you say that you do (basic InCommon membership does not, however, require audits) InCommon, to make sure its completed Does anyone ever verify the stated practices? No, you are trusted to accurately reflect reality in your POP. How do you change it? Very carefully and deliberately You should make sure those who trust you, based on your previous version, know that you have revised it Changes should be summarized for quick viewing You should also let InCommon know, if the URL to your POP has changed

Why is the POP Important? *YOU* are now part of my identity mgmt system and I need to know what types of risk that entails The foundation of trust is understanding how those you rely on manage identities – the POP is how you achieve that The “high-value transaction“… Helps you to identify weaknesses in your process Helps auditors measure your performance Chain is only as strong as weakest link If I am to be a good steward of my resources, I must understand how you operate your system (in a federated scenario) High-value transactions mean more is at stake if something goes wrong (student financial aid versus a campus music service) By documenting your processes, you can learn a lot about things *really* work on your campus and identify opportunities for improvement When you have a concrete practice statement, it can help auditors know exactly what it is you intend on doing in various situations (rather than have them speculate or assume)

Example of POPs The InCommon "starter" document Institutional: http://www.incommonfederation.org/docs/policies/incommonpop_20080208.html Institutional: Many are there, but only InCommon registered contacts can see the URLs – some campuses feel this is sensitive information. https://wiki.cac.washington.edu/display/infra/Shibboleth+for+UW+Web+Applications http://its.lafayette.edu/about/policies/InCommonPoP http://www.cit.cornell.edu/identity/InCommon.html System-based: UT System: https://idm.utsystem.edu/utfed/MemberOperatingPractices.pdf Federation-based: U.K. Federation: http://www.ukfederation.org.uk/content/Documents/FedDocs

Why might the POP be inappropriate? Some are inclined to “hide” them (or URLs get changed) Strong desire to “make it look good” or “how we plan on things working” Can be speculative in terms of how things really work POPs can become stale (practices/technologies change) POPs are rarely/never verified (the “A” word…) So, there needs to be some “teeth” in the operating practices to promote trust among participants……..

Introducing “Level of Assurance” (LoA)… What is LoA? What is LoA NOT? Why is it stronger than a POP? Who gets to set the standards? Examples of LoA How is the required level determined? How is it used? What is LoA? definition: how certain a service provider can be that an authenticated user is who they claim to be way of describing common practices that reflect degrees of strength in an IdM provides for a consistent understanding of IdM frequently represents “best practices” for operating an IdM infrastructure governs identity-related activities, typically in-person vetting, password complexity requirements, and data currency What LoA is NOT? required for participation law the only way to conduct high-value transactions a “quality score” for your identity practices not necessarily hierarchical Why is it better than a POP? they typically reflect a well thought-out standard intended to reflect quality/best practices many enterprises can follow the same standard and discuss IdM in common terms usually, it is verified to ensure compliance Who gets to set the standards? Federations (InCommon) Collaborative organizations (TAGPMA) Those with valuable resources/services (NIH) Those with legislative authority (government) Examples of LoA US Government: FICAM/TFPAP originally based off NIST 800-63: 1: Little or no confidence in the asserted identity 2: confidence exists that asserted identity is accurate 3: high confidence in the asserted identity’s accuracy 4: very high confidence in the asserted identity’s accuracy Kantara Initiative 4 levels provisionally approved by FICAM InCommon (next topic) Bronze (1) Silver (2) seeking FICAM approval How is the required level determined? SPs must determine the LoA they require based on a careful risk assessment Fed Gov’t provides a framework for such an assessment in OMB M04-04 Based on perceived institutional risk Often an over-looked responsibility of SPs How is it used? Typically, one of the attributes an IdP sends to an SP for a user will be a representation of all applicable LoA values that apply to the transaction. An IdP’s assertion of these values should be controlled by either the SP or the federation operator (not everyone is certified to assert all levels) Newer ways of expressing this information, using native fields in SAML, are being explored and developed

The InCommon Assurance Framework What's an IAP? Background How are they used? Bronze (http://www.incommonfederation.org/docs/assurance/InC_Bronze-Silver_IAP_1.0.1.pdf) Silver (same URL as above) How to get started? What’s an IAP? (Identity Assurance Profile) “structured sets of requirements intended to satisfy management of access to general classes of resources” (Wasley) an IAP represents the requirement for a particular LoA Background started with the fed’s eAuth program, which died on the vine a few years ago originally based off of 4 levels defined by 800-63 InCommon wanted to be compliant with federal standards and began development work on InCommon IAPs Silver and Bronze More than vetting and credentialing, it includes requirements for legal status, help desk operations, records management, network protocols, etc, etc All info avail on the InCommon website How are they used? First, you apply Then, you assemble documentation and evidence of compliance Next, a “sufficiently independent” auditor reviews your documentation and evidence against the requirements in the IAP Then, an assessment of compliance is made by InCommon If approved, the InCommon metadata is updated to allow your IdP to assert transactions under the Silver IAP Service providers receive an LoA value from you in an attribute (typically eduPersonAssurance) and, if federation metadata allows you to assert that value, they will accept your assertion and the user is allowed to access the resource in question. Bronze Intended to map to fed level 1 in-person vetting not required less restrictive password entropy requirements (1 chance in 1024 – 2^-10) Silver Intended to map to fed level 2 identity validation required (in-person or remote) more restrictive password entropy requirements (1 chance in 16,384 – 2^-14) How to get started? If not done already, establish an IdM stakeholders group on your campus Build your POP, based on what you actually do perform a gap analysis between your POP and InCommon Silver develop an action plan to address deficiencies identified in gap analysis notify InCommon of your desired LoA certification have your internal audit department perform an audit sign InCommon legal addendum for that LoA

Issues/Questions/Discussion… Organization-based versus subject-based? (the "exception process") What infrastructure is needed to implement higher LoAs? Is LoA determined only at credentialing time or should there be a run-time component? What about remote password resets? How urgent is LoA? To be capable of higher LoAs, does that man that everyone on your campus must meet the requirements? What is needed to implement higher LoAs? documented processes internal controls to verify process is being followed password policy system (strength, composition, notification) ability to reliably assert LoA values (provisioning) Does LoA change if your IdM system locks an account out 50 times in a day? How about if one of your staff members who you saw at lunch records authentication events from an IP address in Croatia? What about if the security group discovers a keystroke logger on the user’s computer? Do you lower LoA when a user creates a new password remotely (the forgotten password scenario)? Urgent? Don’t wait until it is – this is a complicated process involving most of your campus’ business units

Thank You! Contact Information: Paul Caskey (pcaskey@utsystem.edu)