Changing RouteData in Asp.Net Core 3.1 in Middleware - asp.net-core-3.1

I've recently updated my .Net Core 2.1 application to 3.1 and there is one part that has not upgraded as expected.
I'd written code to map subdomains to areas as described here
I now realise that the method of using app.UseMvc() should be replaced with app.UseEndpoints() but I can't find anywhere in the 3.1 framework that will allow me to write to the RouteData before app.UseEndpoints()
//update RouteData before this
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
"admin", "{area:exists}/{controller=Home}/{action=Index}/{id?}");
endpoints.MapControllerRoute(
"default", "{controller=Home}/{action=Index}/{id?}");
});
Is there a way to write to RouteData using Middleware?
I've tried going back to app.UseMvc() as it's still in the framework but MvcRouteHandler doesn't seem to exist anymore
app.UseMvc(routes =>
{
routes.DefaultHandler = new MvcRouteHandler(); //The type of namespace could not be found
routes.MapRoute(
"admin",
"{area:exists}/{controller=Home}/{action=Index}/{id?}");
routes.MapRoute(
"default",
"{controller=Home}/{action=Index}/{id?}");
});

Try to use custom middleware.
Add a reference to using Microsoft.AspNetCore.Routing and use Httpcontext.GetRouteData() method to achieve RouteData
app.UseRouting();
app.Use(async (context, next) =>
{
string url = context.Request.Headers["HOST"];
var splittedUrl = url.Split('.');
if (splittedUrl != null && (splittedUrl.Length > 0 && splittedUrl[0] == "admin"))
{
context.GetRouteData().Values.Add("area", "Admin");
}
// Call the next delegate/middleware in the pipeline
await next();
});
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
"admin", "{area:exists}/{controller=Home}/{action=Index}/{id?}");
endpoints.MapControllerRoute(
"default", "{controller=Home}/{action=Index}/{id?}");
});

Related

How do you modify the client and api scopes that are predefined in IdentityServer 7 when creating a web app with individual accounts?

I have been stuck on this problem for a few days now. I have a web application being built on .NET Core 7, IdentityServer 7, EntityFramework 7, and Angular 15 and written in C#. The scope in the JWT contains a scope of (MyAppAPI, openid, and profile). I am trying to find a way to add roles to the scope. I've tried several approaches, but all of them are directed towards creating new IdentityResources, Clients, and ApiScopes. This approach throws errors because they already exist from IdentityServer 7.
Hoping someone can help. Thanks.
My latest effort consisted of applying option arguments to the builder.Services.AddIdentityServer().AddApiAuthorization<ApplicationUser, ApplicationDbContext>() method in the Program.cs file. But I get an error saying "Can't determine the type for the client type". So I don't know if I'm close to getting this all resolved or am way off track.
Here are the contents of my Program.cs file:
using Duende.IdentityServer.AspNetIdentity;
using Duende.IdentityServer.EntityFramework.Entities;
using Duende.IdentityServer.Models;
using AdminPortal.Areas.Identity.Data;
using AdminPortal.Areas.Identity.Models;
using AdminPortal.Framework;
using Microsoft.AspNetCore.ApiAuthorization.IdentityServer;
using Microsoft.AspNetCore.Authentication;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Logging.AzureAppServices;
using System.IdentityModel.Tokens.Jwt;
using System.Security.Claims;
var builder = WebApplication.CreateBuilder(args);
string envName = string.IsNullOrEmpty(builder.Configuration["configEnvName"]) ? "development" : builder.Configuration["configEnvName"].ToString();
builder.Configuration.AddJsonFile("appsettings.json").AddJsonFile($"appsettings.{envName}.json");
builder.Logging.AddAzureWebAppDiagnostics();
builder.Services.Configure<AzureFileLoggerOptions>(options =>
{
options.FileName = "AdminPortal-diagnostics-";
options.FileSizeLimit = 50 * 1024;
options.RetainedFileCountLimit = 5;
});
builder.Services.Configure<AzureBlobLoggerOptions>(options =>
{
options.BlobName = "log.txt";
});
// Add services to the container.
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();
builder.Services.AddDefaultIdentity<ApplicationUser>(options => options.SignIn.RequireConfirmedAccount = true)
.AddRoles<ApplicationRole>()
.AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddIdentityServer()
.AddApiAuthorization<ApplicationUser, ApplicationDbContext>(options =>
{
options.IdentityResources = Config.IdentityResources;
options.Clients = Config.Clients;
options.ApiScopes = Config.ApiScopes;
})
.AddProfileService<ProfileService>();
builder.Services.AddAuthentication()
.AddIdentityServerJwt();
builder.Services.AddControllersWithViews();
builder.Services.AddRazorPages();
//builder.Services.AddScoped<IClaimsTransformation, ClaimsTransformer>();
var app = builder.Build();
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
app.UseMigrationsEndPoint();
}
else
{
// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseIdentityServer();
app.UseAuthorization();
app.MapControllerRoute(
name: "default",
pattern: "{controller}/{action=Index}/{id?}");
app.MapRazorPages();
app.MapFallbackToFile("index.html"); ;
app.Run();
And here are the contents of Config.cs:
using Duende.IdentityServer.Models;
using Microsoft.AspNetCore.ApiAuthorization.IdentityServer;
using System.Collections.Generic;
namespace AdminPortal.Framework
{
public static class Config
{
public static IdentityResourceCollection IdentityResources =>
new IdentityResourceCollection(
new IdentityResource[]
{
new IdentityResources.OpenId(),
new IdentityResources.Profile(),
//new IdentityResources.Email(), // Can implement later if needed
//new IdentityResources.Phone(), // Can implement later if needed
//new IdentityResources.Address(), // Can implement later if needed
new IdentityResource("roles", "User roles", new List<string> { "role" })
});
public static ApiScopeCollection ApiScopes =>
new ApiScopeCollection(
new ApiScope[]
{
new ApiScope("AdminPortalAPI"),
new ApiScope("openid"),
new ApiScope("profile"),
new ApiScope("roles")
}
);
public static ClientCollection Clients =>
new ClientCollection(
new Client[]
{
new Client
{
ClientId = "AdminPortalAPI",
ClientName = "AdminPortal Credentials Client",
AllowedGrantTypes = GrantTypes.ClientCredentials,
AccessTokenType = AccessTokenType.Jwt,
ClientSecrets = { new Secret("AdminPortal_client_secret".Sha256()) },
AllowedScopes =
{
"AdminPortalAPI"
}
},
new Client
{
ClientId = "AdminPortal",
ClientName = "AdminPortal SPA",
AllowedGrantTypes = GrantTypes.Code,
AccessTokenType = AccessTokenType.Jwt,
RequirePkce = true,
RequireClientSecret = false,
AllowedScopes = { "openid", "profile", "AdminPortalAPI", "roles" },
RedirectUris = { https://localhost:44463/auth-callback },
PostLogoutRedirectUris = { https://localhost:44463/ },
AllowedCorsOrigins = { https://localhost:44463 },
AllowOfflineAccess = true
}
}
);
}
}
I found the solution to my problem. So I'll report it here for anyone else that finds themselves struggling with this issue or similar.
If you create a new project in Visual Studio and tell it to include Individual Accounts, it will use IdentityServer to build out an authentication framework that will make it easy to manage user accounts and authenticate users. However, if you want to implement role-based security, you'll have to build it out manually because the preconfigured code only partially implements IdentityServer and is not designed to let you customize the scopes (reference link: https://github.com/dotnet/aspnetcore/issues/16939).
To resolve this issue, I found a great tutorial that helped me build out the authentication and authorization framework using IdentityServer for my Angular 15 .NET Core 7 web application. Here is the link to it: https://code-maze.com/angular-security-with-asp-net-core-identity/

Mocking authentication when testing MSAL React Apps

Our app is wrapped in the MSAL Authentication Template from #azure/msal-react in a standard way - key code segments are summarized below.
We would like to test app's individual components using react testing library (or something similar). Of course, when a React component such as SampleComponentUnderTest is to be properly rendered by a test as is shown in the simple test below, it must be wrapped in an MSAL component as well.
Is there a proper way to mock the MSAL authentication process for such purposes? Anyway to wrap a component under test in MSAL and directly provide test user's credentials to this component under test? Any references to useful documentation, blog posts, video, etc. to point us in the right direction would be greatly appreciated.
A Simple test
test('first test', () => {
const { getByText } = render(<SampleComponentUnderTest />);
const someText = getByText('A line of text');
expect(someText).toBeInTheDocument();
});
Config
export const msalConfig: Configuration = {
auth: {
clientId: `${process.env.REACT_APP_CLIENT_ID}`,
authority: `https://login.microsoftonline.com/${process.env.REACT_APP_TENANT_ID}`,
redirectUri:
process.env.NODE_ENV === 'development'
? 'http://localhost:3000/'
: process.env.REACT_APP_DEPLOY_URL,
},
cache: {
cacheLocation: 'sessionStorage',
storeAuthStateInCookie: false,
},
system: {
loggerOptions: {
loggerCallback: (level, message, containsPii) => {
if (containsPii) {
return;
}
switch (level) {
case LogLevel.Error:
console.error(message);
return;
case LogLevel.Info:
console.info(message);
return;
case LogLevel.Verbose:
console.debug(message);
return;
case LogLevel.Warning:
console.warn(message);
return;
default:
console.error(message);
}
},
},
},
};
Main app component
const msalInstance = new PublicClientApplication(msalConfig);
<MsalProvider instance={msalInstance}>
{!isAuthenticated && <UnauthenticatedHomePage />}
{isAuthenticated && <Protected />}
</MsalProvider>
Unauthenticated component
const signInClickHandler = (instance: IPublicClientApplication) => {
instance.loginRedirect(loginRequest).catch((e) => {
console.log(e);
});
};
<UnauthenticatedTemplate>
<Button onClick={() => signInClickHandler(instance)}>Sign in</Button>
</UnauthenticatedTemplate>
Protected component
<MsalAuthenticationTemplate
interactionType={InteractionType.Redirect}
errorComponent={ErrorComponent}
loadingComponent={LoadingComponent}
>
<SampleComponentUnderTest />
</MsalAuthenticationTemplate>
I had the same issue as you regarding component's test under msal-react.
It took me a couple of days to figure out how to implement a correct auth mock.
That's why I've created a package you will find here, that encapsulates all the boilerplate code : https://github.com/Mimetis/msal-react-tester
Basically, you can do multiple scenaris (user is already logged, user is not logged, user must log in etc ...) in a couple of lines, without having to configure anything and of course without having to reach Azure AD in any cases:
describe('Home page', () => {
let msalTester: MsalReactTester;
beforeEach(() => {
// new instance of msal tester for each test
msalTester = new MsalReactTester();
// spy all required msal things
msalTester.spyMsal();
});
afterEach(() => {
msalTester.resetSpyMsal();
});
test('Home page render correctly when user is logged in', async () => {
msalTester.isLogged();
render(
<MsalProvider instance={msalTester.client}>
<MemoryRouter>
<Layout>
<HomePage />
</Layout>
</MemoryRouter>
</MsalProvider>,
);
await msalTester.waitForRedirect();
let allLoggedInButtons = await screen.findAllByRole('button', { name: `${msalTester.activeAccount.name}` });
expect(allLoggedInButtons).toHaveLength(2);
});
test('Home page render correctly when user logs in using redirect', async () => {
msalTester.isNotLogged();
render(
<MsalProvider instance={msalTester.client}>
<MemoryRouter>
<Layout>
<HomePage />
</Layout>
</MemoryRouter>
</MsalProvider>,
);
await msalTester.waitForRedirect();
let signin = screen.getByRole('button', { name: 'Sign In - Redirect' });
userEvent.click(signin);
await msalTester.waitForLogin();
let allLoggedInButtons = await screen.findAllByRole('button', { name: `${msalTester.activeAccount.name}` });
expect(allLoggedInButtons).toHaveLength(2);
});
I am also curious about this, but from a slightly different perspective. I am trying to avoid littering the code base with components directly from msal in case we want to swap out identity providers at some point. The primary way to do this is to use a hook as an abstraction layer such as exposing isAuthenticated through that hook rather than the msal component library itself.
The useAuth hook would use the MSAL package directly. For the wrapper component however, I think we have to just create a separate component that either returns the MsalProvider OR a mocked auth provider of your choice. Since MsalProvider uses useContext beneath the hood I don't think you need to wrap it in another context provider.
Hope these ideas help while you are thinking through ways to do this. Know this isn't a direct answer to your question.

SSO with openiddict

When a user logs in from site https://www.siteA.com,
an authentication cookie is recorded.
I want to read this authentication cookie from site https://www.siteB.com using User.Identity.Name.
How should I configure Program.cs(ASP.NET CORE 6.0) of Site https://www.siteA.com and Site https://www.siteB.com ?
using AuthorizationServer.Models;
using Microsoft.AspNetCore.Authentication.Cookies;
using Microsoft.EntityFrameworkCore;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContext<DbContext>(options =>
{
options.UseInMemoryDatabase(nameof(DbContext));
options.UseOpenIddict();
});
builder.Services.AddOpenIddict()
.AddCore(options =>
{
options.UseEntityFrameworkCore()
.UseDbContext<DbContext>();
})
.AddServer(options =>
{
options
.AllowClientCredentialsFlow();
options
.SetTokenEndpointUris("/connect/token");
options
.AddEphemeralEncryptionKey()
.AddEphemeralSigningKey();
options.RegisterScopes("api");
options
.UseAspNetCore()
.EnableTokenEndpointPassthrough();
});
builder.Services.AddHostedService<TestData>();
builder.Services.AddControllersWithViews();
builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, options =>
{
options.LoginPath = "/account/login";
});
var app = builder.Build();
if (app.Environment.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseEndpoints(endpoints =>
{
endpoints.MapDefaultControllerRoute();
});
app.Run();
you can use ASP.Net Core Data Protection Keys configuring in your client Applications (i.e SiteA and SiteB).
Have a look at this.
https://github.com/openiddict/openiddict-core/issues/1109
and this
https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-3.1
hope this helps

ASP.NET Core Authorize Redirection to wrong URL

I am trying to run a web application with the following route mapped:
app.UseMvc(routes =>
{
routes.MapRoute(
"default",
"WoL/{controller=Account}/{action=Login}/{id?}");
});
If the user is not authenticated and tries to access a action having the AuthorizeAttribute, the user should be redirected to the default login URL (as seen above). But the user gets redirected to "/Account/Login" instead of "/WoL/Account/Login". How can I redirect the user to "/WoL/Account/Login", if the user is not authenticated? I have configured the following Cookie Authentication:
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
LoginPath = new PathString("/WoL/Account/Login"),
AutomaticChallenge = true
});
The answer of #Dmitry is not working anymore in ASP.NET Core 3.1. Based on the documentation that you can find here, you have to add the following code to the ConfigureServices:
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Latest)
.AddRazorPagesOptions(options =>
{
options.Conventions.AuthorizeAreaFolder("Identity", "/Account/Manage");
options.Conventions.AuthorizeAreaPage("Identity", "/Account/Logout");
});
services.ConfigureApplicationCookie(options =>
{
options.LoginPath = $"/Identity/Account/Login";
options.LogoutPath = $"/Identity/Account/Logout";
options.AccessDeniedPath = $"/Identity/Account/AccessDenied";
});
This works for me (in Startup.ConfigureServices):
services.AddIdentity<User, UserRole>(options =>
{
options.Cookies.ApplicationCookie.LoginPath = new PathString("/Admin/Account/Login");
});
Try to add options.ForwardChallenge = "oidc"; to AddCookie options config

Sails.JS + sails-auth + passport-openidconnect

I'm trying to implement passport-openidconnect into my Sails app. I've installed sails-auth, passport, passport-local, passport-http, and passport-openidconnect, all of which are required to start the sails app. I copied the contents of this file to get a passport config since the sails app was already started when I began implementing. This is my config file so far:
module.exports.passport = {
openid_connect: {
name: 'OpenID Connect',
protocol: 'oauth2',
strategy: require('passport-openidconnect').OAuth2Strategy,
options: {
clientID: '',
clientSecret: ''
}
}
};
I based this off some of the default options that were in the config/passport.js file mentioned above.
I've searched for setup examples for the OpenID Connect, but haven't been able to find anything so far. Has anyone implemented this in their own project and could give me some pointers? Thanks!
I've implemented passport in sails, with passport-local, passport for Google/FB/Twitter, but without sails-auth !
I don't know passport-openID but this should be nearly the same.
First you need to add passport middleware like this in your config/http.js
Then you have to create the different strategy in config/passport.js (exemple with FacebookStrategy, it should
var passport = require('passport')
, LocalStrategy = require('passport-local').Strategy
, FacebookStrategy = require('passport-facebook').Strategy
var verifyExtHandler = function (token, tokenSecret, profile, done) {
checkAuthExt(profile, done);
};
var verifyHandler = function (mail, password, done) {
checkAuth(mail, password, done);
};
// Passport session setup.
// To support persistent login sessions, Passport needs to be able to
// serialize users into and deserialize users out of the session. Typically,
// this will be as simple as storing the user ID when serializing, and finding
// the user by ID when deserializing.
passport.serializeUser(function (user, done) {
user.password = null;
done(null, user);
});
passport.deserializeUser(function (user, done) {
done(null, user);
});
// Use the LocalStrategy within Passport.
// Strategies in passport require a `verify` function, which accept
// credentials (in this case, a username and password), and invoke a callback
// with a user object.
passport.use(new LocalStrategy({
usernameField: 'mail',
passwordField: 'password'
}, verifyHandler));
// Remplacer les 'XXXXX' par vos clés et 'yourhost.com' par votre nom de domaine
passport.use(new FacebookStrategy({
clientID: "XXXXXX",
clientSecret: "XXXXXX",
callbackURL: "http://yourhost.com/auth/facebook"
}, verifyExtHandler));
And you need to configure your routes (config/routes.js) :
'/auth/facebook': 'AuthController.facebook',
'/auth/facebook/callback': 'AuthController.facebook'
Then in your controller :
facebook: function (req, res) {
passport.authenticate('facebook', {
failureRedirect: '/auth/login'
}, function (err, user) {
if (err) {
return console.log(err);
}
req.logIn(user, function (err) {
if (err) {
console.log(err);
res.serverError();
return;
}
return res.redirect('/');
});
})(req, res);
}
Hope that helps !