How to access the business system through jwt login mode through business system user information

[AuroraLove]

When I use the jwt login method to access the turms service, after the user logs in successfully, the basic business of sending messages can be performed normally. But when I created the group, I found that it could not be created normally. I carefully checked the relevant source code and Mongo's storage information, and noticed that the user information in the relevant business system was not recorded in turms. The subsequent associated users who need to create groups and group permissions do not have associated user information. When I tried to create a user record in Mongo that was consistent with the user ID in the business system (while saving the relevant permission information), I found that the group could be created normally. I now plan to synchronize business user information to the turms service by implementing user plug-ins. In this case, I would like to ask the author how to consider the access solution of the jwt business system. There is a problem with my usage that causes this situation. ? Or am I missing some ability? Or maybe my improper use resulted in incomplete processing of user information. I would also like to ask if my access method violates the original intention of turms design? Or there is a better implementation solution

[JamesChenX]

Thanks for your feedback.

Honestly, I haven't taken the time to adapt the whole business workflow to support authentication types other than PASSWORD, so your confusion is understandable, and it's a problem of Turms. I am working on this problem and will write detailed documents for your business cases this weekend or next week.

The background of the problem is that when we write the business workflows, we assume the user info is stored in MongoDB most of the time, so there maybe some cases that will not work well if you use the jwt, ldap, etc authentication mode because these authentication modes are designed NOT to store users' info in MongoDB managed by Turms on purpose.

I now plan to synchronize business user information to the turms service by implementing user plug-ins.

I will take over your business requirements mentioned here, so you can ignore this problem right now, wait for me to adapt and write docs, and focus on implementing your business logic.

[AuroraLove]

Thank you very much for the detailed reply.

This also roughly confirms my guess that turms, as a core basic module, should not manage too many business system-level operations.

Thanks again and looking forward to the release of new documentation. After researching so many products, I think turms is the best IM open source product.

[JamesChenX]

Hi @AuroraLove, I have adapted the code, and you can pull the latest code in the develop or master branch, or pull the latest images to have a try. They should work well with your requirements currently.

---

For your questions:

But when I created the group, I found that it could not be created normally.

It won't work fine with the jwt, http, and ldap identity and access management type because turms-service would find the user permission group for the requester (the logged-in user) to check if the user has permission to operate on the group, but turms-service would never find it because you don't need to store the data of users in MongoDB when you use jwt, http, or ldap, which is designed in this way so that you don't need to waste time syncing users' data to Turms.

After changes, turms-service will use the default user permission group for the requester if it cannot find a stored one currently. The new code is quite simple and you can check it if you want: https://github.com/turms-im/turms/commit/1e6dc1b2359b0dba36527fdf880c2aeb69fe29b3

For more information, I just wrote a doc for it and hope it can help you understand the identity and access management of Turms better.

English: Hosted and Non-Hosted Identity and Access Management Mechanisms Chinese: 托管与非托管身份与访问管理机制

[AuroraLove]

Hi,thanks for the reply, something was delayed the past two days. I updated the code and found that although the group can be used normally, a new problem has arisen. When I created the user application, I found that there were no users of the persistent business system in the library. Therefore, related functions such as adding friends, establishing user relationships, etc. could not be used normally. I want to isolate business functions from turms functions and let turms be fully responsible for im-related functions. Therefore, I feel that I still have to implement a plug-in that persists users to turms to avoid some subsequent problems. But during the implementation process, I discovered a new problem. The plug-in entrance you provided is in the gateway. After registering the plug-in, I found that there was no relevant capability when I called the service service. I carefully checked the login verification method you provided, and I noticed that you created a simple user business service in the gateway, but it did not add user-related capabilities. So for the plug-in implementation here, how should I achieve user persistence? Should the operation of adding new users be directly added to the user business, or should the service interface be called through the http service to add new users (but there will be permission issues), or should the operation be implemented by adding an rpc service interface?

[JamesChenX]

When I created the user application, I found that there were no users of the persistent business system in the library

If you mean there were no user records stored in MongoDB, it is true and designed this way if you don't use the password as the identity and access management mechanism.

Therefore, related functions such as adding friends, establishing user relationships, etc. could not be used normally

They should work properly. If these features don't work, they are considered bugs. You can always @JamesChenX to fix them.

Although no user records need to be stored in MongoDB, turms-service will still use user IDs to store the relationships between users and groups, etc. For example, if user A adds user B as a friend, turms-service will store a relationship record that contains both user IDs in MongoDB.

(p.s. if a user needs to access turms-gateway, it is always required for them to pass a user ID, so turms servers always know their user IDs no matter which IAM mechanism you use)

The plug-in entrance you provided is in the gateway

No. Both turms-gateway and turms-service have their extension points for developers to implement. For details, you can read the docs for Turms plugins: https://turms-im.github.io/docs/server/development/plugin.html#custom-plugins

So for the plug-in implementation here, how should I achieve user persistence?

All business logic should be implemented in turms-service. turms-gateway has a simple UserService because turms-gateway uses it for password authentication without unnecessary calls to turms-service.

As you have said Therefore, I feel that I still have to implement a plug-in that persists users to turms to avoid some subsequent problems, but it is not the truth, so you should not implement a plugin for persisting user records for this reason.

[AuroraLove]

They should work properly. If these features don't work, they are considered bugs. You can always @JamesChenX to fix them.

OK,I understand.When I used the jwt login method, I noticed that although there was a record of the request, when my client processed the request, it could not pass normally, that is, it could not establish the user relationship normally. When I manually added the user with the same ID to turms Among users, the user relationship can be established normally when processing the request again. This may be a bug. You can try it.

(p.s. if a user needs to access turms-gateway, it is always required for them to pass a user ID, so turms servers always know their user IDs no matter which IAM mechanism you use)

This is because I have carefully read the document you wrote. In the user plug-in endpoint entry, you provide optional synchronization user operations, and it is specified here that the plugin is on the turms-gateway side. But when I tried to handle it here, I found that the main entrance of the method added by the user is on the turms-service side, so I don’t know how to implement it here.

[darkSystemCode]

我和你的问题一样，turms-gateway可以做一个简单的用户存储，因为，turms-server-common存在User实体，turms-gateway注册了userRepository。但是，依旧无法解决你提出的问题，因为建立好友关系需要userVersion的lastDate，这个数据在turms-gateway端是无法实现的。

[AuroraLove]

Yes, I had added relevant synchronization user code to the gateway before, but found that there were problems with many business operations and deleted it. Now temporarily add user data by calling the service method through the business system