Next up: the Authorization service
10 March 2008Now that the Approval service has been put to bed, it’s time to start working on something new. Although there are quite a number of things that I would love start playing with, I think the next logical thing on the list should some kind of a Authorization service. Not to be confused with Authentication, which simply verifies a user’s Identity, an Authorization service would provide a mechanism to determine what it is that a user can do, along with a common means to maintain that information.
Once again, I’m thinking of something relatively simple, easy to access, and relatively ignorant of the various ways in which it might be used. If we think in terms of a possible URL for the Authentication service’s resources, it should include enough components for the service to be useful, but not so many that it becomes difficult to manage and understand. I’m thinking of something like this:
/auth/<context>/<object>/<method>/<qualifier>/<userId>
Briefly, this is the basic concept for the various “nodes” found in the URL:
- context – This is the high-level grouping for all of the authorization needs of a particular functional area and/or application. The “rules” for using the Authorization service might be different in a different “context.”
- object – This is the thing, or “noun,” portion of the authorization. For example, within the “context” of a purchasing application, you might have such objects as purchase orders or vendor invoices.
- method – This is the action, or “verb,” portion of the authorization. Again, using the example of the purchasing application context, when talking about purchase orders you might have such methods as submit, approve, or issue.
- qualifier – This is an optional subcontext, or further classification, that allows you to grant authority to a user to review purchase orders for one department, but not another. The qualifier further limits the scope of the authorization.
- userId – This is the identifier for the subject of the authorization, and ties back to your Identity and Authentication systems.
Basically, the system would be a simple yes/no process based on the presence or absence of a resource for a given URL. Resource present equals authorization granted; resource absent, authorization denied.
That’s the theory, anyway …
Sorry, the comment form is closed at this time.
