February 2009 Archives
Most of my fellow OCLC Developer Network staffers are still at Code4Lib soaking up all the great ideas, making technology intersections and creating new possibilities for library development projects.
For me, I got stuck in a snowstorm on the way to the preconference session OCLC sponsored, the "OCLC Grid Services Boot Camp." So I won't tell you my reflections on the morning session, because I wasn't there. But Richard Wallis did, with a nice summary over on Panlibus.
Karen Coombs over at Library Web Chic also uploaded a video demo of the WorldCat Search API during the conference.
In the afternoon, Ralph LeVan gave an overview of SRU and CQL, and I showed off some of the social networking features of WorldCat.org...which sparked an interesting discussion about ways to help faculty and students make better use of the tools available.
In looking through the list of attendees, there were a number of Perl and Java developers--with some interest in Groovy--and lots of people keen to do more with mobile. (For example, Birkin showed me the MIT mobile site for iPhone users. How cool would it be to have library materials, right there alongside the shuttle service info?)
All the powerpoints from the session are linked off the pre-conference page above, so even if you couldn't make it to Providence, you can still see Flickr photos and participate.
One of the outcomes we talked about from the session was to think about a series of Webinars, or maybe just short video clips that show different uses of the developer tools now available from OCLC. Would something like that be helpful for you?
One of the hottest issues in Identity Management is often referred to as SSO; Single Sign-On. However it is a horribly misunderstood and misused term. I will try to give a brief overview of what SSO is and isn't.
What most people mean when they say SSO is the user experience of accessing multiple services and systems but only having to 'log-in' once. On the face of it SSO sounds great but there are some pitfalls that we have to be wary of. If we aren't very careful, the 'ease' of SSO is bought at the cost of privacy.
The type of SSO that I am going to explore is the "HTTP Redirect" SSO mechanisms that are widely deployed for SSO on the web. This includes OpenID, Shibboleth (Web SSO), SAML (WebSSO), FaceBook, Yahoo! and Google, to name a few. These protocols differ in many details and have different strengths and weaknesses but they all share the same underlying HTTP Redirect mechanism. The basic pattern is this:
1. Jane navigates to a web-site and she wants to log-in using a username and password that support SSO.
2. Jane clicks on the 'login' button on the page.
3. Jane has to tell the web-site who her SSO service provider is. This is known as the Where Are You From problem, otherwise known as WAYF. More about WAYF in a moment.
4. Once Jane has told the web-site who her SSO service is; a HTTP Redirect is sent to the browser to send Jane off to her SSO service.
5. At her SSO service Jane is asked to provide her UserName and Password.
6. If Jane convinces the SSO service that she is, in fact, Jane, then she is returned (via HTTP Redirect) to the original web-site with a 'token' that says "I am SSO service XYZ and I believe this is Jane"
7. The web-site and SSO service communicate in such a way that the web-site can validate that this is really SSO service XYZ talking AND if it knows and trusts service XYZ it can go ahead and accept that this is Jane.
At this point we have performed 3rdParty Authentication or Federated Sign-On NOT SSO.
8. Having done what she came to do Jane now navigates to another web-site.
9. When Jane arrives at the second web-site she is NOT recognized as being logged in. This site has no knowledge who she is or that she has logged in somewhere else before. If Jane wants to access 'protected' resources at this web-site she is going to have to click on the log-in button.
10. Again Jane will be asked Where Are You From and she will select her SSO service provider.
11. The web-site will then send Jane off to her SSO provider asking... "Who is this?"
12. Because Jane logged into her SSO service just a few minutes earlier the SSO service doesn't ask Jane for a UserName and Password this time, it immediately returns back to the web-site with a 'token' that says "I am SSO service XYZ and I believe this is Jane"
13. The using the same trust validation as above the web-site can now believe that this is Jane
And Jane only logged in ONCE... that is SSO.
Jane still had to click on login twice and still had to provide her SSO service twice but she only Signed-On a Single time.
There are variations in this flow, OpenID nicely shortcuts the double SSO service provider selection BUT you have to type in your UserName twice.
The most common expectation of SSO that is not satisfied by the flow described is "why didn't the second site just 'know' that I had already logged in and who I was?" Apart from the fact that would be technically difficult the answer is actually that REALLY you wouldn't want that behavior... Once I explain why:
If SSO worked that way, when you logged in once, everywhere you went on the internet would know who you are. Not just an IP address, they would be getting a message "here's Jane". All of the web-sites on the web could talk to each other and work out EXACTLY which sites you visited and which ones you didn't. That is generally considered to be a terrible breach of privacy. In order to avoid this privacy leak clicking 'login' remains an explicit action that the user must take. The action no longer means: "I want to enter my username and password" but now means "I'm OK telling this site who I am."
There are ways for 'closely connected' sites to shortcut this experience. Handing a user from their Local Library System to the Consortia Meta-Search interface; a handoff that is between trusted parties; Janes identity CAN be passed from one service to the other providing the 'seamless' SSO that we would love to have. But you can't be sure that Jane was OK being identified at the second system unless you make the action explicit. As a service provider you have to make very careful choices between seamless SSO and user privacy.
Rather than going on now:- You can tune in later for "SSO using Pair-Wise Identifiers to protect your privacy", "How and Why OpenID is different from Shibboleth Web SSO" , "Why you MUST trust your SSO service provider because they know a lot about you"...
Please ask questions if I haven't been clear... Please let me know if you think I have said something misleading or wrong... I'm just trying to start a conversation here.
xISBN bookmarklets now supports thousands more libraries by integration with Worldcat Registry.
The previous xISBN bookmarket supports more than 300 libraries, however, the list was manually maintained and it's challenging to keep these links up-to-date, By ingesting good Registry OPAC information into xISBN bookmarklet, we are able to support thousands more libraries in a more sustainable way.
xISBN bookmarklet automatically pulled new information from Worldcat Registry on a monthly basis, so if a library maintains up-to-date information in Registry, its data will be automatically reflected in xISBN bookmarklet. Furthermore, we have also developed mechanisms to validate and improve OPAC linking templates in Registry during the process.
The previous xISBN bookmarklet is still maintained in http://xisbn.worldcat.org/liblook/
Written by colleague Joanna White, Product Manager of the WorldCat Registry.
Users can use a new Registry Web Service to retrieve an institution record in XML using the OCLC symbol.
For example:
http://worldcat.org/webservices/registry/lookup/Institutions/oclcSymbol/OCL?serviceLabel=content
Additional notes.
Q: What happens when no records are found?
When no WorldCat Registry record is found for a given OCLC Symbol , the web service returns "0" results in the XML response while the user interface presents options to adjust the search query.
Q: Do I need to adjust my service for searches by special characters?
Yes. Services that utilize these web services have to accommodate for special characters present in some OCLC symbols, for example symbols such as "A#2".
Q: What is included in the returned content?
If a user is not authorized, then the "public view" of the XML data is returned to the user. If the user is authorized, then the "authorized" version of the XML data is returned to the user. For example, "authorized" users will see IP Addresses for the record. More information on all the data fields is available with Data Fields Quick Reference at http://www.oclc.org/us/en/registry/support/Registryquickreference.pdf
WorldCat Registry detailed search is also available as part of our more general Registry Search web service. This SRU service returns HTML to a web browser but XML to software agents (e.g., curl)
Example of SRU search:
http://www.worldcat.org/webservices/registry/search/Institutions?version=1.1&operation=searchRetrieve&recordSchema=info%3Arfa%2FrfaRegistry%2FschemaInfos%2FadminData&maximumRecords=10&startRecord=1&resultSetTTL=300&recordPacking=xml&query=local.oclcSymbol+exact+%22OCL%22+not+local.logicalDelete%3D%221%22&x-info-6-deletedRecord=
Details about the three WorldCat Registry web services are listed here http://www.worldcat.org/wcpa/content/affiliate/default.jsp
