Cannot create, set, or change Roles via API

[Tom]

Having problems with authentication Roles in the .NET SDK:

• Cannot set a Role when creating a new user. I must include a Role.Id in the new User, but it is ignored; all users are created with the Role "Registered".
• Cannot change the Role for an existing user. No error is given when using the example UpdateUserById code, but the user.RoleId does not change. Other values such as user.Email can be changed by this method.
• Cannot add a new role. Am getting the error "Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)". I though the Id would be created by the Backend Services.

 Here is my code for trying to add a new role:

Role newRole = new Role() {
    Name = "Gibbergoo",
};
CreateResultItem cri = await CreateRoleAsync(new Guid(everliveApp.AppSettings.ApiKey), newRole, masterKey);

 - - - - -

public async Task<CreateResultItem> CreateRoleAsync(Guid applicationId, Role newRole, string masterKey) {
    var metadata = new EverliveAccount(new EverliveAccountSettings(AuthorizationStrategy.MasterKey, masterKey));
    return await metadata.WorkWith().Application(applicationId).Roles().Create(newRole).ExecuteAsync();
}

 

 

 

​

[Anton Dobrev]

Hi Tom,

Could you please try with the following:

Role newRole = new Role() { Name = "Gibbergoo"};

CreateResultItem cri = await CreateRoleAsync((everliveApp.AppSettings.ApiKey), newRole, masterKey);

Here is the method (note the substitution of the ApplicationId with its API key:

public async Task<CreateResultItem> CreateRoleAsync(String myApiKey, Role newRole, string masterKey)
{
    var metadata = new EverliveAccount(new EverliveAccountSettings(AuthorizationStrategy.MasterKey, masterKey));
    return await metadata.WorkWith().Application(myApiKey).Roles().Create(newRole).ExecuteAsync();
}

The Metadata API requires the Application Id or the API key of the backend application.

The API key is a string but not a valid string to construct a GUID - thus  the error that is thrown by the environment run-time, not by Backend Services because of the usage of the new Guid constructor with the supplied API key.

The server will generate the Id of the new role and return it as a property of the CreateResultItem.

Let me know if this works for you.

Regards,
Anton Dobrev
Telerik

 

 

[Tom]

Switching to the API key does work. Thanks for that correction.

 Is this the same reason that I cannot change the RoleId of an existing user? In the snippet below, UpdateUserById returns "true", and the email address is updated but not the RoleId.

 

User user = await GetCurrentUser(everliveApp);
user.RoleId = new Guid("784a5850-19a3-11e5-b1e2-f57baaa38489");
user.Email = "[e-mail]";
bool result = await UpdateUserById(everliveApp, user.Id, user);

 - - - - -

public async Task<bool> UpdateUserById(EverliveApp app, Guid userId, User updateObject) {
    return await app.WorkWith().Users().Update(userId, updateObject).ExecuteAsync();
}

[Anton Dobrev]

Hello Tom,

Given the fact that security permissions on the backend are subject to Role-based security, it is not a safe path to allow a user account to be registered with a certain role. This could only be done when master key authentication is used. Thus only the master account can create a user assigned to a certain role. Otherwise, the server ignores the Role field of the request.

Do not use the master key of your backend project in a client app or expose it to third parties.

More information is available here:

• Register Users with the .NET SDK
• Using Master Key authentication with the .NET SDK

Let me know if this answers your question.

Regards,
Anton Dobrev
Telerik

 

 

[Tom]

I see that I was looking at Roles the wrong way. I was considering assigning users to roles as one would assign users to groups. What is the suggested method for creating groups for Backend Services authentication users? (Example: I am authenticating users in my division and want to have different groups for different departments such as Purchasing and Accounting.)

[Anton Dobrev]

Hello Tom,

Thank you for specifying this. I'd suggest that you have an administration layer that assigns users to groups and roles. I hope that the information in this forum thread that discusses a similar approach might would be helpful for you.

Let me know if further questions arise.

Regards,
Anton Dobrev
Telerik