InCommon Technical Advisory Committee Community Forum. October 10, 2013

Transcription

1 InCommon Technical Advisory Committee Community Forum October 10, 2013

2 Logistics for Today Use the phone line we ll want to hear from you! (please use if you don't pay for long distance) (toll-free US/Canada) PIN: # (everyone joins on mute press ##1 to unmute your phone) We will be conducting polls during this webinar some will have the audience entering suggestions that everyone can vote on. We are you! We re here to listen The work gets done by ALL of us join a Sub Group!

3 TAC Community Update Agenda Introduction InterFederationUpdate Metadata Distribution Update MultiFactor Update TAC Quick Work Summary Items, of Past Work and Items Future Quick TAC Work Summary Items, of Past Work and Items Future Steve Carmody Paul Caskey Scott Cantor Tom Barton, Ann West Keith Nick Roy Hazelton Nick Keith Roy Hazelton

4 What is the InCommon Technical Advisory Committee? The InCommon TAC will work with Steering to support the InCommon Participant community's use of shared identity and access management technology, services, recommended practices and strategies. The InCommon TAC will advise the SC regarding policy implications of technical changes and the technical implications of proposed policy changes. The TAC may suggest policy changes to support new uses or configurations of the underlying technology or its applications. The TAC shall seek further review of its recommendations within the broader community of users, both within InCommon and among the larger, shared access management community, as appropriate. The TAC will function as defined for Advisory Committees in the InCommon LLC ByLaws.

5 TAC Members Tom Barton, University of Chicago Jim Basney, University of Illinois Scott Cantor, The Ohio State University Steven Carmody, Brown University Paul Caskey, University of Texas System Michael Gettes, Carnegie Mellon University Keith Hazelton, University of Wisconsin - Madison Jim Jokl, University of Virginia Ken Klingenstein, InCommon Steering Committee Chris Misra, UMASS-Amherst (NEW) Nick Roy, Penn State (NEW) David Walker, Independent Ian Young, U.K. Access Management Federation In Memoriam - R.L. "Bob" Morgan, University of Washington

6 TAC Does its Work Through Subgroups What s a subgroup? A community group that forms to work on a technical priority. A subgroup has a charter and goals Who can participate? Anyone in the community with an interest in the topic and time to contribute

7 TAC Subgroups Current TAC Subgroups Social Identity Working Group Interfederation Phase 2 Metadata Distribution PKI Subcommittee Proposed Subgroups Federation Operations

8 Today s Advertisement See you at Identity Week 2013! An opportunity to meet and interact with your peers in the IDM space Advanced CAMP has reached its registration cap, but CAMP is still open for registration

9 The Big Picture InCommon, Net+ Continue to Evolve The growth of the Net+ provider portfolio The evolving relationship between between InCommon and Net+ The growing demand for international interoperation The need to provide solutions for rapidly evolving campus IDM requirements

10 Interfederation Working Group

11 About the group Began in early 2013 led by Jim Basney" Intent was to explore the area of linking federations" Technical aspects" Trust/policy issues" One primary driver was LIGO users in the UK Federation" Wiki:" spaces.internet2.edu/display/incinterfed/interfed+subcommittee" Mailing List:" lists.incommon.org/sympa/info/interfed"

12 Use Cases" Deliverables from Phase 1 spaces.internet2.edu/x/eqawag" Plans for InCommon and UK Interfederation" spaces.internet2.edu/x/tia_ag" Lessons Learned" spaces.internet2.edu/x/qwboag" Report to Technical Advisory Committee (TAC)" spaces.internet2.edu/x/dw9oag"

13 Phase 2 Picks up where Phase 1 left off." Duration: October 2013 March 2013" New Leadership:" Warren Anderson (LIGO, new to subcommittee)" Paul Caskey (UT System, Liaison to TAC)" Charter drawn from recommendations document of Phase 1." Currently ~10 participants."

14 Charter for Phase 2 Establish international interfederation agreements with edugain and UK federation." Review documented trust practices and policies for entity registration and publishing." Review and adopt the US-EU Code of Conduct concerning attribute release and privacy." Review and assist in the implementation of metadata management/publication/aggregation/tagging improvements." Establish practices and policies for domestic interfederation for regional, K-12, etc federations."

15 Next steps? Begin work on Phase 2" And We need You!! (everyone is welcome)" First telecon soon! (~10/23)" Subscribe to the mailing list:" All project information is linked here:" spaces.internet2.edu/display/incinterfed"

16 Warren Anderson, Chair" Contacts Paul Caskey, TAC Liaison"

17 Metadata Distribution Subgroup Charter Phase One Recommendations

18 Phase 1 Conclusions Current signing key will be maintained indefinitely, a long-lived, self-signed certificate issued Shibboleth deployers unaffected, other metadata-supporting products likely affected similar to the last time the certificate was renewed Current CA not used operationally by federation participants, will be discontinued upon 2014 expiration Review and update policy and technical guidance around signing operations, and participant keys

19 Phase 2 Discussions Plan transition to SHA-2 in metadata signatures Currently testing broader interoperability issues around use of SHA-2 Primary impact is on unsupported software versions using OpenSSL or earlier Most common case is Red Hat EL 4 and various unsupported Windows Shibboleth packages

20 Phase 2 Discussions Examine trade-offs with different technical /business models for metadata management and distribution (e.g., offline key vs. an online HSM) Propose a pilot for support of per-entity queries using existing Shibboleth SP software Understand technical requirements for software and federation operations Understand impact on features like IdP Discovery

21 Multifactor Authentication & Assurance Update Tom Barton, U Chicago & Internet2 Ann West, Internet2

22 Passwords are bad and will get worse. We know! Need to strengthen authentication process Reduce risk that authenticated user is someone else Stolen or shared (eg, phishing) Inappropriate reassignment (eg, yahoo) Fraudulently obtained InCommon s Identity Assurance Framework provides a stepwise and standards-based way to plan your mitigation of these risks 22

23 Components of assurance Effort to mitigate Risk Fraudulently obtained Inappropriate reassignment Stolen or shared Assurance component that mitigates Identity proofing + credential management Vetting process, Subject attributes, record keeping Credential management Token issuance & revocation, binding of Token to Subject, secure infrastructure, record keeping Token technologies Password/passphrase Second factor (OTP, phone factor, 2 nd password) Multi-factor (PIN + token) Additional factors (biometric, geolocation,...) 23

24 Assurance update Multi-Context Broker Shibboleth extension Silver/Bronze, 2FA, MFA, step-up authentication Testing code Active Directory Cookbook for Silver v1.2 Draft available for comment. No Alternative Means needed Further Assurance program work Bronze Adoption, Federal Cloud Credential Exchange (FCCX) Alternative Means MFA: SafeNet (soon), Duo (underway) Certificates: Comodo and InCert (Manage certs on user devices) More info: assurance.incommon.org 24

25 Service Categories

26 What is a Service Category? Classification of member SPs to make attribute release more scalable IdPs release a known set of attributes to categories of SPs Attribute release policy is configured for all services in the category (both present and future), rather than once per service. Classification of supporting IdPs to help SPs build relevant discovery interfaces

27 Research & Scholarship Category Services that 1) support Research and Scholarship and 2) require a small set of low-risk attributes Proposed modification to R&S definition to remove requirement for "no specific oversight" of research supported by SP This aligns better with an emerging international R&S Category Academic research in US is generally subject to oversight of some form, but in any case, compliance cannot be readily verified by InCommon Please provide comments and feedback in the chat room or start a conversation on the participants@incommon.org list.

