57 lines
3 KiB
Org Mode
57 lines
3 KiB
Org Mode
:PROPERTIES:
|
|
:ID: 8c6d80b5-dc83-40ee-b187-4b0427c77f78
|
|
:END:
|
|
#+title: Permissions outside scopes
|
|
#+Author: Yann Esposito
|
|
#+Date: [2023-03-10]
|
|
|
|
- tags :: [[id:ce893df9-32a4-44e0-9eb5-b9817141ee6a][cisco]] [[id:299643a7-00e5-47fb-a987-3b9278e89da3][Auth]]
|
|
- source ::
|
|
|
|
This was really interesting and this question about when to use or not scopes is
|
|
generally a recurring one.
|
|
So I should probably try to explain it more clearly.
|
|
Perhaps I would need to write a doc, but if I try to make it easier to
|
|
understand, maybe we can think about it this way.
|
|
|
|
Scopes are permissions that we can control via the OAuth2 clients. So when we
|
|
put the permission inside scopes we gain:
|
|
|
|
- the ability to restrict the permission for some clients (for example we will
|
|
be able to restrict DI access to some client without restricting access to
|
|
Secure Client while the user can access both)
|
|
- checking for permission is easier because all permission are centralized in
|
|
the scopes, always. This has consequences for the API as well as for the UIs
|
|
but also for all external clients, so the permission can be enforced and
|
|
published at the API level.
|
|
|
|
If we plan to have another set of permission outside the scopes, say, have a
|
|
list of permission in another entity (like in the entitlement of the Org, or
|
|
something related):
|
|
|
|
- In this case, the UI will need to check both the scopes and this new values.
|
|
Knowing that the structure of such list of permission will be pretty similar
|
|
to the structure of the scopes (mainly a list of string that represent
|
|
permissions). The clients will not easily be able to know if they can access
|
|
some resource or not.
|
|
- Internally, every API access permission only uses scopes, that would mean we
|
|
will need to add another independent layer of checking that could cause
|
|
confusion in the code, probably will have a non negligible impact on the
|
|
performance of every API call (as we will need to check more than the scope,
|
|
every API call will also need to perform addition call to the DB)
|
|
- We can no longer express that an OAuth2 Client is restricted to use some apps
|
|
(like if we change the entitlement, we can no longer restrict that client not
|
|
to use some app)
|
|
- With RBAC I see more and more concern about handling permission of external
|
|
applications via IROH, so here too, it is easier to handle via scopes
|
|
- Every client (not just UI and IROH) will need to check two different set of
|
|
permissions if they want to understand what is allowed to them or not. Mainly
|
|
instead of just checking scopes, they will also need to check another
|
|
permission system with potentially different access rules.
|
|
|
|
Everything about it is quite technical and not easy to convey in a discussion.
|
|
But this is why I might need to write this down somewhere to explain the
|
|
advantages and drawbacks of using another dimension for permissions.
|
|
A good usage of not using scopes for some kind of permission are the audiences
|
|
because this is not about the User's permission, but about the Client permission
|
|
that still is granted to be used by some User.
|