OCLC Developer Network

Identity Management News Archive

Syndicate content

Hosted version of EZproxy now available from OCLC

Calling all EZproxy admins! Happy Hanukkah and Christmas came early this year: OCLC EZproxy is now available as a hosted service. So you no longer have to maintain all the database tables and configuration files yourself, unless you just like doing it. Five libraries have been in pilot with the hosted service since April 2009, and they've helped the cooperative work out any kinks in the system. EZproxy now joins other OCLC services available as hosted versions, including CONTENTdm and ILLiad. What do you stand to gain from moving to the EZproxy hosted service? From the official announcement:
  • Timely addition of new databases
  • Reduced reliance on technical staff for initial configuration or ongoing configuration file changes
  • Peace of mind with a secure environment and security for user information
  • 24/7/365 access monitoring and reporting on usage
  • Elimination of local proxy server (or other hardware) maintenance
  • Automatic updating for bi-annual enhancements
So you'll always run the latest and greatest version--currently 5.3. And OCLC supplies the security certificate, too. In case you're curious, the deployment on cooperative's end is on Linux VM services at the OCLC data center. It currently has more than 2,200 VMs deployed as of 17 November. There are full diesel and battery back-ups for the data center and two commercial power feeds...just in case someone upstream gets crazy with a backhoe--you don't lose your eContent access. EZproxy hosted service sits alongside other recent OCLC innovations to help make it easier (and cheaper) to manage and provide access to eContent, including the WorldCat knowledge base, licensed resource management, and integrated link resolution. Learn more about the EZproxy hosted version at one of a couple introductory Webinars. New and current EZproxy users are encouraged to attend: To get a price quote for your institution to move to the hosted version, send your name, institution and FTE or community served to EZproxy [AT] oclc.org.
Submitted by alicesneary on Thu, 12/02/2010 - 11:13am
in

EZproxy version 5.3 now available

While EZproxy isn't a Web service, a lot of developers/Web people are also tasked with maintaining the library's authentication servers. Thus, we always want to let you know the latest and greatest with identity management, authentication and authorization services. So the latest version, 5.3 is now available on OCLC.org. Here are the details about the enhancements:
  • A new function, Length, returns the number of characters in a string. This functionality is helpful in complex user.txt configurations for verifying and parsing strings. See an example from the official announcement.
  • EZproxy V5.3 now supports the latest Shibboleth Version 2.1 Identity Providers (IdPs) for authentication. This move expands the number of Shibboleth IdPs available to an even wider range--all IdPs from V1.3 forward are now supported.
  • A new option, Option CookiePassThrough, passes ALL cookies through EZproxy to the user's browser. Adding this option provides wider flexibility for the service to work with additional Web sites that may require a cookie to be set.
  • LOGFORMAT now returns the correct number of bytes transferred for https connections. This correction will help libraries more accurately track usage statistics for EZproxy-enabled sessions.
  • There were a number of additional minor fixes to improve the overall stability of EZproxy.
See the full list of changes Upgrade to 5.3 Also note two things:
  1. a hosted version of EZproxy is in pilot and the reports back from libraries using it are quite good. So stay tuned to hear more when hosted EZproxy is ready for production in your library...
  2. As soon as testing is complete, version 5.3.1 will come out that supports NCIP authentication even more fully than v5.3 does today.
Submitted by alicesneary on Wed, 10/13/2010 - 12:40pm
in

New EZproxy Reference Manual now available

For all of you EZproxy administrators, there's a brand new Reference Manual available as a PDF to help you manage all the different directives you may want to specify. Topping out at a whopping 114 pages, we're still thinking the Reference Manual is a work in progress. I mean, 104 Directives is pretty darn good for a first draft--but there are improvements to be had, to be sure. So download it now, peruse at your leisure and send the EZproxy team your thoughts and ideas about what else should/could go in here, and where it could use some additional information. There are already planned updates in the works, of course, and your feedback and insight is always encouraged. Future versions with small incremental changes will be called out with a version number and listed on a yet-to-be-created "changes made to this version" page.
Submitted by alicesneary on Mon, 05/17/2010 - 3:05pm
in

Comments

re: New EZproxy Reference Manual now available

Submitted by Jonathan Rochkind (not verified) on Tue, 05/18/2010 - 8:12pm.

Nice, a comprehensive EZProxy manual is welcome.

Any chance in making this available in html, on the web, ideally split up in appropriate sized pages (per chapter), and so it winds up googleable?

