mooreds
commented
2 years ago Another alternative/workaround would be to build this mapping proxy yourself and insert it between your client and the token endpoint.
Open matthewhartstonge opened 2 years ago
mooreds
commented
2 years ago Another alternative/workaround would be to build this mapping proxy yourself and insert it between your client and the token endpoint.
brazabr
commented
2 years ago Another alternative to this would be a custom scope CRUD section where we could setup any scope and link it to entities/applications/users and leverage the permissions in FusionAuth to do its things.
robotdan
commented
1 year ago In order to use spaces for permissions as well, we would have to enforce that all roles are defined as globally unique which we don't do today. This would be a breaking change of sorts -so we'd likely have to make the user opt into this behavior, or maybe we could be backwards compatible in that we only allow the new syntax if we identify the item as a role and it is globally unique.
In your example solution, are you suggesting that we index all values for entities and roles, so that when we see a scope such as urn:hero:attendance:records we don't know if it is a role or an entity - until we resolve it and then identify it is an entity. The same would go for the permission urn:hero:attendance:records:delete, and then based upon their type and sequence in the scope we would know that all permissions following an entity apply until we see the next entity. Does that sound right?
Add support for scope aliases for entities
Problem
The permissions system and naming of scopes is very restrictive, enforcing a FusionAuth styled format for scopes which provides incompatibility with existing OAuth scopes pushed into external solutions that want to migrate to FusionAuth.
For example, given our current OAuth 2.1 implementation, we have a number of API consumers that use the Client Credentials grant and all our internal backend services talk to each other using client credentials as well to access our APIs. The new format will provide a bit of pain in migrating our current API consumers who, depending on access requirements, have quite a list of scopes based on the resource access required.
For example, given our current OAuth scopes, a request like this:
Will now become:
Solution
I propose the idea of scope aliases. This can provide a way to have globally unique scopes (permissions) that can be bound to a given scope. This also better aligns with the OAuth specification of whitespace separated scopes, for example:
Alternatives/workarounds
Inform all our API Consumers to migrate to the new scopes? haha
Additional context
I noticed a similar ask via: https://github.com/FusionAuth/fusionauth-issues/issues/1477, but this would provide a more nuanced/user customisable, more migratable approach.
Related
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.