You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 5-AccessControl/1-call-api-roles/README.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -295,7 +295,7 @@ To provide feedback on or suggest features for Azure Active Directory, visit [Us
295
295
296
296
### Angular RoleGuard and protected routes for role-based access control
297
297
298
-
The client application Angular SPA has a [role.guard.ts](./SPA/src/app/role.guard.ts) component that checks whether a user has the right privileges to access a protected route. It does this by checking `roles` claim the ID token of the signed-in user:
298
+
The client application Angular SPA has a [role.guard.ts](./SPA/src/app/role.guard.ts) component that checks whether a user belongs to the required role(s) to access a protected route (see also: [base.guard.ts](./SPA/src/app/base.guard.ts)). It does this by checking `roles` claim the ID token of the signed-in user:
299
299
300
300
```typescript
301
301
@Injectable()
@@ -390,9 +390,9 @@ const routes: Routes = [
390
390
391
391
However, it is important to be aware of that no content on a browser application is **truly** secure. That is, our **RoleGuard** component is primarily responsible for rendering the correct pages and other UI elements for a user in a particular role; in the example above, we allow only users in the `TaskAdmin` role to see the `Dashboard` component. In order to **truly** protect data and expose certain REST operations to a selected set of users, we enable **RBAC** on the back-end/web API as well in this sample. This is shown next.
392
392
393
-
### Policy based Authorization for .NET Core web API
393
+
### Policy based authorization for .NET Core web API
394
394
395
-
As mentioned before, in order to **truly** implement **RBAC** and secure data, this sample allows only authorized calls to our web API. We do this by defining access policies and decorating our HTTP methods with them. To do so, we first add `roles` claim as a validation parameter in `Startup.cs`, and then we create authorization policies that depends on this claim:
395
+
As mentioned before, in order to **truly** implement **RBAC** and secure data, this sample allows only authorized calls to our web API. We do this by defining access policies and decorating our HTTP methods with them. To do so, we first add `roles` claim as a validation parameter in [Startup.cs](./API/TodoListAPI/Startup.cs), and then we create authorization policies that depends on this claim:
396
396
397
397
```csharp
398
398
// See https://docs.microsoft.com/aspnet/core/security/authorization/roles for more info.
@@ -411,7 +411,7 @@ As mentioned before, in order to **truly** implement **RBAC** and secure data, t
411
411
});
412
412
```
413
413
414
-
We defined these roles in `appsettings.json` as follows:
414
+
We defined these roles in [appsettings.json](./API/TodoListAPI/appsettings.json) as follows:
415
415
416
416
```json
417
417
"Roles": {
@@ -420,7 +420,7 @@ We defined these roles in `appsettings.json` as follows:
420
420
}
421
421
```
422
422
423
-
Finally, in `TodoListController.cs`, we decorate our routes with the appropriate policy:
423
+
Finally, in [TodoListController.cs](./API/TodoListAPI/Controllers/TodoListController.cs), we decorate our routes with the appropriate policy:
0 commit comments