Results matching “2006/08/05/launches_and_launches” from Contentment

As I said earlier this week, I want to write about how I implemented single sign-on for the new Boomer.com web site. I didn't come up with the design on my own, but the implementation is from scratch and unique--i.e., proprietary. In the future, I hope to replace the system with something else but since certain aspects of our system's integration or currently in limbo and the lack of prefab Magnolia-to-Drupal implementations, a quick and dirty implementation was certainly in order. I like the results, as much as I can for a quickie, which is why I share it here.

Design

As I just mentioned, I did not invent this design myself. I merely implemented the pattern described for Cosign, a project at the University of Michigan. If my deadline hadn't been looming so close, I might have considered implementing a Drupal plugin for Cosign. As it were, though, I created a fresh implementation that has no other relationship to Cosign than the fact that I have approximately the same structure of HTTP requests and responses that it has (and probably several other implementations).

For the following use-case, I will call the web site that holds authoritative information the Auth-Site and the other site requring authentication information against the Auth-Site, the Sub-Site.

Basically, the use-case works like this:

1. The Client attempts to connect to a protected document on the Sub-Site.
2. The Sub-Site server returns a Sub-Site session cookie to the Client and redirects the Client to the Login-Checker of the Auth-Site.
3. The Login-Checker of the Auth-Site determines if the Client has logged in already to the Auth-Site. Assuming that the Client has not, the Login-Checker returns an Auth-Site session cookie to the Client and redirects the Client to the Login-Form.
4. The Client then fills out the Login-Form and returns it to the Auth-Site, which validates the login using the Login-Form-Checker. Assuming success, the Login-Form-Checker notes that the original Auth-Site session cookie came from the Sub-Site. It then performs a redirect to the original protected document on the Sub-Site that includes in the URL a Login-Token.
5. The Client then returns to request the original protected document from the Sub-Site, but with the Login-Token this time. The Sub-Site then performs an out-of-band (direct connection from Sub-Site to Auth-Site) to see if the Login-Token is valid. Assuming the Login-Token is valid, the Auth-Site returns the Client profile to the Sub-Site and the Sub-Site returns the protected document.

That probably sounds pretty complicated, but it basically amounts to the Sub-Site deferring login to the Auth-Site and asking the Auth-Site for a Login-Token to validate the user by. The major hiccup is the risk of session hijacking if an attacker happens to guess the token.

If that's still confusing, the Cosign site has a lovely sequence diagram of the interaction.

Implementation

So the actual implementation required two additional Java servlets to run with the Magnolia server (in addition to the login servlet already in place). One I called the CheckForLoginServlet. This servlet checks to see if the visiting user has already logged in. If the user has, the user is redirected from whence she came with the login token to verify her authenticity. If the user is new, the user is then redirected to the login form, which is notified of which URL the user needs to be returned to afterward.

The second servlet is the ValidateAuthTokenServlet. This servlet handles the out-of-band, server-to-server communication, which verfies the user and sends an XMLized version of the user's profile from Magnolia auth-site to the Drupal sub-site. The token itself is a UUID, which should be sufficiently difficult to guess, but might still be vulnerable to snooping attacks, since the communications aren't currently encrypted. Really, though, this is no worse than any other plain text login, which has the same vulnerabilities. We plan to move the authenticated parts of the site to SSL in the next few months to make the system stronger.

Another interesting piece to the puzzle is that I made the LoginToken objects semi-autonomous in that they erase the persistent data they store with the user objects when the session they belong to is invalidated. A user can login multiple times from differnet locations and each location will have a unique session token. When the user's session times out, the token is also invalidated.

On the Drupal side of things, I had to add a couple little hacks to get things to work just so. First, since the Drupal site is entirely contained within the Extranet, all documents are protected documents. No one should see anything on the site without logging in first. Thus, I overrode hook_init to perform a redirect to the CheckForLoginServlet unless the request came with a login token, came from a browser with an already validated session, or was coming for the cron script---which I didn't want to authenticate to execute.

If the request comes with a login token, the Drupal server performs the out-of-band check against ValidateAuthTokenServlet to see if that login token matches any current user session. If it doesn't, the user is kicked out to the CheckForLoginServlet to login again. If it does match, the user is, effectively, logged in by a special subroutine which loads their profile information from the XML passed back by the ValidateAuthTokenServlet. This also updates all the roles the user is in to make sure his permissions are correct and then drops them into the page.

