Custom Authorization Roles

[nemerna]

Hi, i was looking for a way to be able to customize the Authorization Roles being used by the registry. as i know the registry support by default 3 roles, (sr-admin, sr-developer, sr-reader).

the question is, how can i create new Roles to be used by the application.

for example, sr-reader1, that can read only specific Artifacts.

thanks!

[andrewstevenson]

I'm also interested in this and potentially OPA support.

[carlesarnal]

Hello, as of today, this is not possible. There are some options around authorization that allow some level of customization, like configuring the name of the role for a concrete level of permissions (see https://github.com/Apicurio/apicurio-registry/blob/master/app/src/main/resources/application.properties#L178).

The only option slightly related to this is allowing only the owner of a particular resource to perform some operations, you can enable that option using this property https://github.com/Apicurio/apicurio-registry/blob/master/app/src/main/resources/application.properties#L172.

That said, this property cannot be enabled only for a particular resource.

[andrewstevenson]

@carlesarnal Any plans to add pluggable authentication and authorisation, we are willing to potentially help and any pointers of where to start?

[EricWittmann]

Hey @andrewstevenson - we have a few things being discussed that are relevant here. The first is that we have a POC using Authorino as the auth layer for registry:

https://github.com/kuadrant/authorino

There are some things that still need to get worked out, but there may be some promise here. It's not quite clear to me (yet) whether this approach can work well to support per-artifact authorization use-cases.

More broadly, the question of how to support per-artifact access is not something we've tackled yet. And I think it's a difficult enough thing to achieve that it would probably be hard to know exactly where to start. I'll give you some info on what we have right now.

Our current authorization approach works by adding appropriate java annotations to methods in the JAX-RS layer. For example:

https://github.com/Apicurio/apicurio-registry/blob/master/app/src/main/java/io/apicurio/registry/rest/v2/GroupsResourceImpl.java#L185

    @Authorized(style=AuthorizedStyle.GroupAndArtifact, level=AuthorizedLevel.Write)
    public void deleteArtifact(String groupId, String artifactId) {
        requireParameter("groupId", groupId);
        requireParameter("artifactId", artifactId);

        storage.deleteArtifact(gidOrNull(groupId), artifactId);
    }

The annotation @Authorized indicates that the user must have "write" permission in the registry, and that the method contains both a groupId and artifactId. That information can be extracted from the method when enforcing the authorization rules. The authorization itself is enforced via a CDI interceptor:

https://github.com/Apicurio/apicurio-registry/blob/master/app/src/main/java/io/apicurio/registry/auth/AuthorizedInterceptor.java

Have a look at that interceptor - it is well documented in the code and should be easy to follow. That is one place we would need to extend to implement per-artifact access enforcement.

There are two additional areas I can think of that would need to be explored. The first is how to grant the appropriate permissions. Is there some UI that would allow some user to grant a role to another user that would be needed to access a particular artifact?

And finally there is the issue of search. If users can only see a subset of the artifacts, then the SQL query that fetches the artifacts will need to be modified appropriately. It also suggests (to me) that the role grants themselves will need to exist in the application's DB, so that queries can be efficient (joining the user's granted roles when querying the artifacts, and filtering against required roles).

Sorry for the delay in responding to this. It's a very interesting area and we are indeed very interested in evolving our auth layer to eventually supporting authorization rules at the artifact granularity, but don't currently have the bandwidth for that.

[carlesarnal]

@andrewstevenson I'm closing this as stale, if you still have interest in it, please, re-open it at your convenience.