That would make it even more useful. I know there is (was?) some EZProxy documentation on the web, but I don't think it was nearly as comprehensive as this manual, and for some reason it never ended up google-able, and I never end up being able to find it.

re: New EZproxy Reference Manual now available

Submitted by Don Hamparian (not verified) on Thu, 10/21/2010 - 5:34pm.

Sorry to take so long to respond Jonathan. We will check out the google-able problem. We aren't sure how we are going to maintain the HTML documentation going forward. We may consider having the detailed reference documentation in the PDF and not the HTML.

OCLC joins Open Identity Exchange as founding member

Note: the following post was submitted by Andy Dale, our resident expert on all things identity management and authentication. Electronic chickens and eggs keep chasing each other through the internet evolutionary cycle. In this latest evolution, Federated Identity Technology that has been maturing over the last 5 years now has a nascent trust infrastructure that will make it not only functional, but, usable. I have written here previously introducing some concepts of Single Sign-On and Third Party Authentication; these are facets of Federated Identity. I often say that an Identity Federation is one third technology and two thirds legal agreements. It is vital that members of a federation have interoperable technology otherwise nothing works. However the actual glue that makes an Identity Federation useful is the legal agreements that govern behavior of the members. This lets members trust each others' identity assertions, like logins. These legal agreements have to be deeply crafted so that they can satisfy the federation members in the complex regulatory frameworks in which they operate. The InCommon federation has legal agreements that let US academic institutions federate identity infrastructure within the Family Education Rights & Privacy Act (FERPA) regulatory framework. OpenID and InformationCards have been flourishing as internet scale identity technologies that have been embraced by companies like Google, VeriSign, PayPal, Verizon and many more. All of these companies have been willing to issue 'portable identities' to their users but few of them have been willing, or able, to accept identities from other providers. The technology has been there but the legal infrastructure has been missing to make this all useful, in this wider context. Last week at RSA; the premier annual online security conference in San Francisco, the formation of a new organization was announced: Open Identity Exchange (OIX). OIX will establish a framework of 'standard' interoperable legal agreements. These agreements will be vetted and accepted by members of OIX and used to establish 'networks of trust'. OIX does not try to establish a single network of trust as the legal agreements for different types of activities will clearly need different legal agreements. Health Record sharing has different demands than Photo Sharing. The first trust network that has been established will enable people with OpenIDs or InfoCards issued by Google, Equifax and PayPal to access US government web sites. OCLC is a founding member of OIX and holds an advisory board seat. We are there because we see the potential for OIX to provide the library community a vital piece of infrastructure. Over time we see the possibility that the OIX infrastructure can be used provide identity trust between libraries, consortia and content providers and greatly lower the barriers of access to content. The promise is a world in which a patron can log in to their library, large or small, K-12, Public, academic or special and gain direct access to all of the resources that they should be able to access. We will keep you informed as this exciting new space evolves.
Submitted by alicesneary on Wed, 03/10/2010 - 1:43am
in

EZproxy 5.2 now available for download

Back to school time for IT staff at libraries usually involves a handful of new databases to configure and an updated version of EZproxy access and authentication software. This year is no different: the latest version (5.2) is now available. A snippet of the enhancements going on in this release:
  • New directive for use in LDAP authentication, which allows the search filters that are used in login to also be used when reading attributes.
  • EZproxy now allows vector notation in the user.txt file, to give III systems more flexibility with contact information.
  • The sample config.txt updated to include more stanzas for OCLC resources, so it's easier and faster to add a new database to your configuration file.
  • See the full list and get the details on all the 5.2 changes.
Download the latest version of EZproxy 5.2 If you have specific questions about your installation, the EZproxy listserv is usually a good first step.
Submitted by alicesneary on Tue, 09/01/2009 - 9:20am
in

Introduction to Information Cards

