services.AddIdentityServer((options) =>
{
options.UserInteraction = new UserInteractionOptions
{
LoginUrl = "/login",
LogoutUrl = "/api/Account/Logout",
ErrorUrl = "/error"
};
})
.AddSigningCredential(X509CertificateHelper.getCert(_env))
.AddOperationalStore(builder => builder.UseSqlServer(connectionString,
options => options.MigrationsAssembly(migrationsAssembly)))
.AddInMemoryIdentityResources(Config.GetIdentityResources())
.AddInMemoryApiResources(Config.GetApiResources())
.AddInMemoryClients(Config.GetClients(AppSettingsHelper.GetIdSrvrSettings()))
// .AddConfigurationStore(builder => builder.UseSqlServer(connectionString,
// options => options.MigrationsAssembly(migrationsAssembly)))
.AddAspNetIdentity<ApplicationUser>();
When running dotnet ef database update -c PersistedGrantDbContext
An error occurred while calling method 'ConfigureServices' on startup class 'Startup'. Consider using IDbContextFactory to override the initialization of the DbContext at design-time. Error: Cannot perform runtime binding on a null reference
Is it Possible to store Persisted Grants in the DB while leaving Resources/Clients in Memory
Yes. Those are all different extensibility points.
To be able to run dotnet ef database update -c PersistedGrantDbContext and seed the PersistedGrants table, I have to comment out:
// .AddInMemoryIdentityResources(Config.GetIdentityResources())
// .AddInMemoryApiResources(Config.GetApiResources())
// .AddInMemoryClients(Config.GetClients(AppSettingsHelper.GetIdSrvrSettings()))
and uncomment:
.AddConfigurationStore(builder => builder.UseSqlServer(connectionString,
options => options.MigrationsAssembly(migrationsAssembly)))
After running database update on the PersistedGrantDbContext successfully, I can then comment out the
.AddConfigurationStore.. and uncomment the .AddInMemoryIdentityResources/ApiResources/Clients and everything works seemingly as desired.
.NET Core, DI and the Factory Pattern are new to me. Assuming the above does not stand out as .AddConfigurationStore and .AddOperationalStore are dependent on each other, at the least for seeding the Db; I will focus on learning how to use IDbContextFactory and how EF7 MigrationsAssembly work.
Thanks..
For anyone else with same road block,
I ultimately solved this by implementing IPersistedGrantStore with help from the following like so:
services.AddIdentityServer((options) =>
{
options.UserInteraction = new UserInteractionOptions
{
LoginUrl = "/login",
LogoutUrl = "/api/Account/Logout",
ErrorUrl = "/error"
};
})
.AddSigningCredential(X509CertificateHelper.getCert(_env))
.AddOperationalStore(builder => builder.UseSqlServer(connectionString,
options => options.MigrationsAssembly(migrationsAssembly)))
.AddInMemoryIdentityResources(Config.GetIdentityResources())
.AddInMemoryApiResources(Config.GetApiResources())
.AddInMemoryClients(Config.GetClients(AppSettingsHelper.GetIdSrvrSettings()))
.AddAspNetIdentity<ApplicationUser>();
services.AddTransient<IPersistedGrantStore, PersistedGrantStore>();
And wiring up a PersistedGrantStore : IPersistedGrantStore
I am trying something similar but my code never gets to my persisted store class at all. What can I do to hit my breakpoint? What action will call these methods?
but my code never gets to my persisted store class at all
depends on the use cases if the store gets hit
Without more details, its hard to know how to help.
The following is what I learned that helped me today and quite possibly is no help to you. All the same.
dotnet ef ... the entry point of the program is not Program.Main. I was loading my appsettings.json file in Main, and only got the above mentioned error when running dotnet ef commands. To diagnose dotnet ef commands, append --verbose to them.
I was able to diagnose this with --verbose. My personal solution was to not assume Program.Main runs when running EF commands.
I learned this from here.
I was trying something similar to @ttugates where I was using in-memory clients and API resources. Once I deployed it to a load balanced environment to test I was getting errors. Those were, I am assuming, because of the jwki URI keys. So after reading up a little more, I realized I had to have a persisted grant stored. I am wrong to think that the persisted grant store will solve my issue?
So, I tried to implement the interface and store stuff in Redis instead of SQL Server but I could never hit any breakpoints in my code.
Once I deployed it to a load balanced environment to test I was getting errors
In a load balanced environment you will need to set a signing credential and use the same one across the 2 machines. Also, depending on the client flows, you will need to set a persisted grant store.
you will need to set a signing credential and use the same one across the 2 machines
You mean, set up a cert using AddSigningCredential right? Ran into a weird error when I tried this yesterday. It was not able to find the cert even when I could see it in the certificate manager.
Also, depending on the client flows, you will need to set a persisted grant store.
We are using only the implicit flow as of now - used entirely to authenticate human users and to support SSO.
We are using only the implicit flow as of now - used entirely to authenticate human users and to support SSO.
So no need for persistent grants, unless you are enabling consent.
Awesome! One last Q. Can I pass any cert (under Personnal) on a machine to AddSigningCredential? Is there any restriction if that cert needs to be a special kind? When I tried locally on my machine with a self signed cert from IIS it worked fine but in our testing environments I am trying to use domain issued certs which it does not seem to like.
If you can load it yourself, you can pass the x509 cert object. You might have DACL issues. That's been covered a ton elsewhere.
Good pointers for me to look into. Thank you!
@brockallen Noob question: Do you know if I can add a cert using a friendly name instead of a CN.
.AddSigningCredential("CN=MyCert")
@brockallen Which flows in a load balanced environment need a custom / persistent implementation of IPersistedGrantStore?
@brockallen Sorry, guess I missed that in the docs. Was just asking based upon your previous comment re: load balance environment.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
So no need for persistent grants, unless you are enabling consent.