14 Feb 2004

Sat, 14 Feb 2004 01:34:15 -0700

So I've been hacking some on Monticello today, trying to make the dependency mechanism a little less awful. In particular, I'm working on letting you merge an entire bundle in one operation, instead of popping up a sequence of individual merge dialogs.

An interesting thing is happening as I'm doing this. So far, the bottom layer and core concept in Monticello has been the Package - everything else has been built around this. So there's a PackageLoader for getting stuff into the image, the Merger expects to be merging versions of packages, and so on. In practice, I had noticed that these things mostly operated on Patches, but since I thought of these as the difference between packages it still all seemed to revolve around the package.

However, I'm now having to expand the Loader and Merger so that they can deal with multiple packages at once, and I'm suddenly realizing that packages are irrelevant at that layer. All you care about when merging or loading something into an image is patches, just the raw modifications being made to the code. Where the patches originally came from really isn't your concern. So my mental image of the layers suddenly did a backflip, with Patch at the bottom, Merger and Loader making use of it, and Package and Snapshot on top as a convenient way of producing patches (and of course Version further up still).

This probably isn't very interesting to anyone else, but that's what diaries are all about...

10 Feb 2004

Tue, 10 Feb 2004 07:06:46 -0700

As of today, there are at least three web sites that most developers using Squeak will want to have an account on: the SqueakMap of released software, the Squeak People Advogato clone, and the new SqueakSource public version control repository. My guess is that there will be more to come.

This has got me thinking about single-sign on systems, something I've had some experience developing over the last year. At one point, frustrated by the complexity of systems like the Liberty Alliance, I tried to come up with a truly small and simple system for sharing user accounts. I call it MISO, for Minimalist Integrated Sign On, and I'd like to propose a that we try it as a standard for (to begin with) Squeak community web sites.

Feb 12: I've revised this quite a bit from my initial posting...

The idea behind MISO is this:

Every user has a profile. This profile contains whatever information (name, email address) the user wishes to share about themselves. It also must contain a public key for that user. This public key must remain constant - it is the primary key of the profile. The rest of the information can be changed as the user wishes. Sensitive information should not be placed in the profile, as it can in practice be viewed by anyone.

The profile has a "home site" where it is hosted. This is likely a central site operated for and by a particular community (miso.squeakfoundation.org, say), but in theory it could be anywhere. The user must trust their host completely, since it controls their profile and stores the private key that matches the public key in the profile. Particularly paranoid users will of course want to set up their own home sites to host their profiles. There is nothing in the profile that ties it to the home site - they could be moved from host to host as long as you have a way to safely transfer the private key as well.

When a user accesses a MISO enabled application, they pass the URL of their profile as a query parameter. They also pass a large random number as a session id. Most likely, they do not type these in by hand. Instead, they will log in to the home site, and ask it to redirect them to the application they wish to visit. The home site will automatically generate a new session id and add it and the profile URL as parameters to the redirect. The home site must also record the time the session id was created, and the URL to which it is redirecting.

The MISO enabled application will then request the profile from the URL, passing the session id as a query parameter. The response will be the profile wrapped in an "envelope" that consists of:

a header containing the profile URL and session id
a header containing the URL of the application for which this session was created
a header containing a timestamp of when the session was created
a DSA signature at the end of the entire document, including the above headers and the profile itself, signed with the profile's private key

The host should not accept multiple requests using the same session id - once a single request has been made, that session should be expired. It should not accept requests for session ids it knows nothing about. The application should not accept responses with a session id or profile URL that do not match the one they requested, or with a timestamp older than a a few seconds. The application must verify the signature against the public key in the profile.

The one time use session id, included in the signed document, means that the interaction is unique and cannot be replayed. The signature means that the document cannot be modified in transit, and did indeed come from someone with the right private key. Providing the URL of the application for which the session was created should ensure that it is the user that is accessing the application, and not another application subverting a session that was intended for itself.

Exactly what the application does with the profile is up to it. In general, the application will likely maintain some mapping between the public key of the profile and an account object in the local application. How this association is set up will vary from application to application, but most likely the first time an application sees a particular profile they will require the user to fill in some form to further identity themselves; from that point forward, the application will know who they are.

A useful service that a home site could provide is to act as a general redirection engine - it could have a "redirect" URL that accepted the URL of a MISO application as a query parameter. It would then authenticate the user (through HTTP Basic Authentication, or by verifying a cookie from the user's browser, or if necessary with a login form), and immediately redirect them to the provided URL along with their profile and session info. If the profile advised a MISO application of the availability of such a service, the application could modify any links between it and other applications to go through this redirection so that the user could move between the applications without having to login again.

13 Nov 2003

Thu, 13 Nov 2003 01:19:05 -0700

Too many blogs...

For now, check out HREF Considered Harmful, which is where I usually post. But maybe I'll use this space as a development diary, if I find anything useful to say...

Squeak People diary for avi

14 Feb 2004

10 Feb 2004

13 Nov 2003