Orthogonality

Posted on January 6, 2011 by Tommy McGuire

This is a story about how bad code gets written by someone who knows better.

Orthogonality, in a basic geometrical definition, means that two lines are perpendicular to each other. Consider the traditional x and y axes as the two lines. These two lines are perpendicular, and so orthogonal. All of the points on the y axis, projected onto the x axis, share the same point. If you move from one point on the y axis to another, you keep the same x value; your shadow on the x axis does not move.

The alternative involves having the two lines non-perpendicular. Now, all of the points on the y axis, projected on the x axis, are mapped to different points on the x axis. If you move from one point on the y axis to another, you also have to change your x value; the shadow on the x axis moves with you.

What has this got to do with bad code? Non-orthogonality is a problem when it appears in code. In this case, I could have avoided the problem, but I didn't. Now, I get to write bad code. It will work, but it will not be pretty, and I bet it will cause problems in the future.

Take a pretty normal user authorization system, where users have the ability to perform their designated operations for the site where they work. As a result, the user's home location maps to their authorization. Unfortunately, it never stays that way. In my case, one group of users is authorized to do things for remote sites, and a sub-group of them cannot do things for their own site. So, location no longer cleanly maps to authorization.

One proposal was to use location as the primary authorization mechanism, with group membership overriding the location for the special cases. My proposal, on the other hand, was to use a group for every location and add users to the correct group to allow them to do whatever they need to do. Unfortunately, I didn't press the issue and it is too late now, given that the special groups are set up and populated and the sheer inertia of the organization is overwhelming.

So I am now writing code using location as a primary authorization field with group membership as an override. Yay.

Comments

I don't understand.

What does location have to do with authentication?

It seems like there is a coupling between authentication and authorization, and your solution is not that much better to the one that was implemented. You simply give yourself one degree of freedom. It is much better to pass the rights around as they are needed, and make decisions on whether to revoke or deny rights as you pass them around.

John Zabroski
'2011-01-10T17:16:18.583-06:00'

Authentication? Location doesn't impact that at all. Did I mistype something? I've had authentication on my mind for so long I think it's the only completion for "auth...." I'll check.

There is a coupling between authentication and authorization because I do not have any information about authorization aside from the authentication information. I cannot determine rights without determining identity originally, and we'll need the identity for other purposes in any case.

Tommy McGuire
'2011-02-01T15:18:29.053-06:00'