Home | Workrooms | SSO Authentication | SSO Working Group Charge

SSO Authentication Working Group Charge

The charge of the Single Sign-On Working Group was included as part of the original proposal, and was subsequently revised by the SSO Authentication Working Group in order to refine the goals and make clear the work product. This version is dated February 9, 2010.


This Working Group will explore issues related to Web Single Sign-On (SSO) Authentication Optimization in order to create a Recommended Practice(s) that will improve the user experience, providing consistency, improved usability, and an SSO experience across a set of distributed service providers. The end result of this work will be small, smart conventions for moving the user within a session seamlessly from licensed site to licensed site. The creation of new SSO technologies or the standardization of current SSO technologies is beyond the scope of this working group’s charge.

The Working Group will produce four possible deliverables:

Deliverable 1: NISO Recommended Practice: standardizing terminology

  1. Articulate use cases describing the variety of ways in which a browser user would arrive at a service provider (SP), (possibly) traverse a discovery process, and arrive at a protocol/package specific login. Minimally, this should include use cases involving: direct to the SP, starting from a home site library navigation page, federated searches, and the open web (e.g., Google), as well as deep linking to and between documents/results licensed by content sites (linking via OpenURL/link resolvers and CrossRef).
  2. Develop and promulgate a standard vocabulary of technical, business, and policy-related terms used by web SSO and federated authentication products.
  3. Develop and promulgate a set of “best practice” policy and business practice recommendations for the relationships between customers, licensing bodies, federations, and service providers.

Deliverable 2: NISO Recommended Practice: standardizing user interface presentation for user authentication.

  1. Identify a preferred location for login link and/or login input box (to help users navigate to the appropriate login pages)
  2. Recommend to pervice providers a standard approach for guiding the user to the desired authentication method which include:
    1. Develop standardized GUI flows that will be presented to a user after they click on the login link.
    2. Develop and promulgate best practices in user interface approaches that allow a user to identify their home site for authentication purposes.
    3. Provide content providers with guidelines that address the proliferation of Shibboleth Federations.
    4. Include recommendations on where SP and IDP branding could be inserted.
  3. Working with the various authentication mechanisms, develop standardized approaches for handling automatic login when the url presented at the SP identifies the user’s preferred authentication method and/or authentication provider.
  4. Working with the various authentication mechanisms, develop a consistent approach/link syntax for campus-based software to present a deep link to a service provider which will trigger an automatic login process that bypasses the discovery process.

Deliverable 3: NISO Recommended Practice: Identify approaches (existing implementations?) that allow federated search technologies and portals to leverage existing web SSO authentication sessions of a user when contacting backend Service Provider sites. Federated Search has a unique set of challenges in that they perform searches of licensed content acting as an agent for the user. Since the browser user is interacting with the federated search portal but not directly interacting with the content provider's site, this situation provides unique challenges for a web SSO authentication system.

  1. Work with those package mechanisms that currently support “delegated authentication”. Ensure that service providers have access to the documentation they need to support this feature.

Deliverable 4: NISO Recommended Practice: Provide plans for the promotion and adoption of these Recommended Practices to make the access improvements a reality.

  1. Marketing plan
  2. Business case/justification will be developed as part of the marketing plan.


  1. There are two primary use cases: user arriving at an SP anonymously and with no indication of their home authentication site, and user arriving with an identifier of their home site. (A degenerate version of use case 2 would be arriving and indicating which method/protocol to use but not indicating a home site.)
  2. SPs supporting multiple protocols may use different packages from different vendors to provide support for the different protocols. SPs in general will not want to write additional code to “frontend” a set of packages; instead, they will probably prefer that the various packages expose their own endpoints at the SP. A campus forwarding a user to an SP will know which protocol/package it is using with each SP, and will be able to forward to the appropriate endpoint.
  3. It's very likely that the discovery/login GUI/flow will be different for different protocols. This working group should define a standard flow/sequence that an anonymous user would see from clicking a login link on the front page up to the point where they identify the package/protocol they will use; from that point forward, the user would see a sequence of pages specific to that protocol.