Decomposing the Authorization Class

[jp-harvey]

Recently there has been an effort to refactor the Authorization class to reduce duplication and redundancy, and make it more applicable to real-world scenarios - see #531.

After seeing the improvements made and following impromptu additional analysis in the System Activity weekly call, it was suggested that the current approach of having a single Authorization class may be too condensed for many scenarios.

Primarily it was raised that the class conflates two different activities - assigning permissions to a principal and changing group membership of a principal, which ultimately mean direct or indirect permissions being assigned to a principal. In addition, Authorization could also be interpreted as the use of credentials rather than a change in credential assignment, and that searches in the current format may become complicated.

The other consideration is that Authorization is very generic and can be interpreted as a class that is concerned with whether or not authorization was granted (which is covered by Access Activity

It's suggested that the existing class be split instead of condensed, something along the lines of two new classes:

Entity Permission Management
Entity Membership Management

Some thought needs to be given about how roles would fit in here as well.

@odianosen eager to get your thoughts on this one.

(it was also noted that there are some fields that should probably be changed to make the class more generic, which could be applied with a profile. eg. dst_endpoint)

[pagbabian-splunk]

Yes, I agree the current Authorization class has become too complicated and might be error prone in usage. The two distinct classes aforementioned make sense and are in the spirit of the live call we had. Along with Access Activity for the enforcement of privileges or permissions. (Note, do we consider privileges and permissions the same? We have a privileges attribute already, I suggest we stay with that).

We should also re-craft these classes with Account Change and Entity Management classes in mind. Account Change is mostly about passwords and policies, and notably there are not account_xxx attributes as primary attributes (and we have a new Account object PR), but rather as attributes of the required User object.

Entity Management has CRUD activities on a Managed Entity object - it's unclear to me what they really mean, what types of logs are represented.

In other words, when re-crafting Authorization, we need to do it in context of the Access Control category as a whole (note API Activity has already been moved to Application Activity category).

[odianosen]

Interesting discussion. Sorry I missed the weekly call where this was discussed - I just came back from vacation.

So it seems to me that there are 2 general use cases related to authorization - granting permissions and using the permissions. The former is currently the focus of Authorization class, and the latter is handled by Access Activity. So far, that makes sense to me.

Regarding the Authorization (that is, permission/privilege assignment), @jp-harvey is suggesting that it be split into distinct activities - directly granting permission to a principal vs adding a principal to a group. I'm kind of struggling to see the difference. Ultimately, they are both about access management. I think that splitting them out into more granular classes as suggested may be the more confusing approach. Seems to me that it will be lead to class duplication, and ambiguity of which class to use for different use cases. Take assigning a role to a user for example - is role a thing that the user is now a member of (which aligns with my mental model), in which case Entity Membership Management applies, or is role a permission/privilege that is directly assigned to the user (hence Entity Permission Management)? It becomes ambiguous and confusing.

@jp-harvey It may help the discussion to outline some scenarios where the current approach is too condensed, and let's discuss that.

By the way, I think that the class name Authorization may be too generic and even misleading. Maybe we should change the name to Access Management (as in IAM), which would make it a neat complement to Access Activity within Access Control category.

[odianosen]

Summary of where we landed on after discussion.

Enumeration of events that we want to model:

• Assign privileges to User
• Revoke privileges from User
• Assign privileges to Group
• Revoke privileges from Group
• Add User to Group
• Remove User from Group
• Add Group to Group
• Remove Group from Group

And they will fit into these classes:

User Access Management
Target: User
Activities:

• Assign privileges
• Revoke privileges

Group Access Management
Target: Group
Activities:

• Assign privileges
• Revoke privileges
• Add User
• Remove User
• Add Group
• Remove Group

These classes will model permission management actions, and are different from runtime access authorization. We will therefore leave the current Authorization class as is, because the event it captures is the latter type - privileges assigned to a user on logging into a machine. Access Activity also falls into the category of access authorization at runtime (or request time).

We will also not create an object or classes for Role, until we see the need for it.

I'll put these in a discussion and close out PR #531.

[odianosen]

PR #593

[pagbabian-splunk]

New classes are now part of RC3.