All-in-all, the visitors should be relatively oblivious to the system. The only hiccup at this point that I need to take care of is to make sure that anytime the query string of a request to Drupal or to Magnolia contains a login token, that the client be immediately redirected again to remove the token from the location bar. Those tokens shouldn't accidentally end up in linked URLs if the user copies-and-pastes, or someone may find themselves logged in as the other user---i.e., bad stuff.

In the long-term, however, I will probably implement something like Cosign or CAS or SXIP, depending on how things shake out over the next few months. If we choose the right standard, we should be able to provide better integration with clients or third party apps to improve our SaaS opportunities in the future.

Ooblech. I'm tired. I better get this posted and then get some sleep.

I'm excited to announce the two new site launches: this web site and a new Boomer.com. The latter has involved 6 months of my blood, sweat, and late hours. The former took me all of today to revamp and re-re-re-re-re-release. I'm also working on launching about three other web sites in the near future.

Home Site

As I stated previously, I'm going to start toning down the development I do at home. Well, at least that was the plan. It didn't really work as I thought. I've probably spent almost as much time in front of a screen at home as at work over the last few months. The reason is related to some work I've been doing with Perl and Java---which, incidentally, might be published on Perl.com in the next few months.

I've been toying with the idea of using a Java-based database engine called Jackrabbit with a Perl web front-end called Catalyst. While that was a fun project to work on, the results weren't quite as nice as I wanted. Rather than continue tweaking it into what I want (which would probably only take another month or two of effort), I'm going to take what I've learned and move on to using Drupal again instead.

Why back to Drupal? Well, I was using WordPress, which is a pretty decent blog app. However, it's just not as easy to hack as Drupal is and I know that if I have a blog, I'll still want to tweak it, but that's not so easy with WordPress. Furthermore, I'm webmaster for the extranet site at work, which is Drupal, and our church web site, which is Drupal. I figure I can maximize my ability to maintain all these Drupals. Drupal is an excellent general purpose CMS even if it's a little bit of overkill for a blog.

I'm also starting to contribute to a number of different web sites and I'd like to have one central location to collate all those contributions and I hope to make this the place. With some enhancements, I think either the built-in or one of the other aggregation modules available for Drupal will come in handy for this. I also have a kiddo on the way and plan to share photos here. That is to say, this isn't going to be just a blog for long.

Finally, as I mentioned I did learn something from the Perl/Jackrabbit integration and I plan to use some of that to improve the user interface of Magnolia (see below) and/or Drupal. I'll probably write a blog on what I learned in the next few days so that these thoughts aren't quite so nebulous.

Boomer.com

Boomer.com is another interesting beast. I'm still trying to decide how I feel about what we've done. It looks pretty good. Though, the look will never look as good as either Eric or I want it to. Being so close to the project, I know all of its blemishes. Like home remodeling projects, when you fix something, there are inevitibly a few mistakes that bug you, but when you look at project by someone else, you never even notice them. It's the same way here: I will always know what isn't quite as nice as it could be even though almost no one else will notice.

As for the technology, we've actually built a hybrid of Magnolia and Drupal. That's mostly interesting because Magnolia is written in Java and requires a Java-based application server, while Drupal is PHP based and requires CGI or an Apache module to run. There are some tools to help PHP and Java communicate server-to-server, but we haven't used any of them, mostly because we couldn't get them to work correctly within our timeline.

However, I'm pretty happy with how well the integration works. The most interesting project related to this so far has been the implementation of single sign-on, which required some interesting redirect tricks. It works pretty well and I'm confident that our customers will be completely oblivious to the nuts and bolts of the process. I'll probably blog on the single sign-on process in another blog coming up, so look for it! ;)

Just because we launched, though, doesn't mean we're finished. There's a long list of new features to add. Since I'm not sure how much of that list is safe to tell, I'm going to just say that we hope to sell more stuff and hope to add more multimedia and hope to put up some additional web-based applications to facilitate our consulting; that ought to vague enough. :P

Other Sites