Information Cards introduce a new paradigm in on-line authentication that replaces conventional Username and Password login. The new paradigm is based on the very familiar 'real world' experience of presenting credentials. When I want to purchase something and I don't have cash; I present a credit card. When I want to rent a car I pull out my driver's license and when I want to borrow a book from the library I pull out my library card. Despite the number of cards I may have in my wallet; 3 credit, 1 debit, healthcare, dental care, library, 3 museum memberships, 2 frequent flyer, etc... It is very easy and intuitive for me to select the right card at the right time. The mechanics of trust that 'real life' cards represent is also interesting. When I present my driver's license, the 'claims' on the card; age, address, etc... are packaged in such a way that the person looking at the card can establish 'trust'. They can compare the picture on the card to my face. They can compare the age represented on the card to their view of how old I am; they can compare the eye-color listed to my eyes. Finally, they can identify the state that issued the card. The trust mechanics dictate that: The card does not appear to have been tampered with. The photo to face matching indicates that this card was issued to this person by the State of California. I trust the State of California I can therefore trust the claims on this card. The interesting thing to note is that there is no need for trust to be established between the person presenting the card and the person accepting the card. The person accepting the card only has to trust the State that issued the card; even though the state isn't present, or in any way involved in the transaction. This is similar with credit card processing; a shop keeper doesn't trust you to give them money 'later' ("I'll gladly pay you Tuesday for a hamburger today"), but they do trust Visa, the issuer of the card. Information Cards bring this paradigm and these mechanics to our online experience. When you login to a web site with Information Cards (I-Cards) you are asked to select an I-Card from your virtual wallet. The analogy isn't perfect so the wallet, otherwise known as; The Card Selector, has some smarts to make things easier. The Card Selector, which is a piece of 'secure' software running on your machine, remembers places that you have logged in before. Each time you start to log into a site that you haven't logged into before, you get an informational dialog that tells you about the site you are logging into. This largely eliminates concerns about 'phishing' attacks, scams where a site pretends to be a site it's not to get your username and password. Even if a site manages to fool you into logging in with an I-Card ; they don't get something they can use somewhere else. When you click on the 'login' link, the site you are trying to log into tells your computer what it wants to know about you. If you are trying to leave a blog comment that might just be a nickname, if you are trying to purchase beer it might be a claim that you are over 18 years of age. When the wallet opens, only those cards that are capable of satisfying the sites 'policy' (what the site wants to know) are selectable. This interaction means that the user doesn't have to go through and select from ALL their cards every time they login, the choice comes down to selecting from one or two for any given context; Visa or American Express? If you want to play with Information Cards the best place to start would be http://www.azigo.com/icards.html this site is provided by Parity Inc.; THE leaders in implementing this technology. If you click through the Equifax Card sign-up process you will have the Card Selector installed and get your first i-Card, one that can 'prove' you are over 18 (if you are) without exposing any other information about you. The Minuteman Library Network is the first Library Card i-Card project and probably of special interest to the readers of this blog; I am working on this project and will keep you informed of its progress.
Submitted by admin on Wed, 03/11/2009 - 10:40am
in

What is SSO?

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.
Submitted by admin on Tue, 02/10/2009 - 1:48pm
in

Comments

re: What is SSO?

Submitted by Pamelalice (not verified) on Sat, 05/23/2009 - 1:55pm.

I really liked this post. Can I copy it to my site? Thank you in advance.

Which Andy is that? Are you sure?

My name is Andy Dale and I am a new member of the OCLC team. I am honored to have been invited to add my voice to the OCLC blogs. My title at OCLC is Consulting Software Engineer, Identity Management and Authentication. Over the last couple of years there has been a race to put the suffix '2.0' on every concept known to man. Tim O'Rielly is often credited with first coining the term Web 2.0 back in 2003 and since then it's been a rush to the door 2.0. One of the 2.0's that I have been very involved with is Identity 2.0 and I am now starting to work to see how Identity 2.0 and Library 2.0 interact. In my blog posts I will try to introduce some of the concepts behind Identity 2.0 and how they might be leveraged to enhance the library experience. My knowledge of Identity technology and policy is deep; my knowledge of how things REALLY work in libraries is nascent at best. I will speculate and hypothesize about the collision of the ideas that drive Identity 2.0 and the use-cases and pain-points of working libraries. I look to you, the readers of this blog, to help correct my misunderstandings and help me find the points where my particular knowledge can be leveraged to add value to library software implementation. Some of the things that I will blog about soon are: OpenID, Information Cards, Claims Based Authorization, Single Sign-On and Federated Authentication. At times I will write high level explanations of the concepts, at times, forgive me, I will delve into the nuance of one representation of an identifier vs. another. I look forward to this dialog with the library community. If you want to contact me you can do so through my i-name by clicking here: =andy.dale (More about i-names and contact pages soon :-) )
Submitted by admin on Thu, 01/29/2009 - 5:29pm
in

Follow the OCLC Developer Network:

The OCLC Developer Network supports the use of OCLC Web Services—a set of tools and APIs that expose data and services for WorldCat and our member libraries and partner institutions or companies. learn more »

© 2010 OCLC Domestic and international trademarks and/or service marks of OCLC Online Computer Library Center, Inc. and its affiliates


Powered by Drupal, an open source content management system