We need to set up a third party authorization system for exchanges between a server, owning a resource, and a "requesting party" client, needing action on this resource (reading, modifying).
The User-Managed Access (UMA) 2 protocol seems globally appropriate for our needs.
We tested it on some identity servers implementations (WSO2-IS, Gluu Server) and it proved usable on the resource declaration step from the resource server, and the client access situation.
One thing missing for us now is the authorization logic in the client access situation.
For our needs, the resource is to be created by an user from an affiliated resource server, with the possibles scopes for action on it.
And then the authorization scheme would be parameterized by this user, in the third party context.
There he should be able to set up authorizations rights for a resource he created on an associated resource server, then associating a specific scope to a specific "requesting party" user that would access using a specific "requesting party" client.
So we need a way for the user to configure this association matrix, ideally on the authorization server directly (as it could there use the same identity he used to declare the resource from the resource server).
On the UMA2 examples provided by the documentation of the authorization servers we tested (WSO2-IS, Gluu Server), the policies are simple test examples with hard-coded assertions.
And no endpoint provides a way to set up the authorization rights as we need.
At first we thought of creating policies for each association needed by the user, associating all specific values, as in the WSO2-IS UMA2 policy example.
But seeing that the WSO2-IS endpoint for policies creation only accept basic login/password authentication (more of a technical access then), and that in Gluu Server policies are working in a globally configured manner. This de-multiplied policy set-up doesn't seem the correct way to do it.
So is our authorization scheme something beyond the scope of authorization servers in UMA2 scheme?
It needs to be tightly associated with the authorization server data, as it needs to know the "resource owners" and "requesting party" users, the "resource servers", the "requesting party" clients, and all resources created with associated scopes, identified on it.