28 Affiliation-Based Access Category Proposal: Affiliation-Based Access Category Services that 1) benefit campus community and 2) require no personally-identifying information Only affiliation and a pseudonymous identifier (edupersontargetedid) are released No presumption of an existing institutional agreement for these services Examples of eligible services include: Software tools for students Online databases for researchers Entertainment discounts for staff Please provide comments and feedback in the chat room or start a conversation on the participants@incommon.org list.

29 Social Identity

30 Social Identity Use Cases Possible use cases for social identity: 1. Social gateway as an IdP of Last Resort 2. Parent accessing student grades web app 3. Student accessing continuing ed course management system 4. Provide someone with one-time or short-term access to local services

31 Social-to-SAML Gateway Pilot Paul Caskey and his colleagues at the University of Texas piloted a Social-to-SAML Gateway in October 2012 The pilot has been in continuous operation since that time Much of what we know about social identity is due to the success of this pilot

32 Google Gateway InCommon Operations runs a production Google Gateway for internal use The Google Gateway is an OpenID-to-SAML gateway for the Federation Manager, the Certificate Manager, and a few other Internet2 SPs Cirrus Identity built the Google Gateway using simplesamlphp in the cloud (AWS)

33 Social Identity WG Next Steps At the Oct 7 Social ID WG meeting, Cirrus Identity demoed their gateway solution Cirrus will deploy their gateway solution on campuses that have expressed an interest Demo/trial phase begins Nov 2013 Production launch targeted for early 2014 Additional campuses should contact Cirrus directly A centralized gateway for all InCommon participants is being discussed Will explore multiple service and subscription models

