This article references Fine grained authorization in Overlord projects

Ideally all of the Overlord projects would maintain some consistency with regard to the concepts used for fine grained authorization.  Please see the article above for details about how this is currently done in APIMan.  This article is about how authorization might be done, using these same concepts, in RTGov.

Specifically, the authorization entities are as follows:

1. User
2. Role
3. Permission
4. Qualified Membership

RTGov allows users to view and manage aspects of running Services as well as view and react to Situations.  For the purpose of this use-case description, I'll focus on Situations.

Applying Authorization to Situation Management

A running system that uses RTGov may generate Situations as various business related metrics are reached.  These Situations are gathered up and presented to the user in the RTGov user interface.  The user may choose to react to a given Situation in some way, for example by modifying the message payload that caused the Situation and re-submitting it.

Perhaps not all users of the RTGov UI should have permission to view and react to all Situations.  Perhaps only a subset of Situations should be available to a particular user.  What information about the Situations might we want to use to determine whether the currently logged-in user should have access to it?

There are a few options we could choose, such as which Service the Situation is related to.  However, for this use-case let's assume that the Situation contains a property that we can use for this purpose.  We'll also assume that the property is "CustomerId".  This property would need to be set on the Situation every time it was generated by the RTGov system, presumably being drawn from the inbound message.

Therefore we can apply the authorization pattern described above to this use-case in the following way:

1. Define a set of Permissions that determine what users can do with Situations:
   1. situation.view - allows users to view a situation
   2. situation.resubmit - allows users to modify the payload and resubmit it
   3. situation.ignore - allows users to clear/ignore a situation from the list without doing anything further with it
2. Define a Role or set of Roles that users can be given:
   1. Customer Contact - grants: situation.view
   2. Customer Representative - grants: situation.view, situation.resubmit
   3. Manager - grants: situation.view, situation.resubmit, situation.ignore
3. Grant a User Membership in one or more Roles defined above, qualified by a particular Customer ID
4. Add logic to the "resubmit" and "ignore" code that will first check authorization.  The logic would be:
   1. Get CustomerId property from the Situation being acted upon
   2. Get all permissions for the currently authenticated user
   3. Assert that the user has appropriate permission (situation.resubmit and situation.ignore, respectively) qualified by the CustomerId from (a)
5. Modify the (e.g. SQL) query being used to retrieve the list of Situations available to the current user (this query is used by the UI when displaying the list of Situations to the logged-in user).  Here is how that might be done:
   1. Get all situation.view qualified permissions for the current user
   2. Create a set of Customer IDs from the qualifiers in (a)
   3. Add a WHERE criteria to the SQL query such that only Situation rows which have a CustomerId that matches the set from (b) are returned

For this use case to be effective, we will need a convenient way to grant and revoke membership in the Roles defined in (2) above, and each membership granted must be qualified by a Customer Id.  This means that a source of Customer Ids must be available.

I would also propose that role called Admin should exist that would bypass all of the authorization checks and allow these users to have access to all Situations and all actions.