Resources Configuration

[ghost]

First of all thank you for the Glewlwyd project! We are using it for 3 years now and it works great for us.

Is your feature request related to a problem? Please describe.

1. Glewlwyd seems to consider Scopes something > permissions e.g. g_admin, g_profile; whereas most articles/documentations I read on the internet consider them as permissions (read.products, write.products, update.products etc). Glewlwyd is not limiting a user from doing this though.
2. Roles/Groups is something out of the scope of OAuth2 but some services like Azure AD include Roles in JWTs.
3. Many projects also try to bridge the gap between message based protocols like MQTT and the authentication/authorization need over OAuth2. https://github.com/iegomez/mosquitto-go-auth#jwt

Describe the solution you'd like
Roles based policies with each role containing Scopes would be a nice feature that would make the user's management easier.
Apart from HTTP resources, maybe it would be possible to have other types of resources (e.g. topics, channels)

Describe alternatives you've considered
An alternative solution for us was keycloak but it is really hungry on computer resources and we want to avoid.
https://www.keycloak.org/docs/latest/authorization_services/

Additional context
I haven't found how to administer resources and connect them with scopes from the Glewlwyd UI but I see the tables and connecting table in the database. (g_resource, g_resource_scope, g_scope)
ACLs is something used by many types of applications e.g. message brokers(mosquitto), event brokers (eventstoredb) maybe it is something that should be considered.

[babelouest]

Hello @thoism ,

First of all thank you for the Glewlwyd project! We are using it for 3 years now and it works great for us.

Thanks, although I have a question, do you use Glewlwyd 2.x or still use the version 1.4 from 3 years ago?

Roles based policies with each role containing Scopes

Correct me if I'm wrong, but what I understand with your request is to allow then administrator to group scopes into groups of scopes, so it doesn't have to add multiple scopes multiple times for each user. Is that so? If I misunderstand, can you describe a use case on what you expect?

Basically, you could use the scopes as they are to reproduce the ACL but I understand it would be painful and time consuming.

If we are on the same page, I can consider improving the scopes management to add groups and ACLs but I want to make I got it right, mostly because I won't use it myself so I can't guess what you would need.

The database tables g_resource, g_resource_scope are not in Glewlwyd 2.x, it's in the old version 1.x that they were used and were used only as an information of what resource servers can be connected to this auth server and what scope they are expecting, see the screenshot for an example.

But they only existed as a useless information and I never used it myself, nor knew anyone who used it, so I dropped this feature in 2.0.

[ghost]

Thanks, although I have a question, do you use Glewlwyd 2.x or still use the version 1.4 from 3 years ago?

We are using 1.4 I guess.

Correct me if I'm wrong, but what I understand with your request is to allow then administrator to group scopes into groups of scopes, so it doesn't have to add multiple scopes multiple times for each user. Is that so? If I misunderstand, can you describe a use case on what you expect?

Yes exactly!

If we are on the same page, I can consider improving the scopes management to add groups and ACLs but I want to make I got it right, mostly because I won't use it myself so I can't guess what you would need.

Groups and roles are normally considered as two different things meaning:

1. Roles define a type of user and applications assign scope(permission) and access control to roles.
2. Groups basically are a set of users. Users can belong to zero or more groups and inherit any roles assigned to a group

I believe implementing Roles takes precedence over Groups.

Yes actually I am thinking about something along these lines:

And as you said use the Scopes (Permissions) to determine the read(subscribe), write(publish) on specific MQTT topics.