34 Other Items Other items of possible interest: Delegated Administration Federating the FM and the CM Multifactor IdP Proxy Discoverable IdPs SHA-256 Testing IdM Landscape InCert

35 Delegated Administration

36 What is Delegated Administration? A Delegated Administrator (DA) is provisioned by a Site Administrator (SA) The SA delegates the administration of SP metadata to the DA The SA must approve any metadata update request made by the DA A DA logs into the FM with a federated password

37 Announcement A Delegated Administrator may now log into the FM with a Google account

38 InCommon Google Gateway Internet2 IdPoLR Google Gateway OpenID RP SAML IdP FM Google IdP InCommon IdP In production on October 13, 2013

39 Federating the FM and the CM

40 InCommon Multifactor IdP Proxy Internet2 IdPoLR Google Gateway InCommon Metadata MF IdP Proxy FM OpenID RP SAML IdP InCommon IdP SAML SP SAML IdP CM Google IdP Duo Service

41 Multifactor IdP Proxy The Multifactor IdP Proxy is a SAML-to-SAML gateway that implements distributed multifactor authentication. The MF IdP Proxy is integrated with the Duo Security mobilebased authentication solution. All Executives, SAs, and RAOs will be required to enroll a mobile device for the purposes of MFA. Duo supports ios, Android, Windows Mobile, and Blackberry. A staging instance of the MF IdP Proxy is being tested now. Cirrus Identity built the MF IdP Proxy using simplesamlphp. The staging instance of the MF IdP Proxy is deployed in the cloud (AWS). The deployment requirements for a production MF IdP Proxy are TBD.

42 Federating the FM: Status Report Project status: All DAs log into the FM with a federated password now; all DAs will log in via the MF IdP Proxy by the end of 2013 All RAs log into the FM with two factors now; all RAs will log in via the MF IdP Proxy by the end of 2013 All new Site Administrators will be required to enroll a mobile device by the end of 2013

43 Federating the CM: Status Report Project status: A staging instance of the CM that supports federated login is being tested now All MRAOs will log into the staging CM with two factors via the IdP Proxy by the end of Oct 2013 All DRAOs will log into the staging CM via the IdP Proxy by the end of 2013 All new RAOs will be required to enroll a mobile device by the end of 2013

44 InCert Status 44

