Tag Archives: integration

Integrate Web Applications Vs Integrated Authentication

I’ve been trying to integrate web applications for a while now on ivany.org. Basically, I have WordPress and Gallery “integrated” into one site where it’s relatively seamless for the user. It works OK for the most part but I’ve come to the realization that I don’t really want integrated applications. What I want is integrated user control and authentication.

Why does every single web application have to have it’s own userid/password/access management? Why can’t they all just share some common thing? I think there are a couple different ways to achieve this. The first one is to use something common like a user’s email address. Instead of getting the user to create a “username” or “login name”, just use their email address. It’s pretty much guaranteed to be unique unless you have two users sharing the same email but then just tell them to go get a GMail or Yahoo account.

GMail. Yahoo. That raises the second question. Why should my web applications have to manage authentication of a user? Google and Yahoo both have web APIs (Google Account Authentication and Yahoo Browser-Based Autentication) now that allow you to authenticate a user through their system, as long as they have a Yahoo or Google account. This is fantastic. No longer would you have to manage user passwords because you would just off load that work to Google or Yahoo. Yes, there are some security concerns since you are trusting Google and Yahoo for controlling who authenticates on your web application. I think that’s relatively low on the meter though as both Google and Yahoo have a reputation to protect. They are going to work to ensure their system is secure.

So, instead of WordPress and Gallery maintaining their own user names, why not just let me add a user by their email address. Then I just control access, and other options on an email address instead. If I pull Google and Yahoo into the mix, I can allow access based on if I add a person’s email into the correct access control lists, etc. Easy. No messing around with setting up accounts in WordPress just to give access to an album in the Gallery for specific people. Once they authenticate, through Google or Yahoo, they have access to both web applications automagically. Heck, if they’ve already logged into their GMail account, they wouldn’t even have to log in to the website since Google would already know they were authenticated. This gives us the concept of single sign on. You sign on once to Google and all Google registered applications you go to after that in your browser session know who you are.

OK, and what about the other stuff that isn’t associated with an email address. On WordPress, there are other things associated with a user id. Stuff like your full name, IM contact info and other blurbs of information. This could also be pushed out of your web application since much of it is common. This is where OpenID and the Simple Registration Extension could come into play. OpenID is a decentralized identity system. With the Simple Registration Extension, it allows storing of typical stuff you would need when registering for a site. For what I mention above, you’d probably need a “not quite so simple” registration extension. ;)

And where is all of this going? No where. Until someone steps up to the plate and puts together all of the pieces to achieve this. Am I the person? No, not likely. It needs to be done by the major players in the web application space. If WordPress and Gallery (just to name a couple) were to move to a system like this, other applications may follow and new applications may use this model as the “standard”.

Is this a perfect concept? Heck no. There are probably numerous issues associated with moving all of your authentication and user information out of your application. It may even be more difficult to create such an application versus managing everything yourself in your own database. You would still have to at least maintain a database of users (email addresses) and what access or permissions they have for your particular application. Of course, what happens if you can’t reach Google, Yahoo or the OpenID server to try and figure out if the user who is trying to log in is actually who they claim to be? How do you handle users that don’t have a Google or Yahoo email account?

I guess I will keep hoping that something like this happens.

Wiki and Blog Integration

Wiki and Blog integration is apparently a difficult thing. It seems that no one can really agree on how they should be integrated. There is also some question on if they should be integrated.

I stumbled across Blogs and Wiki: WhenBlogMeetsWiki (link now broken – see update below) while trying to find an app that had wiki and blog integration. This site (which is for a course at Bemidji State Univeristy) has a fairly good discussion on the differences and other attempts to combine blogs and wikis.

Now, I’ve been thinking about this for a while. I would really like an app that does wiki and blog integration because there are many times when I would like to be able to reference a wiki (reference) page from a blog entry. It should be seamless integration without having to hack either code base to “force” it to work. I know there are a number of plugins available for most of the major wikis and blogs, but then you’re stuck with two seperate apps to manage. Both of which are probably more complex that what I’m looking for.

I like the model that Mediawiki uses where each individual wiki page has it’s own “talk” page. I like that idea but I don’t like how it’s implemented. I think it would make more sense for a wiki page to be able to have a blog of it’s own. That could be expanded on to give individual users their own blog within a wiki (the blog would be attached to their user page). In addition to a blog being able to be attached to a wiki page, there should also be a blog style comment ability. The thing I find most confusing about the wiki talk pages is that each user has to make sure they denote their words well. Sometimes you can get very confusing pages unless you’ve been following the “conversation” since day one. Maybe some form of “discussion” page would make more sense. With the ability to thread comments.

Anyhoo, I’m probably never going to find an app that does all of this so maybe it’s time for me to start working on one of my own. With the amount of free time I have these days, I should have a working prototype by 2010. ;)

Updated: Unfortunately the original link in this article has disappeared/moved. You may be able to find relevant info via http://ferret.bemidjistate.edu/~morgan/