Example ACLs (for topic patterns e.g. a/#/event/+):

user service-a
topic write a/#/event/+
topic read  a/#/command/+
topic read  b/#/event/+
 
user service-b
topic read  b/#/command/+
topic write b/#/event/+
 
user admin
topic write a/#/command/+
topic write b/#/command/+
topic read  a/#/event/+
topic read  b/#/event/+

This project for example expects two HTTP endpoints:

jwt_getuser_uri - URI for username/password check
jwt_aclcheck_uri - URI for acl(topic/permission or scope if you prefer) check

The code provides more information about the expected parameters and response and there are also different modes of both request and response types.

If we take the jwt_aclcheck_uri then the plugin would send to Glewlwyd the following parameters:

• "clientid"
• "topic"
• "acc"

The endpoint is expected to respond with a 2.x HTTP code if the mode is set to status which means authorized.

What is a bit confusing though is the clientid; which is the OAuth2 client application or the actual user? Remains to be seen I guess. What is also more confusing to me still is if I should consider each micro-service as a client to OAuth2 or consider the whole software system as a client to OAuth2. Due to the nature of MQTT and HTTP though I think both users and services should be using a user since a service should not be able publish a message on another service's topic.

Could this be implemented as a new plugin to support this Glewlwyd - mosquitto-go-auth integration?

@babelouest thank you for your prompt reply!

[babelouest]

We are using 1.4 I guess.

No problem, but note that I don't maintain this version anymore, and all improvements will be in the current 2.x branch.

Concerning your feature requests, I see 2 different ones in your message.

The first one is to add the concept of scope groups in the application, and users can be linked to those groups. That can be done in a future release, since it's not very complex to implement.

The second one is to add a new plugin that will implement an ACL validator. This plugin should provide an API to verify ACLs and credentials.
This last one looks more difficult for me to implement.
The software you mention doesn't look to be based on a standard, therefore I wouldn't want to spend time in maintaining the plugin, if the implementation reference changes every other morning.

[ghost]

Hi @babelouest

The first one is to add the concept of scope groups in the application, and users can be linked to those groups. That can be done in a future release, since it's not very complex to implement.

I guess defining them as roles will allow for supporting user groups later if the need arises without changing concepts.

The second one is to add a new plugin that will implement an ACL validator. This plugin should provide an API to verify ACLs and credentials. This last one looks more difficult for me to implement.

I believe the Eclipse Mosquitto - Dynamic Security Plugin implements this feature really nicely but there is also Casbin which is a library dedicated to ACLs.

The software you mention doesn't look to be based on a standard, therefore I wouldn't want to spend time in maintaining the plugin, if the implementation reference changes every other morning.

Totally agreed here. I wish I could avoid it.

I am wondering if it would be an option to have the JWT token optionally contain:

1. Roles
2. Scopes
3. Resources

as claims; in this way it would be easier to validate authorization even if some disagree.

[babelouest]

@thoism , if you're ok, I'll leave this issue as is and we'll continue it in parralel casbin/casbin-cpp#100

[babelouest]

Also, you can check Glewlwyd's OIDC plugin implementation of OAuth 2.0 Rich Authorization Requests Draft 03 .

See this paragraph for the configuration details of this feature, this may be a solution for your issue

See https://medium.com/oauth-2/rich-oauth-2-0-authorization-requests-87870e263ecb for a explanation of the concept for example

[ghost]

Also, you can check Glewlwyd's OIDC plugin implementation of OAuth 2.0 Rich Authorization Requests Draft 03 .

See this paragraph for the configuration details of this feature, this may be a solution for your issue

See https://medium.com/oauth-2/rich-oauth-2-0-authorization-requests-87870e263ecb for a explanation of the concept for example

@babelouest to be honest I have already read that and it looks very interesting. I will look into it better in the next few days and see if I can make it work for our case.

[ghost]

@thoism , if you're ok, I'll leave this issue as is and we'll continue it in parralel casbin/casbin-cpp#100

I am amazed how this this turned out. I am really thankful for the efforts from all sides and I hope other users will see the value of this.

As I already mentioned, EventStore and Kafka use ACLs as well which might make this feature available for 2 of the most widely used event brokers as well.

Thank you!

[babelouest]

Awesome!

Don't hesitate to open a new issue of you have problems or questions regarding rich auth requests.

I've implemented it without a use case nor the need, "for the cause" I'd say :)
So the implementation might have bugs or would require new features.