Recently I've been thinking about looking at adding OpenID support to our own products and was also about to look at the openid4java library. One thing I've not really seen mentioned anywhere is the notion of associating an OpenID account with an existing user.

Every example I've seen so far logs you in and creates an account for you, but if I already have an account I might just want to associated that with my chosen OpenID identity.

If this was done and both Confluence, JIRA, Bamboo were OpenID providers/consumers (and Crowd as a provider - not sure it would suite as a consumer but you never know) it could make for an interesting low-cost SSO solution between the various Atlassian applications (not as powerful as using Crowd thou).

Currently I have my Confluence install slaving its os_user configuration to JIRA but this is somewhat messy - OpenID could be an interesting low-cost way of dealing with this.

Don't get me wrong, I think this is a great move... Confluence is by far the best wiki out there in my opinion, and being able to integrate it into a company or institution's existing infrastructure is very important. I did however figure that if anyone was going to OpenID-enable confluence, it would be someone outside of Atlassian, seeing as how it could be seen as a competitor to Atlassian's own "Crowd" product. Would Atlassian consider supporting OpenID in light of their own competing product?

I don't think you should treat OpenIDs as usernames and sign them up as completely separate accounts. It's far more useful to create a "real" account and then associate it with an OpenID. That way you don't end up with two classes of users, and more importantly you allow people who have already created an account to associate it with their OpenID.

I recently wrote about how OpenID could help with behind-the-firewall SSO, where every user in an organisation gets theirusername.internal.example.com as an OpenID and the intranet applications (such as Confluence) are configured to only accept OpenIDs of that format: http://simonwillison.net/2007/Feb/25/six/

As for your first comment about associating an openid with an existing account, I'd imagine a real OpenID implementation would direct the user to a "signup" or "new user" form on first login. Usually, an application will need to know more about the user than their user name, and perhaps the application will even prefer to use a different login name style. Although it is possible for an open id provider to expose custom attributes like email address, you can't rely on it being available. On this sign up screen, you could have a little tool that allows them to associate their open id with an existing id.

As for using OpenID as a way to SSO between Atlassian or other internal applications, I'd imagine it would work just fine - but for user name sharing and SSO only. The big missing piece is groups, as most organizations have a huge group database/LDAP somewhere, which you'd want to leverage. Still, I'd bet a custom authenticator that uses OpenID and also hooks into internal user directories would be nice, although at that point, you've just reinvented a fraction of Crowd for a whole lot more development cost :)

Will: actually, Crowd has SSO support on its roadmap, I believe. As for overlap, as I understand it, Crowd is really more about bringing together multiple user data stores within an enterprise, giving them a single interface both for administrators and application integrations. I can't speak really about the "official" adoption of OpenID within Atlassian as this post was really about something I did on my free time, but from those I've spoken to, they seem interested.

Simon: Great post! I wish I could have made that talk as it sounds pretty timely. I completely agree a real OpenID implementation wouldn't use the id as the user name, but hey, mine was a weekend hack :)

"Would Atlassian consider supporting OpenID in light of their own competing product?"

Even if OpenID was a competitor to Crowd (which really, it isn't) I can't think of a single time that a company saying "We're not going to support [open standard X] because we want people to buy [proprietary product Y]" has been good for our industry. And I can probably only count on one hand the number of times it's been any good for the company.

In order for authorization to be supported, the folks in the OpenID community would need to have the desire of moving past the basics of identity. Likewise, the features of an identity selector (e.g. Cardspace) will need to change. IMHO it seems no one really cares to talk deeper about authorization as it may require too much work on their parts...

As an FYI, we have posted a blog/interview entry about how in the future Atlassian will be supporting OpenID through the Crowd application. In short we to not see OpenID as a threat to Crowd but as another way to extend the program and have companies deploy their own OpenID servers.

You can view the article here: http://blogs.atlassian.com/news/2007/03/crowd_connects.html

Hi! Can You show me some code how redirect from authenticator to OpenId server?

This has been one of my gripes after investing in Crowd (and CrowdID). I had originally expected CrowdID to act as a proxy to external OpenID servers, creating a federated authentication style service; this would have allowed companies running private instances of say JIRA to off load the user management of customer accounts to the customer's themselves and concentrate on whatever it is they do best.

The idea would be to create a trust for an external OpenID server and treat it like a normal Crowd directory, the only difference being that you would associate security groups to the whole directory rather than individual users. Going one step further, what would be really cool would be to impose a naming convention ie. email address or apply group memberships against users using regex :D