How to programmatically create a new user?

[horacioj]

Hello,

This is the case:

I would like to auto-register users after validating credentials against another authentication provider, but this is irrelevant to the problem I'm facing.

After the user successfully authenticates in the external system, I would like to create (if it doesn't already exists) new a user account in Oqtane to make it work as any regular user account. How to take care of keeping things in sync and secure is irrelevant to to the problem I'm facing.

Everything goes well until I do:

user = await UserService.AddUserAsync(user);

This returns null because (a) nobody is already logged in (this module acts as an alternate to the standard login module), and (b) AllowRegistration is disabled in the site.

In \oqtane.framework\Oqtane.Server\Controllers\UserController.cs , inside private async Task<User> CreateUser(User user), the first problem I'm facing is that of course if (User.IsInRole(RoleNames.Admin)) is false because there is nobody logged in.

In addition,

verified = false;
allowregistration = _sites.GetSite(user.SiteId).AllowRegistration;

This means the user will not be created as verified and it will not be created at all because AllowRegistration is disabled.

So, the question is, how can I programmatically create a new user without having to be running the site already logged in as an Admin?

Is there a way to temporarily change the security context for this to work? (For example, Sitecore allows doing something like this. i.e. run a piece of code impersonating someone else).

Said all of this, which options do I currently have to programmatically create a new user in Oqtane avoiding the limitations and security checks set in private async Task<User> CreateUser(User user)?

Should I copy & paste the code and create my own version or is there a better way (i.e. using the Oqtane APIs as they are)?

Thanks!

** EDIT **
I understand Oqtane's server API is not the same as the DNN API, but I guess there should be a way to do this kind of things 'server side' outside the context of who si running the code?

[sbwalker]

Oqtane uses a client/server architecture and it's REST API is designed to ensure only authorized clients have access. There is no option to bypass these security requirements, as that would expose a security vulnerability. If you want to create an external client application that adds users I would suggest you create a flow which first establishes a security context and then calls the API. You can use the standard HTTPClient or a library such as RestSharp to do this.

[horacioj]

The public API for core services needs to be secure and only provide access to trusted users.
Allowing access to untrusted users would expose a security vulnerability to the framework.

I totally agree, @sbwalker
The problem is, there is no way to authenticate to the API programmatically, which make it useful only for the Oqtane core itself. It cannot be utilized in modules. It isn't acting as a public API because there is no way to authenticate for using it. This is a big problem, I think.

[sbwalker]

@horacioj I have to admit that I am really struggling to understand your questions and comments in this discussion thread. I have created many external modules for Oqtane and never run into any difficulties. Perhaps the issue you are encountering is specific to your use case. I don't think I fully understand what you are trying to accomplish... so that may be contributing to my confusion.

[horacioj]

Sorry, never mind. The answer to the original question is " you can't programmatically create a new user" unless the user using your module is logged-in as an Administrator. The thread was no longer about what the title says... So, better leave it as it is.

[sbwalker]

If we focus on programmatically creating a new user from an Oqtane module there are a few possible options:

1. Call the Oqtane User API. In order to do this the logged in user must be a site administrator.
2. Enable "Allow User Registration" in Site Settings. This will allow anyone to create a user account using the Oqtane User API.
3. Expose your own API which contains a method that has more relaxed security constraints than the Oqtane API. Within this method you can implement whatever code you want. Please note that by taking this approach you may be exposing a security vulnerability for the site as you are effectively bypassing the security restrictions for the core framework - but that is ultimately your responsibility.

[horacioj]

Thank you, @sbwalker. The options are clear.

Regarding the 3rd. option, (in my case, the module's API method taking care of creating a user is secured by a different external authentication), something like creating a user should be re-coded as there is no way to use the Oqtane logic (API) already created for this (public async Task<User> Post([FromBody] User user) / CreateUser(User user) at \Oqtane.Server\Controllers\UserController.cs).

[W6HBR]

Hate to bring back an old topic, but I'm struggling with this similar problem.

I need non-admin users assigned to a custom role (e.g. "Profile Editors") to be able to create/edit users and their profile properties (about 40 profile settings fields), but not be a full site administrator.

My first thought was to use copies of the Users module Add/Edit/Roles screens in my own module, but then realized that the API security still wouldn't allow this to function.

I'm looking for a little more guidance than just #3 above from Shaun. Seems that some granular assignment of rights via roles could benefit many orgs/users as having an all or none access via Administrator is just too restrictive.

As a work-around, how could I have a regular user call the built-in user add/edit screens via impersonation with an Admin user credential?

[sbwalker]

No worries about bringing up this topic again... clearly it is still a challenge. Oqtane is a modular application framework which means that flexibility is extremely important. It uses a client/server architecture which means that front-end is fully separated from the back-end. The back-end functionality is exposed via an API and currently that API uses some security conventions which are intended to safeguard the system from inappropriate use - however to accomplish this, the implementation lacks flexibility. Specifically, many of the API methods include static role specifications for authorization (ie. a user must be in the Administrators role in order to perform an action).

The optimal way to make the API more flexible would be to implement dynamic authorization policies. This would allow the Administrator of a site the ability to specify which roles or users are allowed to access a specific API. Most likely this would need to be split into Read/Write operations and in order to adhere to the "headless" approach, the permissions would need to be maintained independently from the current View/Edit permissions which are specific to the client UI. The separation would provide API management capabilities for other types of native client applications.

This is not a small amount of effort as it would affect the entire framework API layer. It would need to be implemented in a consistent manner across all APIs with a centralized UI for management. And it would need to support third party module APIs as well. Luckily, the existing permissions model in Oqtane was developed in flexible manner so it could support this use case.

[W6HBR]

As much as I hate making changes to the core framework, I solved this issue with a few small changes to UserController.cs, UserRoleController.cs and SettingController.cs. @sbwalker - Your comment about the API methods including static role specifications gave me an idea to extend that logic with two additional static roles of "Profile Editors" and "Role Editors".

This now allows me to assign users to these roles for the purpose of maintaining site users without being a full site Administrator.

Example changes to UserRoleController.cs:
[Authorize(Roles = RoleNames.Admin + ",Role Editors")]

Example changes to UserController.cs:
[Authorize(Roles = RoleNames.Admin + ",Profile Editors")]
and
if (!User.IsInRole("Profile Editors") && !User.IsInRole(RoleNames.Admin) && User.Identity.Name?.ToLower() != user.Username.ToLower())

Example change to SettingController.cs:
case EntityNames.User:
      filter = !User.IsInRole("Profile Editors") && !User.IsInRole(RoleNames.Admin) && _userPermissions.GetUser(User).UserId != entityId;