You try to give a user a role so they have permission to that credential
This user is not in the organization
OBJECTIVE - it is desired to block this action, until the client adds the user as a member of the organization
This is only done for that particular action (plus a team variant). That never made any real sense, because user-organization-membership in AWX is meaningless when that story is repeated for all other models. So this issue asks what we would have if we respected that as a full feature, and resurrected it in DAB RBAC.
If this setting is False, it will enforce two things, (1) users need "member_organization" for all role-user-assignments and (2) teams must be in same organization as any content_object they get permission for. So we have to logic this through from the very start:
The team model, itself, is a resource model that users get "member_team" permission for. This setting applies to it just like other models. If the setting is False, you can't become a member of a team unless you are also a member of the team's organization.
You can't get permission to any other content object without having "member_organization" to its related organization. This, of course, assumes the object has an organization.
Assuming this enforcement is always maintained (or data is migrated to coherency), you can see the 2 enforcement criteria are mutually supporting. Because all team members are known to be organization members, and because teams can only have same-organization permissions, giving team permissions to an object does not spill permissions across multiple organizations.
Model-Specific Implementation
A single global setting is probably too inflexible to ever be workable. Current AWX configuration only asks that this is enforced for the credential model. Model-specific configuration can be done in the permission_registry.register calls.
Some models are "singleton" models that do not have Organization as a parent, so obviously this enforcement would be impossible for those models anyway. Global roles are also apparently totally outside of this system as well.
If the team model does not enforce organization membership, then all other model enforcement is mostly pointless, because users outside of the organization can have permissions to an object via a team.
In https://github.com/ansible/django-ansible-base/pull/490 we added a callback to an old rule in AWX. Walking through the steps there:
This is only done for that particular action (plus a team variant). That never made any real sense, because user-organization-membership in AWX is meaningless when that story is repeated for all other models. So this issue asks what we would have if we respected that as a full feature, and resurrected it in DAB RBAC.
Global Setting Implementation
Imagine some setting and default like:
If this setting is
False, it will enforce two things, (1) users need "member_organization" for all role-user-assignments and (2) teams must be in same organization as any content_object they get permission for. So we have to logic this through from the very start:False, you can't become a member of a team unless you are also a member of the team's organization.Assuming this enforcement is always maintained (or data is migrated to coherency), you can see the 2 enforcement criteria are mutually supporting. Because all team members are known to be organization members, and because teams can only have same-organization permissions, giving team permissions to an object does not spill permissions across multiple organizations.
Model-Specific Implementation
A single global setting is probably too inflexible to ever be workable. Current AWX configuration only asks that this is enforced for the credential model. Model-specific configuration can be done in the
permission_registry.registercalls.Some models are "singleton" models that do not have Organization as a parent, so obviously this enforcement would be impossible for those models anyway. Global roles are also apparently totally outside of this system as well.
If the team model does not enforce organization membership, then all other model enforcement is mostly pointless, because users outside of the organization can have permissions to an object via a team.