User Repository as microservice

[agkoutis]

Hello,

I am trying to connect simpleIdService with an external user repository as a microservice.

What I have done so far is to implement a custom IUserRepository to communicate with the microservice API using a HttpClient but this is not enough because I still need to override several methods in the pwd area
AuthenticateController : BaseAuthenticationMethodController

like the "ValidateCredentials" method.

Any ideas on how I can do it? Do I need to change the Controller & method on UI views or this can be done in a different way?

Thanks

[simpleidserver]

Hello !

If you create a class called "CustomApiUserRepository" and implement the interface "IUserRepository" along with its methods, it will be sufficient.
There are several explanations that clarify why the "ValidateCredentials" method is not working:

• The User class contains a Source property, which must be equal to pwd.
• The User contains a list of Credentials. If you are using the login and password authentication method, the user must have at least one credential with the following properties:

Name	Value
Id	GUID
CredentialType	pwd
Value	SHA256(pwd)
IsActive	true

This solution is not easy to implement and introduces a strong dependency between your API and SimpleIdServer.

If your API only stores user information and not their credentials, a better solution is to implement an auto-provisioning workflow.
We currently support only two sources: LDAP and SCIM.
However, we can implement a third source called API. This source will extract users from an API and insert them into SimpleIdServer.

KR,

SID

[agkoutis]

Thanks for your quick reply KR,

My microservice stores credentials and exposes validation endpoints for validating username & passwords and responses a json with a list user's claims. My goal is to validate the password on the microservice and then map the response to a SimpleIdServer.IdServer.Domains.User

I don't feel that simply implementing IUserRepository will be enough or the performance will be poor, because of IQueryable Query() & _authenticationHelper.GetUserByLogin(UserRepository.Query() method that needs all records to perform LINQ, plus i still need PasswordHelper.ComputeHash from simpleIDserver (which is something that I wish to bypass).

So to sum up, i want to override the ValidateCredentials method with a http call and map the response to SimpleIdServer.IdServer.Domains.User

Currently i only need to implement pwd area.

[simpleidserver]

At the moment, it is not easy to accomplish this. I am going to refactor the solution to provide the option to override the 'ValidateCredentials' method. The ticket can be found at #600 (#600)

[simpleidserver]

@agkoutis : Hello,

I have made some modifications in the origin/master branch to support your scenario.

Here are the steps to follow:

1. Fetch the latest changes from the origin/master branch.
2. Edit the Program.cs file and uncomment the line ConfigureCustomAuthentication.
3. Run the application and authenticate with the fake account, using the login: login : provisionedUser and password : password.

You can edit the class Services\CustomPasswordAuthenticationService to add your logic. This class contains three functions :

• GetUser : Get the user by a technical identifier or the login. In your scenario, there is no need to provide an implementation.
• Validate(string realm, User authenticatedUser, AuthenticatePasswordViewModel, CancellationToken) : In your scenario, there is no need to provide an implementation.
• Validate(realm, authenticatedUserId, viewModel, cancellationToken) : Add your logic to contact your REST.API, which will check the user's credentials. If the verification is successful, you MUST create and store the user in the Database.

A local account must ALWAYS be created because SimpleIdServer uses the user's information during the processing of different OPENID-grant-types, such as Consent management, OAUTH2.0 grant management, Sessions, and more.

[agkoutis]

Hello,

Thanks for the super fast response!

Yes, I also believe that user information for sessions & consent must be part of the SimpleIdServer , but as far as the local accounts I will try to store user information in a temporary record until the session is complete or expires. Let me check on this and I will come back.

AG

[agkoutis]

I have implemented a custom AuthenticateController with views and im waiting for the 4.0.5 release to implement ConfigureCustomAuthentication. Right now, I'm trying to provide some claims from user info endpoint again, using a microservice.

After doing some research, I think that several services need to decouple from API Controllers and move to separated services with Interfaces like the userinfo endpoint, to be more flexible and provide out of box functionality. Im still working on a POC

Thanks,
AG

[simpleidserver]

Before making a technical proposal to fulfill your requirements, could you please list the information you wish to manage in the custom API?

Currently, I have identified only two properties:

• The password.
• The claims.

Is this correct?

[simpleidserver]

@agkoutis : I have created ticket #603 to add a new service that will retrieve the list of claims for the authenticated user. This class will be utilized by SimpleIdServer to obtain the list of claims for the authenticated user.

In the end, you will be able to:

• Implement the IUserClaimsService interface and make calls to your API to retrieve the list of claims. (IN PROGRESS)
• Implement the IPasswordAuthenticationService interface and use your API for user authentication (DONE AND PRESENT IN THE BRANCH release/4.0.5)

[agkoutis]

Before making a technical proposal to fulfill your requirements, could you please list the information you wish to manage in the custom API?

Currently, I have identified only two properties:

* The password.

* The claims.

Is this correct?

Hello @simpleidserver , Microservice manages the user authentication and contains a list of claims. Password is sent from SIDServer login page with RSA encryption to LoginService API. LoginService decrypts passwords and hashes with users' salt to compare to stored value.

Apart from that, the microservice also contains users claims by provider. So my goal is, when a new token is requested, the SIDServer will call the micro service and request user claims to include to Token payload (user - API specific Claims like role access). Next, when the App client uses the userinfoendpoint the SIDServer again will request from the microservice the identity claims and will respond only to the claims that the user is allowed to request and he is request (using scopes). The mapping between Scope and claims exists on SIDServer.

So as a result, the SIDServer will get all user's claims from the api and he will include the claims in the userinfo endpoint based on the client app request (scopes from token)

