Skip to Content.
Sympa Menu

inc-lib-vendor - Re: [InC-Lib_Vendor] Draft Agenda - May 1 - 1PM (EDT)

Subject: InC-Lib-Vendor

List archive

Re: [InC-Lib_Vendor] Draft Agenda - May 1 - 1PM (EDT)


Chronological Thread 
  • From: Adam Chandler <>
  • To: David Kennedy <>
  • Cc:
  • Subject: Re: [InC-Lib_Vendor] Draft Agenda - May 1 - 1PM (EDT)
  • Date: Fri, 1 May 2009 10:33:55 -0400
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Rj/9CzdmZPUEiEZvjF3OXIaQOdICrHq7o+Ax58747rWi3rNGHFw/6mmr2EjmnRbFOk H7vNOh526EZLFR5BS6HfBy/UiFQeZ4QomawymPcvjDYVwZBVVGegkXSrkaEFUMs4eYPg RfIjMrKKKvBcJYaFlek2qEx8DsGhtE5nmQKKQ=

Dave,

One more item for the agenda, please. I'll report on the status of the NISO SSO Work Item.

- Adam

Here is the NISO Work Item text:

<work item>

Single Sign-On (SSO) Authentication:

A Proposed NISO Work Item

DRAFT: February 6, 2009

 

The following proposed work item is submitted on behalf of Oliver Pesch, Chair, NISO Board of Directors, and Chief Strategist, E-Resources, EBSCO Information Services

 

 

Work Item Title:

Perfecting single sign-on (SSO) authentication in an imperfect world: Achieving seamless, item-level linking through single sign-on authentication technologies in a networked information environment.

 

Background and Problem Statement:

Accessing information in a networked environment has been a reality for most user communities for over a decade. With the advent of hosted aggregated full-text databases and the proliferation of e-journals and e-books, a user’s search for information often takes her to a number of different online hosts and platforms. When those information resources are commercial products, each platform requires the user to be authenticated and, as a result, that user may have a different identity on each platform. The problems caused by having to manage multiple identities have lead to the development of so-called “Single Sign-On” (SSO authentication) technologies, such as Athens and Shibboleth. With these technologies, the user can access all compliant content platforms using the same identity. Athens and Shibboleth have both been designed in a way that makes the authentication process (and thus the site-to-site navigation) completely invisible if the user already has an active session.

 

The idea behind SSO options like Athens and Shibboleth is that the user should be able to move seamlessly between sites without being confronted with authentication challenges. Both Athens and Shibboleth work almost perfectly when the user accesses a compliant site and that site knows the authentication method to use (most sites support multiple authentication methods). The most common method for a content site to know the authentication method is by having the user access the site using a special login URL specific for the authentication method to be used (e.g., http://content.example.com/athens_login.aspx). When libraries set up access pages to the resources they subscribe to, they will often use the appropriate login URL and thus achieve the seamless access desired for their users. However, if a user who is authenticating using an SSO method accesses a content site using the generic login option, they will most like be presented with a login screen with the option to select the Athens or Shibboleth link. The user must be trained to click the appropriate link to gain access.

 

While the library can control the “front door” access by using the appropriate URLs on the library’s resources page, they have far less control when it comes to item-level linking. More and more access to content sites comes as a result of linking from other sites, not through the content site’s search pages. Many publishers are reporting that more than one half of links that access their full text come from Google alone. To complicate matters, from the SSO perspective the links between sites, even if they are driven by a link resolver, tend to be generic in nature. For scholarly information, access using the DOI tends to one of the most prolific linking mechanisms. SSO-authenticated users accessing content via linking are most likely to be confronted with an authentication challenge if it’s their first access to the site—even if they have an active SSO session.

 

Making the SSO environment work better (smarter) will certainly help increase the success of users getting to the content to which they are entitled; however, it is probably fair to say that the majority of content hosts are NOT compliant with one or more of the SSO authentication technologies. Library users are required to operate in an environment that includes a mix of authentication technologies with IP authentication being the most common. An effective solution needs to address this hybrid environment, and at the very least, take into consideration the needs of IP authentication, proxy servers and how they interoperate with SSO authentication technologies.

 

This work item is about exploring options and creating recommended practices to allow a content site to know which authentication method to use without special login URLs. Possible solutions range from providing a generic mechanism for passing the authentication method from site to site; use of cookies to remember the authentication method that was used the last time the site was accessed by that computer; and/or providing a mechanism to discover if the user has an active session for one of the common SSO authentication methods.

 

The expectation is that there is a continuum of options with varying levels of complexity that can be employed by content sites that will greatly improve the seamless access experience for users authenticated with the most common SSO technologies.

 

Statement of Work:

The goal of this work item is to explore practical solutions for improving the success of SSO authentication technologies for providing a seamless experience for the user and to promote the adoption of one or more of these solutions to make the access improvements a reality. To achieve this objective, this proposal is to convene a NISO working group to explore the problem and make recommendations. The following would be their expected deliverables:

 

  • Create a white paper that describes the problem and explores possible solutions
  • Conduct a web seminar/thought-leader meeting to further engage the community
  • One or more Best Practice documents describing possible solutions
  • An education plan/adoption plan for seeing solutions implemented.

 

Partners and Participation:

The following organizations/types of organizations should be involved.

 

  • Librarians implementing SSO authentication methods such as Athens and Shibboleth. (Representing users)
  • Athens and Shibboleth representatives. (To help explore/implement authentication discovery options)
  • Representatives of commercial content hosting systems, including publishers, A&I services and aggregated full text databases. (They would need to implement any authentication)
  • Representatives of web search engines, such as Google and Yahoo. (They may be able to introduce personalization options to pass along authentication preferences).
  • CrossRef (Any authentication type processed via a URL would need to be passed along in DOI-based linking)

 



</work item>

On Thu, Apr 30, 2009 at 12:16 AM, David Kennedy <> wrote:

InCommon Library - Vendor Subgroup
May 1, 2009 - 1PM (EDT)

Agenda
----------

1) Review charge  [attachment:  LibIncVendor - Goals.doc]

2) Review proposal for subgroup tasks.  [attachment:  LibIncVendor - Proposal.doc]

3) Discuss logistics for the group:  communication, participation, timeline, documentation

4) Discussion of prioritized vendors



Conference call information:
1-866-411-0013
PIN: 0141950#



Let me know if you have any additions or changes to the agenda.



-----
David Kennedy
Systems Programmer
Perkins Library, Duke University
(919) 613-6831




Archive powered by MHonArc 2.6.16.

Top of Page