incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.jaqu...@mac.com>
Subject Re: OpenID support in JSPWiki?
Date Tue, 17 Jun 2008 16:57:18 GMT
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 <andrew.jaquith@mac.com>  
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/%3C12145556.1196892224922.JavaMail.jira@brutus%3E
>>
>>  message from Harry Metske (Jan 08)
>>  http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-dev/200801.mbox/%3C17193300.1199193223830.JavaMail.jira@brutus%3E
>>
>>  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
>> jack@jackpot.uk.net (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
>

Mime
View raw message