45 InCert: The Problem Space InCert addresses two independent but related issues Manual on-boarding of devices on to the campus network is hard Device configuration for campus WLAN network Device MAC address network registration Security settings & device security testing etc., etc. Stronger authentication can be hard to deploy Passwords are painful to use and phishing is easy and commonplace Enhanced authentication, to be used, must be as or more simple for users to use than passwords and add real security The use of digital certificates (PKI) can enhance security and usability 45

46 Network On-Boarding Automation Many schools have developed local tools Tools, depending on platform, implements functions such as: Certificate installation Wireless configuration Windows firewall VPN settings Security settings Network registration 46

47 Personal Digital Certificate Automation Common Uses for Standard Assurance Certificates Web authentication to campus Web SSO VPN authentication Wireless authentication (EAP-TLS) Campus and eduroam S/MIME for signed (and encrypted) Digital signatures Globus / Grid InCert automates the harder parts of end-user digital certificate use Provisioning and life cycle management Application setup InCommon Client Certificate Site 47

48 InCert : Common Network On-Boarding Tool Development Goals for InCert Project Automate on-boarding for workstations and mobile devices Automatically configure network and wireless settings campus and eduroam Device registration, security configuration, etc. Open community-sourced tool set Life-cycle management of end user certificates Built-in support for InCommon Certificate Service Customizable per-campus without coding Easy for campus to leverage just the pieces that meet local needs Early support for at Windows, MacOS, ios, and now Android Support for other campus needs (e.g., netreg, security, etc.) 48

49 InCert Tool Structure and Status InCommon Comodo CA Ready Ready more testing needed Known issue when used with certs Macintosh Client Campu s AuthNZ Link Campus InCert Server Development Roadmap Campus Logging, netreg, etc. Macintosh Web Service Windows Client ios Web Service Android Client 49

50 InCert Background/Summary Information Summary Documents /InCommonCertToolv2.pdf Screen movie of early version of Windows client Client Certificate Roadmap 50

51 TAC Community Updates 2013 TAC Work Items Keith Hazelton UW-Madison

52 Strategic Priorities, 2013 Assurance Metadata Administration Supporting NET+ Interfederation Metadata Distribution Federated User Experience ç Mobile/Federated Non-browser Applications ç

53 InCommon s evolving role: TAC, at InC Steering s request, spearheaded comprehensive scan of 50+ identity-related projects and initiatives in research and education Shibboleth Consortium, Grouper, REFEDS, CIFER, NSTIC, Kuali RICE, Internet2 Net+, InCommon, Published results in June 2013 Identity Management in Higher Education: A View of the Landscape 53

54 The Landscape Report Institutes of higher education and research are complex, highly dynamic, non-hierarchical organizations where people often have multiple simultaneous roles and relationships Off-the-shelf identity and access management solutions do not generally meet the needs of higher education and research In a very real sense, higher education is leading the creation of identity management solutions because it has to.

55 Trust and Identity vision Review of Landscape document led InC Steering to sketch a vision of the way forward Trust and Identity InCommon seems uniquely situated to provide comprehensive information sharing and coordination of efforts across the wide array of identity consortia, projects and initiatives

56 Trust and Identity Recommendations Production of roadmaps for CIOs on building and leveraging federation and identity and access management infrastructure Work with specific projects to make sure the full set of needed tools and training are available Foster shared approaches to assurance and other crucial policy and practice matters

57 Trust and Identity Recommendations Explore ways to extend the benefits of a modern, comprehensive IAM infrastructure beyond the R1 institutions IAM as a Service Consulting services to augment local staff and bootstrap creation and roll-out of on-campus infrastructure Enhance InC Steering s organizational capabilities so it can effectively respond to these opportunities

58 Some drivers for 2014 and beyond (Are they yours?) Enhanced support for research mission New models for teaching and learning Accelerating adoption of cloud-based services Serving an expanding set of user populations Next generation ERP roll-outs Pressure to consolidate admin services to free up scarce resources

59 Setting TAC Priorities for 2014 Participant Polling Current pain or pressure points? Unfinished journeys that must be continued? Looming trends calling for effective shared responses?