There are several endpoints that users can change passwords, update their profile (or automatically update with the response from external provider claims). Also service contains a user lock mechanism (by admin or failed login retries) , change password policy, and password complexity policy.

Thanks!

[simpleidserver]

I have made some modifications in the branch 'release/4.0.5'. It is now possible to call your Custom API to retrieve the user's claims and to verify the user's credentials.

You can try the sample project here: https://github.com/simpleidserver/SimpleIdServer/tree/release/4.0.5/samples/CustomUserApi

The class 'CustomUserRepository' is used to fetch the claims from your API, and the class 'CustomPasswordAuthenticationService' is used to verify the user's credentials.

Please notify me if the changes fulfill your needs :)

Kind Regards,

SID

[agkoutis]

Hello! I just implemented the CustomUserRepository.

I'm missing a part and I need some information about mapping, please. In CustomUserRepository I'm supposed to return all users' claims, and SID will filter them based on clients' app request (and allowed) scopes in user info request?

Thanks again!

[simpleidserver]

All the claims of the User must be returned by the CustomUserRepository.
SimpleIdServer is using the scope to filter the claims :)

[agkoutis]

Great! Thanks!

[agkoutis]

Hello all,

I have started the implementation of the custom repository and I noticed that some implementations still use EF regarding the user information in the Consents Controller.

So when the controller calls the var user = await _userRepository.GetBySubject(nameIdentifier, prefix, cancellationToken); which returns the response from the API Call (note that users are also stored to SID db) the await _userRepository.SaveChanges(cancellationToken); does nothing. (probably because it does not contain tracking changes I'm guessing)

Any suggestions?
Thanks

[simpleidserver]

Hello,

In your CustomUserRepository class, the function GetBySubject function must return a User from the DbContext to ensure that ChangeTracking works correctly.
In the GetBySubject function, you can add logic to retrieve claims from an external API. For example:

public async override Task<User> GetBySubject(string subject, string realm, CancellationToken cancellationToken)
{
    var result = await GetUsers()
                    .FirstOrDefaultAsync(u => u.Name == subject && u.Realms.Any(r => r.RealmsName == realm), cancellationToken);
    if(result != null && result.OAuthUserClaims != null)
    {
        using (var httpClient = new HttpClient())
        {                
            var userClaims = await httpClient.GetFromJsonAsync<IEnumerable<UserCl>>($"{_options.BaseUrl}/users/{result.Id}/claims");
            result.OAuthUserClaims = userClaims.Select(c => new UserClaim
            {
                Id = Guid.NewGuid().ToString(),
                UserId = result.Id,
                Name = c.Name,
                Value = c.Value
            }).ToList();
        }
    }

    return result;
}

private IQueryable<User> GetUsers() => _dbContext.Users
                    .Include(u => u.Consents).ThenInclude(c => c.Scopes).ThenInclude(c => c.AuthorizedResources)
                    .Include(u => u.IdentityProvisioning).ThenInclude(i => i.Definition)
                    .Include(u => u.Credentials)
                    .Include(u => u.ExternalAuthProviders)
                    .Include(u => u.Groups).ThenInclude(u => u.Group)
                    .Include(u => u.Devices)
                    .Include(u => u.Realms);

If the user exists in the REST.API but not in the SimpleIdServer database, you can override the GenericAuthenticationService and add provisioning logic to create a local account.
The same mechanism is used when a user authenticates with an external account like Facebook.

I've updated the sample project (https://github.com/simpleidserver/SimpleIdServer/tree/master/samples/CustomUserApi), demonstrating how to use an external REST.API to authenticate the user. The most important classes are:
The most important classes are :

• CustomPasswordAuthenticationService : performs login & password authentication and creates a local account if the user doesn't exist in the local database.
• CustomUserRepository : gets a user by subject and fetches claims from the REST.API.

[simpleidserver]

Hello :)

Regardless of the chosen solution, all the collection properties of a user must be loaded from the database.
Examples include Devices, ExternalAuthProviders, Credentials, Consents, Sessions, IdentityProvisioning, Realms, etc.
All this information is required by SimpleIdServer.

If the issue is not storing personal information or claims in the Sid database, you can manipulate the Entity Framework Core configuration to exclude certain properties by removing the Include(u => u.OAuthUserClaim) instruction.

The proposed solution, which involves creating a separate repository for each user property (e.g., ConsentRepository, ConsentUserIdentityProvisioning, ConsentExternalAuthProvider), does not improve performance.
Instead of having a single SQL script with several inner | outer join statements to retrieve a user, we will execute more than one SQL script (RPC connection) to rebuild the entire user.
Most of the time, SimpleIdServer requires all the information to perform different grant types.

You need to establish synchronization between the API and the SID database. Both the API and SidServer must have the same UserId; otherwise, you cannot correlate the user.

[agkoutis]

Hi,

Well, the proposal aims for more flexibility and customisation, but I can understand and respect your vision.

Apart from this, as far as performance is concerned, microservice logic provides workload-sharing on different machines.

For example, our deployed SID in the Azure App Service S1 plan has a nearly average 100% CPU load (hosts only SID). So, besides the flexibility and customisation, I'm trying to reduce the LINQ to SQL process and excess work for this machine and transfer it to the microservice (for the information that I have mentioned).

[simpleidserver]

For some unknown reason, the performance issue is originating from the Centralized Configuration.
I have created a ticket #699 to conduct further investigation.

In the meantime, could you please coment the ConfigureCentralizedConfiguration function in the Program.cs file? This should address the issue.

[agkoutis]

Hello, yes problem with CPU leak was fixed
ty

[simpleidserver]

The performance problem is now fixed in the ticket #699