Murray --
As an industry analyst (my "real job" when I'm not slinging code for
JSPWiki), I have written extensively about OpenID professionally. It's
tremendously important, and we will definitely support it. As you
know, it's on the roadmap for JSPWiki 3.0.
In the 2.8 release cycle, I've made some changes to the AAA system
that will make OpenID easier to implement in 3.0. First, the
AuthenticationManager has been refactored to better support external
authentication mechanisms, such as container and ServletFilter-based
approaches. So, if you use something like ACEGI it should be simpler
to integrate -- just wire up the ServletFilter and JSPWiki will pick
up the credential exposed by the http request wrapper.
But, of course, that's a bit of a dodge -- ultimately we want to
provide our own implementation that will offer a nice "out of the box"
experience. On that front, in 2.8 I've made two other key changes that
should pave the way for OpenID support in 3.0:
* The JAAS/LoginModule system has been simplified and made "portable,"
removing the need to configure it at JRE startup. It is now configured
exclusively through jspwiki.properties and not via an external JAAS
config file. That should help when we write the LoginModules for OpenID.
* UserProfiles are now extensible via the getAttributes() method,
which returns a Map<String,Serializable>. The XML and JDBC user
database implementations have been changed to persist these attributes
too. Why is this important? Simple: OpenID will need to store all
sorts of things into the user's profile (for example: the URL of their
identity provider). Rather than guess what those attributes might be
now, it was easier to simply allow profiles to store generic key/value
pairs.
So, that's what's in 2.8. What about 3.0? I have been thinking about
this too. Here are the key questions we must provide answers for, and
my tentative stabs at the answers themselves.
1. What versions should we support:
Tentative answer: OpenID 2.0, with Simple Registration support. This
will allow JSPWiki to request access for, and extract external
identities' e-mail addresses and full names at time of login.
2. Which libraries would we use?
Tentative answer: the Google/SXIP libraries seem the most mature, and
up-to-date standards-wise. It's also BSD/Apache licensed.
3. Should OpenID be a relying party for others' OpenIDs, or serve as
its own identity provider as well?
Tentative answer: I feel strongly that JSPWiki should consume other
OpenIDs, but NOT produce for other sites to consume. Rationale: there
are plenty of high-quality, free OpenID identity providers out there,
with much better operational discipline and strong authentication
options than any JSPWiki site operator is likely to provide. VeriSign,
Google, Yahoo! and many others are good OpenID identity providers; we
should rely on their systems rather than assume people might want to
trust ours.
4. Would OpenID authentication supplement -- or replace -- JSPWiki's
native authentication system?
Tentative answer: My instinct says that OpenID authentication should
be an either/or proposition. Either you use JSPWiki's built-in
authentication system to manage its own identities, OR you rely on
external identities, but not both. It would be too messy to support
both simultaneously, and frankly I'd rather start encouraging people
to use outside identity providers anyway.
5. What about CardSpace and SAML?
Tentative answer: If there was a magic Rosetta Stone library that
would allow us to support all four major Internet identity standards
(OpenID, CardSpace, Liberty Alliance, SAML), that would be great.
Unfortunately, there isn't. The closest is the Higgins project, but
frankly the documentation sucks, and they are limited to just SAML and
CardSpace at the moment. Regardless, these other standards are
important -- and we should plan for a day when we can support them.
That is a major dodge, I know. But for kinds of things that JSPWiki
does, OpenID is the best choice.
6. If JSPWiki relies on OpenIDs issued by outside identity providers,
how will the identity attributes be represented in the user profiles?
Will there even be user profiles per se?
Tentative answer: From the developer perspective, it would be
completely transparent. The UserProfile would still be the
UserProfile, and the same attributes (e-mail, full name) would be
accessible via the same methods. However, because these attributes
are, in fact, managed by outside entities we ought to forcibly refresh
them at time of login in case they have changed. In other words, the
OpenID login process would ask the identity provider to always supply
the e-mail addressa and full name, which we would stash in the
UserProfile just like we always do.
That said, we might not want to *persist* the full name or e-mail
address for privacy reasons, and in fact I suggest that we do NOT. But
it could be problematic for things like e-mail alerts if we don't, so
we might have to (sigh).
7. Should we accept OpenIDs from any identity provider, or just a few?
Tentative answer: I'd strongly recommend that we use a "whitelist"
approach to identity providers. That is, we'd pick some good ones that
are known to be reasonably secure and reputable. The list of
acceptable OpenID identity providers would be provided by default, but
would be configurable if the user wanted to add more. Some
suggestions: Yahoo!, Google, Technorati, VeriSign, Orange Mobile. From
the end-user standpoint, it's much easier to ask a user to "log in
with their Yahoo! ID" and provide a nice drop-down picker, rather than
ask them for something as weird-sounding as their OpenID URL.
8. What would the user experience be like?
The user experience should be as simple as possible. A great example
is JanRain's ID Selector project. We should aim to do something like
that, if not actually integrate the ID Selector directly.
On Jun 17, 2008, at 6:44 AM, Murray Altheim wrote:
Hi all,
A few months ago at a conference a proponent of OpenID made
a presentation about the state of the project. Afterwards I
talked with him about the possibilities of getting OpenID
support into JSPWiki. He mentioned that he'd talked with
Janne last year sometime and that it would definitely be a
win-win for everyone. I'm trying to follow up to see if
anyone knows of any existing work being done in this area.
We're interested in pursuing this and *may* be able to
contribute developer time and/or funding -- though I myself
am in no position to make an actual offer (only suggest it
might be possible, as I'm not in control of a budget).
We're looking at various AAA alternatives for single sign-on,
and there's various other agencies as well trying to figure
out what direction to take, so this goes well beyond wikis.
We're also looking into alternatives such as Shibboleth (SAML),
etc.
References:
JSPWIKI-94 New Feature (from Janne)
http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-dev/200712.mbox/[EMAIL
PROTECTED]
message from Harry Metske (Jan 08)
http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-dev/200801.mbox/[EMAIL
PROTECTED]
OpenID-LDAP (i.e., LDAP backend)
http://www.openid-ldap.org/
Using OpenID (article)
http://www.theserverside.com/tt/articles/article.tss?l=OpenID
OpenID4Java (Google Code)
http://code.google.com/p/openid4java/
OpenID (Wikipedia)
http://en.wikipedia.org/wiki/OpenID
[OpenID] Webapp OpenID Login Filter (defunct)
http://marc.info/?l=openid-general&m=120370812118744&w=2
OpenID prototype using JSPWiki (defunct)
http://openiddirectory.com/wolf-s-436.html
Regarding those last two posts, I've sent a message off to
[EMAIL PROTECTED] (Jack) to see if there's any reply.
Any information very welcome.
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com>
=== = =
http://www.altheim.com/murray/ =
= ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk =
= = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
