Between the built-in authentication support and the catch-all CGI mechanism, EZproxy does a decent job of handling a diverse set of authentication scenarios. What is implemented is the 80-90% use case, which -- as a developer myself -- I can appreciate. Once you step outside the realm of what is implemented, though, about the only option left available are to use the CGI interface as glue logic into other systems. This can be made to work for many things, but not everything.
For example, RADIUS is supported, but I do not know of any way to flag an account in RADIUS as an administrator account for EZproxy. Nor is RADIUS accounting support implemented (not that many people would use accounting in a typical setting, but in a hosted environment it could open up interesting options for usage-based billing).
One thing that I would really like to have, though, is better Kerberos support. There is already some level of Kerberos built into EZproxy for Active Directory support, but I cannot setup a SPNEGO authenticated connection leveraging my existing non-Microsoft Kerberos servers, because Kerberos is not able to be configured independently of Active Directory.
What would be nice is if OCLC would adopt a modular interface for EZproxy so that those of us with both the skill set as well as the proverbial itch can write extensions to EZproxy that close the feature gap on the 10-20% case that is left out.
If OCLC does go down the modularization route, let's not forget about service handling. Look at current services that require a magic token to connect, like Books24x7, Netlibrary, eBrary, etc. These services perform a handshake with the vendor to retrieve a token value, and then redirect the user's browser into the service using the token as the authentication key.
There is no reason that EZproxy could not use a scripting language like Lua (which is the scripting language behind a surprising amount of commercial programs and games) to perform these handshakes, making the service handling as flexible as the database stanzas are now. With the right design, the scripting interface might even be able to make some of the database stanzas simpler.
Take the recent phenomenon of .NET applications that use the _VIEWSTATE variable to maintain application state as described in this MSDN article. It is just screaming for better EZproxy support. Creative use of the Find/Replace directives can handle populating the username and password fields, and then inject JavaScript into the page to auto-submit the form for a seamless login, but each of these has to be hand-crafted today.
Wouldn't it be nice if EZproxy used Lua as a macro language, and the EZproxy user community could write a function to handle this case more gracefully and share that code the same way we share database stanzas today?
No comments:
Post a Comment