The Authorization Service: Service Overview
15 March 2008I know that last time I said that we would start working on the primary servlet for the Authorization Service next, but since then I realized that I pretty much just jumped right into code and never really did a thorough job of explaining just what the service was for and how it would work. So, I think it’s time to back up the truck just a tad and look at things from a slightly higher perspective.
The primary purpose, of course, is to determine if a certain user is allowed to perform a certain task and/or view a certain resource. This is to be accomplished by issuing an HTTP GET on a specific URL constructed using the appropriate context, object, method, qualifier, and user ID. The answer to the question “Is the user authorized?” can be found in the HTTP response: 200 means “yes”, 404 means “no”, and anything else means that there has been some kind of technical problem.
Determining authorization will not be the only function of the service, however. Because it is a self-contained, stand-alone service, it also has to provide a means to maintain this authorization data. This can be done, of course, with the same URL structure by altering the HTTP method from GET to PUT (to grand authority) and DELETE (to revoke authority). For this service, there will be no need for the POST method, since the only options are to grant or revoke authorizations. Since authorization is a binary “yes” vs. “no” concept, there is nothing to “update” or POST.
To fully understand the concepts behind context, object, method, and qualifier, it will probably be helpful to look at a few examples:
- /purchasing/po/submit/depta - within the Purchasing system, can submit Purchase Orders (POs) for Department A
- /hr/timecard/review/purchasing – within the Human Resources system, can review (approve/deny/etc) Time Cards for the Purchasing department
- /helpdesk/ticket/close/level1 – within the Help Desk system, can close trouble tickets as long and they are assigned to level 1 support
- /master/user/view/purchasing – within the Authorization Service, can review user authorizations in the purchasing context
That last one is how the Authorization Service uses its own services to determine who is authorized to do what with the context of the Authorization Service. The context ID for the Authorization Service is master. Any authorizations in the master context relate to things you can and cannot do with the Authorization Service itself.
Each context defines its own objects, methods, and qualifiers. In the master context, there is only one object, user (user authorizations), and three methods that apply to the user object: view, grant, revoke. The qualifier in the master context represents other contexts, and includes the master context as well. To be an all-powerful system god in the Authorization Service, you need to have the following authorizations:
- /master/user/view/master
- /master/user/grant/master
- /master/user/revoke/master
Given those powers, you can set yourself or others up for any other powers within the service. Whenever you create a new context, you need to set someone up with view, grant, and revoke authority for that context within the master context so that you can create users who can maintain the data within that context.
Sorry, the comment form is closed at this time.
