From 8c107c0af33ca642207fb5b803875473b137376f Mon Sep 17 00:00:00 2001 From: Mike Schwartz Date: Mon, 7 Nov 2022 22:26:18 -0600 Subject: [PATCH] Initial checkin: RBAC, central authz (#2884) Starting point for these topics --- docs/admin/planning/central-auth-service.md | 19 +++++++++++- .../planning/role-based-access-management.md | 31 ++++++++++++++++++- 2 files changed, 48 insertions(+), 2 deletions(-) diff --git a/docs/admin/planning/central-auth-service.md b/docs/admin/planning/central-auth-service.md index cf99095321f..45884346af4 100644 --- a/docs/admin/planning/central-auth-service.md +++ b/docs/admin/planning/central-auth-service.md @@ -4,5 +4,22 @@ tags: - planning --- -This is a placeholder +Older monolithic web access management platforms from the 2000's had +features to allow central policy management--what users can access what +resources. But modern federated digital identity platforms generally do not. +That's true for two reasons. First implementing all the OAuth and OpenID +features is already a wide swath of requirements. Second, policy management, +or authorization, has itself become a nice market. Note the policy management +platforms list in the [RBAC](docs/admin/planning/role-based-access-management.md) +planning guide page. +With that said, if the number of policies is low, there are some ways to +use Jans Auth Server as a central policy decision point. You could use the +presence of OAuth scopes to signal to the policy enforcement point the extent +of access. In this case, policies could be implemented as code in the Update +Token interception script. A similar strategy is to use UMA access tokens +("RPT tokens"), in which case you would use either the RPT interception script +or the claims gathering interception script to implement your policies (or a +combination of both). But this approach should be used with caution. Most +of the policy management tools today use a declarative language for policies. +Maintaining policies in code does not scale as well. diff --git a/docs/admin/planning/role-based-access-management.md b/docs/admin/planning/role-based-access-management.md index cf99095321f..c72ab3196df 100644 --- a/docs/admin/planning/role-based-access-management.md +++ b/docs/admin/planning/role-based-access-management.md @@ -4,5 +4,34 @@ tags: - planning --- -This is a placeholder +Using roles to control access to resources makes sense for lots of security use +cases. One benefit of RBAC is that it's deterministic-- from an audit +perspective, you can tell who had access to what at any point in time. This is +harder to achieve when contextual variables play a role in determining access. +An OpenID Provider / OAuth Authorization Server like Jans Auth Server certainly +has a role to play in the implementation of an RBAC infrastructure, but is not +capable of delivering all the functionality your organization will need for a +complete solution. For example, you may need a platform to define enterprise +roles or to perform role consolidation. This is normally handled by an +[identity governance](./identity-access-governance.md) tool. +Also, Jans Auth Server is not a policy management platform, like +* [Styra OPA](https://styra.com), [OSO](https://www.osohq.com) +* [Zanzibar](https://zanzibar.academy/), or +* [Hashicorp Boundary](https://www.boundaryproject.io/) or +* [Apache Fortress](https://www.symas.com/syms-rbac-abac-apache-fortress) + +The tools above are just a few open source policy management frameworks. There +are more commercial products in this space. + +Although Jans Auth Server may not be a complete RBAC solution, there are still +some RBAC capabilities to consider. When a person authenticates using a web +browser, the client can obtain user claims via OpenID Connect. It may make sense +to send the `role` role claim to the client. You may also send the `memberOf` +claim, if your organization uses group membership to manage roles. + +But what if you need to dynamically compute roles? Or if you don't want to +over-share by sending all the roles and groups associated for a person? One +strategy is to use the Jans Auth Server Update Token Interception script to +render the role claim, either in the OAuth access token, the `id_token` or +the Userinfo JWT.