I'm also working on a few other projects. A couple of them I don't really want to talk about except to say that I'm working on them. ;) However, our church web site is one of the biggies I'm currently working on. This is another Drupal site. First, the web site is currently running an old version of Drupal (either 4.5 or 4.6, I don't remember which and 4.7 is current). Second, the church has been redesigning the look of our logo, letterhead, signage, and web site. The web design has been chosen and Eric and I will be putting that together as soon as we can.

Anyway, I'm excited about that and the fact that the church will be starting a monthly newsletter to help drive new traffic to the site. I hope this will improve communication for our members, which has been a historical problem of our church (as it is with so many).

That's what I'm working on. As I said, I'm tired and now it's time to sign off.

Cheers.

Ooblech. I'm tired. I better get this posted and then get some sleep.

I'm excited to announce the two new site launches: this web site and a new Boomer.com. The latter has involved 6 months of my blood, sweat, and late hours. The former took me all of today to revamp and re-re-re-re-re-release. I'm also working on launching about three other web sites in the near future.

Home Site

As I stated previously, I'm going to start toning down the development I do at home. Well, at least that was the plan. It didn't really work as I thought. I've probably spent almost as much time in front of a screen at home as at work over the last few months. The reason is related to some work I've been doing with Perl and Java---which, incidentally, might be published on Perl.com in the next few months.

I've been toying with the idea of using a Java-based database engine called Jackrabbit with a Perl web front-end called Catalyst. While that was a fun project to work on, the results weren't quite as nice as I wanted. Rather than continue tweaking it into what I want (which would probably only take another month or two of effort), I'm going to take what I've learned and move on to using Drupal again instead.

Why back to Drupal? Well, I was using WordPress, which is a pretty decent blog app. However, it's just not as easy to hack as Drupal is and I know that if I have a blog, I'll still want to tweak it, but that's not so easy with WordPress. Furthermore, I'm webmaster for the extranet site at work, which is Drupal, and our church web site, which is Drupal. I figure I can maximize my ability to maintain all these Drupals. Drupal is an excellent general purpose CMS even if it's a little bit of overkill for a blog.

I'm also starting to contribute to a number of different web sites and I'd like to have one central location to collate all those contributions and I hope to make this the place. With some enhancements, I think either the built-in or one of the other aggregation modules available for Drupal will come in handy for this. I also have a kiddo on the way and plan to share photos here. That is to say, this isn't going to be just a blog for long.

Finally, as I mentioned I did learn something from the Perl/Jackrabbit integration and I plan to use some of that to improve the user interface of Magnolia (see below) and/or Drupal. I'll probably write a blog on what I learned in the next few days so that these thoughts aren't quite so nebulous.

Boomer.com

Boomer.com is another interesting beast. I'm still trying to decide how I feel about what we've done. It looks pretty good. Though, the look will never look as good as either Eric or I want it to. Being so close to the project, I know all of its blemishes. Like home remodeling projects, when you fix something, there are inevitibly a few mistakes that bug you, but when you look at project by someone else, you never even notice them. It's the same way here: I will always know what isn't quite as nice as it could be even though almost no one else will notice.

As for the technology, we've actually built a hybrid of Magnolia and Drupal. That's mostly interesting because Magnolia is written in Java and requires a Java-based application server, while Drupal is PHP based and requires CGI or an Apache module to run. There are some tools to help PHP and Java communicate server-to-server, but we haven't used any of them, mostly because we couldn't get them to work correctly within our timeline.

However, I'm pretty happy with how well the integration works. The most interesting project related to this so far has been the implementation of single sign-on, which required some interesting redirect tricks. It works pretty well and I'm confident that our customers will be completely oblivious to the nuts and bolts of the process. I'll probably blog on the single sign-on process in another blog coming up, so look for it! ;)

Just because we launched, though, doesn't mean we're finished. There's a long list of new features to add. Since I'm not sure how much of that list is safe to tell, I'm going to just say that we hope to sell more stuff and hope to add more multimedia and hope to put up some additional web-based applications to facilitate our consulting; that ought to vague enough. :P

Other Sites

I'm also working on a few other projects. A couple of them I don't really want to talk about except to say that I'm working on them. ;) However, our church web site is one of the biggies I'm currently working on. This is another Drupal site. First, the web site is currently running an old version of Drupal (either 4.5 or 4.6, I don't remember which and 4.7 is current). Second, the church has been redesigning the look of our logo, letterhead, signage, and web site. The web design has been chosen and Eric and I will be putting that together as soon as we can.

Anyway, I'm excited about that and the fact that the church will be starting a monthly newsletter to help drive new traffic to the site. I hope this will improve communication for our members, which has been a historical problem of our church (as it is with so many).

That's what I'm working on. As I said, I'm tired and now it's time to sign off.

Cheers.