Its a bit rich to complain about my very brief opening sentence and then write a small blog post on why I'm wrong and should go write my own identity server.
If you're going to push ABP to add a dependency on a commercial product costing thousands a year then you can expect pushback from those that have to pay for their own costs.
This has taken me some time to get right so I'm putting the solution here. Use this for either generating the keys identity server keys for production or integrating an old ASP Framework MVC project with the ABP identity server. There are other ways to store the cert rather than a file but this will work for linux too.
There are blog posts on this but they are wrong and will waste hours of your time. In particular do not include the "-certfile dev.crt" to the second openssl line as instructed by one post as it will generate an incompatable production cert.
openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout dev.key -out dev.crt -subj "/CN=dev.com" -days 3650
openssl pkcs12 -export -out dev.pfx -inkey dev.key -in shout.crt
For ABP Identity Server project.
public override void PreConfigureServices(ServiceConfigurationContext context)
{
var hostingEnvironment = context.Services.GetHostingEnvironment();
PreConfigure<AbpIdentityServerBuilderOptions>(options =>
{
options.AddDeveloperSigningCredential = false;
});
PreConfigure<IIdentityServerBuilder>(identityServerBuilder =>
{
X509Certificate2 x509;
// todo: passwords need to be moved to secrets storage or deployment system
if (hostingEnvironment.IsDevelopment())
{
x509 = new X509Certificate2(
File.ReadAllBytes(Path.Combine(hostingEnvironment.ContentRootPath, "dev.pfx")),
"cert-password");
}
else
{
x509 = new X509Certificate2(
File.ReadAllBytes(Path.Combine(hostingEnvironment.ContentRootPath, "production.pfx")),
"dontaddhere");
}
identityServerBuilder
.AddSigningCredential(x509)
.AddValidationKey(x509);
});
}
Legacy MVC Framework app. OwinConfig pipeline. For production put the password and possibly certificate somewhere outsite of the git repo.
var x509 = new X509Certificate2(File.ReadAllBytes(Path.Combine(HostingEnvironment.ApplicationPhysicalPath, "dev.pfx")), "cert-password");
var key = new X509SecurityKey(x509);
app.UseJwtBearerAuthentication(
new JwtBearerAuthenticationOptions
{
AuthenticationMode = AuthenticationMode.Active,
TokenValidationParameters = new TokenValidationParameters
{
ValidAudience = ConfigurationManager.AppSettings["JwtAudience"],
ValidIssuer = ConfigurationManager.AppSettings["JwtIssuer"],
IssuerSigningKey = key,
ValidateLifetime = true,
ValidateIssuerSigningKey = true
}
});
Only recently discovered this. Switching from free OS to multi-thousands per year is a real dick move IMO. I suspect they've created the new company simply to avoid possible legal action.
Is it not likely that V4 will simply get forked? For that matter could ABP not fork it and bundle with their own Admin UI since that's already part of the package? Seems like a golden opportunity if you could.
I've heard good things about Firebase Auth which is free or near free, or Azure AD B2C? Maybe some kind of adapter module?
Our ABP Angular tiered solution needs to integrate with an older .net framework MVC solution running separately.
This is the old Jwt code we use.
// from owinconfig.cs
public void ConfigureOpenAuth(IAppBuilder app)
{
//
app.UseJwtBearerAuthentication(
new JwtBearerAuthenticationOptions
{
AuthenticationMode = AuthenticationMode.Active,
TokenValidationParameters = new TokenValidationParameters()
{
ValidAudience = ConfigurationManager.AppSettings["JwtAudience"],
ValidIssuer = ConfigurationManager.AppSettings["JwtIssuer"],
IssuerSigningKey = ConfigurationManager.AppSettings["JwtSecurityKey"].ToSymmetricSecurityKey(),
ValidateLifetime = true,
ValidateIssuerSigningKey = true
}
});
}
//from JwtExtensions.cs
public static class SecurityExtensions
public static SigningCredentials ToIdentitySigningCredentials(this string jwtSecret)
{
var symmetricKey = jwtSecret.ToSymmetricSecurityKey();
var signingCredentials = new SigningCredentials(symmetricKey, SecurityAlgorithms.HmacSha256);
return signingCredentials;
}
public static SymmetricSecurityKey ToSymmetricSecurityKey(this string jwtSecret)
{
return new SymmetricSecurityKey(Encoding.UTF8.GetBytes(jwtSecret));
}
}
edit: ive figured i need to generate a new rsa cert somehow as its using developer mode which isnt recommended for prod.
from what ive been reading the identityserver4 jwt packages are now incompatible with .net framework.
are you share some example code for processing the Jwt token on .net framework. (currently 4.6.x but can update if needed?). im not interested in the user table stuff, just getting the claims. is there anything in the old abpboilerplate code that might work?
I saw your comment about having different App Services for each endpoint which conserned me slightly as we were planning to have just two containing all of the hosts and load balance between them. I did a quick check and it does seem you can put multiple hosts into one App Service plan.
https://docs.microsoft.com/en-us/azure/app-service/overview-hosting-plans#should-i-put-an-app-in-a-new-plan-or-an-existing-plan
Not much info about on Identity Service or deploying to Azure.
@armanozak Thanks, I'll pass that along to the dev.
@alper
Regarding the suite updating issue above. I'm not entirelly sure what caused it but I can tell you that they were modules not applications. There were two modules, the first updated fine, the second just kept reporting success even though it hadn't done anything. Cli worked ok.
Regarding the Anglar proxy issue, our dev said "It doesn't change the 'apiName' in the generated services. Even though it uses this parameter to generate them". He said it was a minor issue though.
Issue with hangfire after update from 4.0.2 to 4.1.0
My developer has posted details here also. https://github.com/abpframework/abp/issues/7147
Multiple errors in the 4.1 suite still.
Looking at your roadmap I think you could do with a period of feature freeze to get things working properly before attempting new features. As far as developing a billing and invoicing system is concerned, you would be absolutely insaine to try and develop something so complex which has to be entirelly bug free since it's dealing with peoples taxes. You can't do a "basic version" as it either compliant or not. That means EU/UK VAT proof of supply regulations, VEIS verification, US sale tax calculations or Taxjar plugins, API sync to accounting software.
Please, slow down!
Bug: Documentation search (top bar) doesn't return any results for anything.