A fundamental approach in programming authorization logic in applications for long term stability and reliability is to focus on permissions
and not roles
or groups
within the code itself.
The reasoning for this is portrayed excellently by this SO post, displayed here readability:
At the moment of checking, the calling code only needs to know "does user X have permission to perform action Y?".
The calling code does not care about and should not be aware of relationships between roles and permissions.
The authorization layer will then check if the user has this permission, typically by checking if the user's role has this permission. This allows you to change authorization logic without updating the calling code.
If you directly check for role at the call site, you are implicitly forming role ⇄ permission relationships and injecting authorization logic into the calling code, violating separation of concerns.
Should you later decide that role foo
should not have permission baz
, you would have to change every code which checks if the user is a foo
.
In the primary authorization examples in Github for Azure AD I see good integration with Groups
and Roles
:
[Authorize(Roles = "Admin, Writer, Approver")]
public ActionResult TaskSubmit(FormCollection formCollection)
{
if (User.IsInRole("Admin") || User.IsInRole("Writer"))
...
{
However there doesn't appear to be an example for Permissions
. In this space, one would expect the ability to do (with a custom handler):
[Authorize(Policy = "task.submit")]
public ActionResult TaskSubmit(FormCollection formCollection)
{
...
}
Under the covers, [Authorize(Policy = "task.submit")]
would call Azure AD to verify if the user has the task.submit
permission. Azure AD would evaluate this internally through the users Groups
and Roles
and their access to the task.submit
permission in the application configuration.
In this approach, the below changes (and more) could go into enforcement without requiring a code change:
- Permission changes to
Admin
and Writer
removing their ability to submit tasks
- Assigning a
Group
permissions to submit tasks
- Assigning a new role with permission to submit tasks
Scopes
At first glance, Scopes appeared to provide these Permissions
however it appears they are only usable in application to application. Users
, Groups
, or Roles
cannot be assigned to a scope
, and when an application requests a scope
all users using the application receive that permission.
Is there the ability to do the above permission-based access with Azure AD?
Thanks!
Additional References: