Sincere thanks. We'll take a look and reopen if necessary. Best!
Ping ? :-) Thanks for any help on this.
Thanks, yes, this will save me some head-scratching time since I was still investigating code and documents to figure a way. So, correct me if I'm wrong: in the end, any Complex-Type that needs to be code-first (EF-Core) persistent must inherit from at compile time from the IEntity and be compiled into Abp to be "wired properly" for persistence. I'm still not sure why this is a do-or-die constraint, still ruminating on that!
Thanks,
Actually it is our own set of POCOs that are C# classes based on https://github.com/protobuf-net/protobuf-net These POCOs must be shared across several systems and, as such, cannot depend on Abp/EF through inheritance.
Best regards! Richard
@chris.tune Once you have a valid JWT, then you use it in your API calls to your server (Bearer). This is a big topic (lots of books and web sites doesn't make it simpler though), and is not ABP specific. In general your external (CORS) JS-client will need to use OpenID-Connect (via a JS-client-side-library or via another backend server) if it wants to send a valid, authentcated SSO JWT Bearer token to your server. Your server will then validate this token against the Identity Provider such as AAD B2C and cache it for a while.
If your JS-client is not external, i.e. it is same-origin, then you have served the page from your server where the user logged in: this is our scenario above. In this case, you could use the cookie for storage, or the JWT token in the Bearer Header. Both of them will contain all the claims that you (normally via AAD B2C) put in that signed, valid token. This JTW token can be read without a signature (see jwt.ms for example) anywhere, by anybody. It just can't be modified.
Hope that helps. More infos on stack exchange :-)
@chris.tune Yes, this is required by .NET-Core Identity. So if you don't want to modify the .NET sources, you had better use it :-) See above. However, it is not set by AAD B2C, that is the caveat I talk about above. In my code above, I define this claim and then set it to the user's email so that .NET does not reject the claim set. This will then be used as the AspNetZero username if I remember correctly, but that could be changed as well. The JWT(claimset) can be set in a cookie, you can check this in your browser's debugger, but cookie storage (the default I think) is only one option.
@konverto The return to the Login page is just the default behavior if the login fails. As such, this could be due to any number or a combination of small things. To get to the precise location of the problem, you'll need to put a breakpoint in the places above (see my codes above) and check what is happeing. On the AAD B2C-side, you'll also want to check a few things. Note that you can test your flows directly in the AAD B2C portal. Here are my thoughts:
In your code above: https://mytenant.b2clogin.com/mytenant.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=b2c_1_login"; Be sure to replace "mytenant" with YOUR b2c tenant name. Also be sure that you have the B2C flow "b2c_1_login" defined in the AAD B2C portal. You can test this there.
be sure your browser cache and cookies storage are blanko-clean when testing. If not, you'll get all kinds of strange effects when debugging. Your case above could be due to an auto-login (SSO) due to a cookie in your browser that is then providing old state and results in a rejection.
Be sure that your claim "email" is getting found in your code. Just put a breakpoint there and check the result...
B2C Reply-URL example. All checkboxes are "yes" except for Native Client is "No", no optional required. it is optional. The URLs.
Good luck!
Hi Chris, I have the feeling that your issue now lies in the claims that you are defining on the AAD B2C side: in my examples above, it looks for specific claims, e.g. email, and if it doesn't find the things it needs, then you will be redirected back to try again. You most certaintly do not have to use email as your username claim. You can use any claim if you change the line in my code to pull that one out. Do not rely on the default claims expected by .NET (see above) since these are not present in the AAD B2C claim set. You'll need to work through this with AAD B2C portal ... that takes a little time at the start to figure out initially. Note that Azure AD and Azure AAD B2C work differently. E.g. B2C does not yet have the GraphAPI, but it B2C is low-cost, AAD is not...
R
Hi,
using System; using System.Collections.Generic; using System.Linq; using System.Security.Claims; using System.Text; using System.Threading.Tasks; using Microsoft.Extensions.Configuration; using Microsoft.IdentityModel.Protocols.OpenIdConnect; using Abp.Extensions; using Microsoft.AspNetCore.Authentication; using Microsoft.AspNetCore.Authentication.OpenIdConnect; using Microsoft.AspNetCore.Builder; using Microsoft.Extensions.DependencyInjection; using Microsoft.IdentityModel.Tokens;
namespace ptw.de.AspNetZero.Web.Startup { public static class AuthConfigurer { public static void Configure(IServiceCollection services, IConfiguration configuration) { var authenticationBuilder = services.AddAuthentication();
if (bool.Parse(configuration["Authentication:OpenId:IsEnabled"]))
{
authenticationBuilder.AddOpenIdConnect(options =>
{
options.ClientId = configuration["Authentication:OpenId:ClientId"];
options.Authority = configuration["Authentication:OpenId:Authority"];
options.SignedOutRedirectUri = configuration["App:WebSiteRootAddress"] + "Account/Logout";
options.ResponseType = OpenIdConnectResponseType.IdToken;
//rht:
//options.RequireHttpsMetadata = false;
//rht:++
options.MetadataAddress =
"https://xxxxxx.b2clogin.com/xxxx.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_XXXSignInPolicy";
Hi, this in appsettings.json works (in conjunction with my post above):
"OpenId": { "IsEnabled": "true", "Authority": "https://yourtenant.b2clogin.com/yourtenant.onmicrosoft.com/oauth2/v2.0/authorize", "ClientId": "xxxe511-f4b2-47sa-a3d3-79dedb4xxxx", "ValidateAudience": false }