1 / 13

Implementing Federated Single Sign-On for GEOSS

This presentation highlights the research and implementation of a federated Single Sign-On (SSO) system for the GEOSS architecture, focusing on OpenID and SAML 2.0. It discusses the goals of the project, feasibility study, use cases, and concerns. The presentation also outlines the work to be done, including addressing concerns, exploring authorization systems, studying legal interoperability, and conducting outreach activities.

emoreau
Télécharger la présentation

Implementing Federated Single Sign-On for GEOSS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GEOSS Federated Single Sign-On Dr. Steven F. Browdy OMS Tech, Inc. IEEE September 25, 2017 CEOS WGISS-44 Meeting

  2. Short Review • Initial GEOSS Architecture Implementation Pilot (AIP) research • Motivated by the GEO Data Sharing Working Group (DSWG) Implementation Guidelines for the GEOSS Data Sharing Principles. • Focus on OpenID only • Not concerned at this point with authorization (access control), just authentication. • Just want to know “who is using my data.” • Believed that this would be the fastest way to realize a GEOSS federation for SSO. September 25, 2017 CEOS WGISS-44 Meeting

  3. Short Review • After initial research • Decided to include SAML 2.0 (Security Assertion Markup Language) to exchange user credentials via XML. • SAML 2.0 is an open standard that provides a vendor-neutral means of exchanging the following: • user identity • Authentication information • attribute information • authorization information • SAML 2.0 defines the structure and content for assertions and protocol messages used to transfer the above information between Identity Providers and Service Providers. • Works with many user management security systems • Has relatively lightweight requirements • Still focused on authentication only September 25, 2017 CEOS WGISS-44 Meeting

  4. GEOSS AIP Study • Goals • Federated solution that has minimal to no impact on the GEOSS Common Infrastructure (GCI) • Lightweight implementation requirements for data providers • A solution that can evolve • Pilot • Implemented to determine federated SSO feasibility • Focused on SAML 2.0 and OpenID • Partnered with the COBWEB project September 25, 2017 CEOS WGISS-44 Meeting

  5. Provider’s Site Resources (Data and Services) Authentication Service Authorization Service User Answers “is this User XYZ?” by verifying the identity Answers “what can User XYZ do?” by checking identity against stored access constraint rules September 25, 2017 CEOS WGISS-44 Meeting

  6. Feasibility Study Plan September 25, 2017 CEOS WGISS-44 Meeting

  7. Study Plan Primary Use Cases • 1. Authenticate via OpenID to access resources at an OpenID site • 2. Authenticate via OpenID to access resources at a SAML-2 site (requires gateway) • Gateway accepts Google OpenID and Verisign OpenID • 3. Authenticate via SAML-2 to access resources at a SAML-2 site • 4. Authenticate via SAML-2 to access resources at an OpenID site (requires gateway) • 5. Identification as "GEOSS User" During Registration September 25, 2017 CEOS WGISS-44 Meeting

  8. OpenID Gateway Use Case (Verified) The gateway verifies the OpenID, and creates SAML-2 credentials to be used and trusted in the federation. September 25, 2017 CEOS WGISS-44 Meeting

  9. SAML-2 Gateway Use Case (Unverified) SAML-2 GEOSS User The gateway verifies the SAML-2 credentials, and receives a valid OpenID from the SAML-2 Identity Provider to be used in the federation. September 25, 2017 CEOS WGISS-44 Meeting

  10. Main Concerns from AIP Study • That data providers will have a difficult time setting things up properly • Even though there are guidelines • Even though there is help available • That data users will not have the seamless experience they should in accessing unrelated GEOSS resources that require authentication • Questions as to what is required to successfully implement the unverified use case • What about additional federations and identity management systems September 25, 2017 CEOS WGISS-44 Meeting

  11. Current Situation • Some GCI components have tested and have/will rollout support for use of Google SSO • Based on SAML 2.0 and OpenID Connect • Doesn’t realize a full GEOSS-wide federation for SSO • Still concerns • Multiple separate federations will require trust gateways • Require use of SAML 2.0 or allow other standards/solutions to be used • Will there need to be a centralized authentication mediator that handles authentication flow to take burden off of data providers and data users • Trust between federations ??? September 25, 2017 CEOS WGISS-44 Meeting

  12. Work to be Done • Address concerns previously mentioned • More interest in authorization • OAuth2 plus others • Study impact by/to legal interoperability • Work will start in 2018 • GEOSS API to research and perform pilot • GEOSS SIF to consider standards and interoperability concerns • H2020 project participation • Outreach to GEO Flagships, GEO Initiatives, and Community Activities September 25, 2017 CEOS WGISS-44 Meeting

  13. Q & A September 25, 2017 CEOS WGISS-44 Meeting

More Related