Initial ideas about design

• Abstract class http-server with a specific interface needed by final classes
• Subclasses of http-server: http-server-hunchentoot, http-server-ucw, http-server-aserve, etc, implementing concrete functionality
• Similar base class / subclasses for HTTP client and storage
• Base class openid-provider, with slots for http-server, http-client and storage that are filled on make-instance
• Similarly for openid-relying-party
• Macros for easily instantiating openid-provider and openid-relying-party for common use cases (def-openid-provider wrapping DEFVAR as well? make-openid-provider returning instance?)
• Some parts of internal workings of openid-provider revealed as documented generic functions

This would allow multiple levels of customization:

• Subclassing e.g. abstract http-server directly for brand new server support
• Subclassing concrete http-server class to change some parts of behaviour
• Specifying around/before/after methods on API generics for http-server or some concrete subclass for small modifications, tracking or logging
• Ditto for http-client and storage
• Subclassing and around/before/after methods for customizing top-level openid-provider or openid-relying-party classes

Logging

Some way of loging will also need to be supported, and customizable to some extent. I think not to overburden myself here and just use some logging library (log5? arnesi?) as the default, and provide CLOS generic for final provider/relying party classes for user to override. If user needs support for logging other than default, it will probably need to be put into existing, customized system anyway.

Storage

Actually, storage has double use:

• One is storage of association handle between request: this is relatively short-term since it is used once for each authorization, and

initial storage may be just a hash table in memory; at the project end, I'd like to have also some kind of shared storage (postmodern, memcached, sql) for this info, to allow horizontal server scaling without need for sticky sessions;

• Second is storage for usernames and passwords, which needs to be permanent, but also needs to be way more flexible than only usernames

and passwords: OpenID gives the provider full freedom for actual authentication mechanism. This is one more place we will need to be customizable.

I think I will start with in-memory keeping of association handles, and simple cl-store alist of usernames and passwords authorized by simple HTTP AUTH and work up from there. How to make actual authorization customizable enough - I have to think it over.