In re-reading my own message, it occurred to me that my statement
about choosing JSPWiki's user management system v. relying on someone
else's was ambiguous.
What I meant to say is this: JSPWiki deployers should, at deployment
time, choose whether they'd like to maintain a private wiki (which
manages its own identities) or a public wiki (which accepts identities
from outside OpenID identity providers). This would be the either/or
proposition.
What I did NOT mean to say is that JSPWiki's native user management
system would be deprecated if we added OpenID support -- in other
words. I wasn't asking the dev team to pick one solution over the
other as the focus of future development efforts.
On Jun 17, 2008, at 10:47 AM, Andrew Jaquith <[EMAIL PROTECTED]>
wrote:
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
