Reapply "Remove Architecture ABAC page and graphics"

[fdr]

Isn't the content just wrong?

#34

This reverts commit 0e6d6c4.

[jeremyevans]

If you definite the first A in ABAC (attribute), to be the ability to use multiple tags per user, similar to how the AWS documentation defines it (https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html), then I don't think the content is wrong. If you define attribute to include session-based information, then the content is wrong.

My personal feeling is multiple tags per user is RBAC with multiple roles, not "true" ABAC. IMO, "true" ABAC includes session-specific information, such as where the current session is logged in from (physical location) and how the current session is authenticated (single factor, multifactor). However, my definition of "true" ABAC does not appear to be universal. Since the AWS documentation uses ABAC to refer to multiple tags/roles per user as opposed to a single tag/role per user, I think it's reasonable for us to use the same definition, and I don't think the documentation is wrong using that definition.

[enescakir]

@ozgune just asked to return it

[fdr]

My personal feeling is multiple tags per user is RBAC with multiple roles, not "true" ABAC. IMO, "true" ABAC includes session-specific information, such as where the current session is logged in from (physical location) and how the current session is authenticated (single factor, multifactor). However, my definition of "true" ABAC does not appear to be universal. Since the AWS documentation uses ABAC to refer to multiple tags/roles per user as opposed to a single tag/role per user, I think it's reasonable for us to use the same definition, and I don't think the documentation is wrong using that definition.

I am at ease with the definition that does not include dynamic tags per authentication method/session. While among the cooler parts of ABAC, and I think we'll get there, but a data model that can only handle RBAC is far more restrictive, often kludged up to get the necessary flexibility. Often the kludge involves semi-imperative code-like elements in the policy language to handle what attributes can handle more naturally and safely (though the imperative-like stuff can do so much more, which is a bit a curse, too)

I was more concerned about clearly obsolete elements of the architecture page, such as how tables were organized.

[fdr]

Also hyper tags, dead right?

[jeremyevans]

It's true that the page does not reflect our current authorization architecture, which is described on a different page: https://www.ubicloud.com/docs/security/authorization

hyper tags got replaced with subject tags, action tags, and object tags. Only remnant is access_tag.hyper_tag_id, which we didn't rename as the benefits of doing so are not worth the costs.

[fdr]

I think we should get the design theory of this page to agree with present practice. ABAC that is degenerate to having no session bindings is still more ABAC than RBAC.

IIRC, although it's been a while since I've studied them, the usual suspects grew expression language-like constructs first and used them to retrofit ABAC, e.g. stuff like this (openstack in this case): example:restricted_action": "role:admin and user.department == 'finance' and time.hour >= 9 and time.hour <= 17

While time.hour is not something we've implemented, use of generic boolean expressions to overcome the inflexibility of the role system is the Bad Thing I'm trying to avoid. What is offered in this ABAC system, sans session-bound attributes, is handling some of the topological complexity in the structure of the authorization system rather than in evaluated policy expressions, which are both more general (and that's bad) and hard to make legible, being embedded with other logic. (and of course, we have no such expression-based functionality, hoping abac-sans-session or whatever you want to call it will carry us a few years)