Identity Core in .Net Framework

[OpenSpacesAndPlaces]

I have most of the nuts and bolts I need in place to get Identity Core working in a .Net Framework environment.

One thing I'm running into:
Microsoft.AspNetCore.Http.HttpContext

is used for:
public SignInManager(UserManager<TUser> userManager, IHttpContextAccessor contextAccessor, IUserClaimsPrincipalFactory<TUser> claimsFactory, IOptions<IdentityOptions> optionsAccessor, ILogger<SignInManager<TUser>> logger, IAuthenticationSchemeProvider schemes);

I would just do like:
new HttpContextAccessor() { HttpContext = ctx }

However, I only seem to have access to:
System.Web.HttpContext

"SignInManager" seems to be working, it just doesn't have an HttpContext I can give it so it can set authentication cookies.

I also tried something like:

HttpContextAccessor hca = new HttpContextAccessor() {HttpContext = new DefaultHttpContext()};
....SignInAsync...
hca.HttpContext.Response.Cookies...
hca.HttpContext.Identity...

But that did not work either (nothing was set).

---

Is there there a way I can workaround?

Any help would be appreciated!

[davidfowl]

What exactly are you trying to do? Use the new Identity in a System.Web application? Are you forking the sources and changing it to work or something else?

[OpenSpacesAndPlaces]

We have an old Web Forms application we are transferring over to .Net Core, but the process is slow.

In effort to ease the transition down the line, we're incrementally switching over key libraries in the Web Forms version of the application to their .Net Core equivalent. (so there is more code carry over)
e.g. We're using SignalR Core and EF Core (working great!).

We were still stuck on the old System.Web membership system and I've begun migrating that over too.
So far with Identity Core: EF Core integration is working. Web API integration is working. Account Lookups are working, Account Creation is working, JWT Token Generation is working. etc..
We haven't had to change any source code at all (so far).

My only pain point so far is being able to leverage cookie based security sessions that tie into context.
We still have controls that rely on server-side knowledge of Authentication state.

Ideally I'd like to avoid a "roll my own auth cookie" if that's possible,

[OpenSpacesAndPlaces]

To provide more detail - I'm constructing like this:

private static readonly IdentityOptions IDOptions = new IdentityOptions()
	{
		ClaimsIdentity = new ClaimsIdentityOptions()
		{
			
		},
		Lockout = new LockoutOptions()
		{
			DefaultLockoutTimeSpan = TimeSpan.FromMinutes(120),
			MaxFailedAccessAttempts = 10
		},
		Password = new PasswordOptions()
		{
			RequireDigit = false,
			RequiredLength = 1,
			RequireNonAlphanumeric = false,
			RequireUppercase = false,
			RequireLowercase = false
		},
		SignIn = new SignInOptions()
		{
			
		},
		Stores = new StoreOptions()
		{
			MaxLengthForKeys = 444,
			//ProtectPersonalData = true
		},
		Tokens = new TokenOptions()
		{
			
		},
		User = new UserOptions()
		{
			RequireUniqueEmail = true
		}
	};
	private static OptionsWrapper<IdentityOptions> IDOptionsWrapper = new OptionsWrapper<IdentityOptions>(IDOptions);

	private static readonly PasswordHasherOptions PWHasherOptions = new PasswordHasherOptions()
	{

	};
	private static readonly OptionsWrapper<PasswordHasherOptions> PWHasherOptionsWarapper = new OptionsWrapper<PasswordHasherOptions>(PWHasherOptions);
	private static readonly PasswordHasher<ApplicationUser> PWHasher = new PasswordHasher<ApplicationUser>(PWHasherOptionsWarapper);

	private static readonly List<IUserValidator<ApplicationUser>> lstUserValidators = new List<IUserValidator<ApplicationUser>>()
	{

	};

	private static readonly List<IPasswordValidator<ApplicationUser>> lstPasswordValidators = new List<IPasswordValidator<ApplicationUser>>()
	{

	};

	private static readonly UpperInvariantLookupNormalizer LookupNormalizer = new UpperInvariantLookupNormalizer();

	private static readonly IdentityErrorDescriber ErrorDescriber = new IdentityErrorDescriber();


	private static readonly List<IRoleValidator<IdentityRole>> lstRoleValidators = new List<IRoleValidator<IdentityRole>>();

	private static AuthenticationOptions AOptions = new AuthenticationOptions()
	{
		DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme,
		DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme,
		DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme,
		DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme,
		DefaultSignOutScheme = CookieAuthenticationDefaults.AuthenticationScheme,
		DefaultForbidScheme = CookieAuthenticationDefaults.AuthenticationScheme
	};
	private static OptionsWrapper<AuthenticationOptions> AOptionsWrapper = new OptionsWrapper<AuthenticationOptions>(AOptions);
	private static readonly AuthenticationSchemeProvider AutheticationScheme = new AuthenticationSchemeProvider(AOptionsWrapper);

	private static IServiceProvider spProvider = null;
	private static IServiceProvider GetUserServices()
	{
		if (spProvider == null)
		{
			IServiceCollection sc = new ServiceCollection();

			spProvider = sc.BuildServiceProvider();
		}

		return spProvider;
	}


	public static UserManager<ApplicationUser> GetUserManager()
	{
		return new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(ContextLoggerFactory.CreateContext<ApplicationDbContext>()), IDOptionsWrapper, PWHasher, lstUserValidators, lstPasswordValidators, LookupNormalizer, ErrorDescriber, GetUserServices(),new NullLogger<UserManager<ApplicationUser>>());
	}

	public static RoleManager<IdentityRole> GetRoleManager()
	{
		return new RoleManager<IdentityRole>(new RoleStore<IdentityRole>(ContextLoggerFactory.CreateContext<ApplicationDbContext>()), lstRoleValidators, LookupNormalizer, ErrorDescriber, new NullLogger<RoleManager<IdentityRole>>());
	}
public static SignInManager<ApplicationUser> GetSignInManager(HttpContext ctx = null)
	{
		UserManager<ApplicationUser> umCurUserManager = GetUserManager();
		HttpContextAccessor hca = new HttpContextAccessor() {HttpContext = new DefaultHttpContext()};
		return new SignInManager<ApplicationUser>(umCurUserManager, hca,
				new UserClaimsPrincipalFactory<ApplicationUser>(umCurUserManager, IDOptionsWrapper), IDOptionsWrapper,
				new NullLogger<SignInManager<ApplicationUser>>(), AutheticationScheme)
		};
	}

public static PasswordHasher<ApplicationUser> GetPasswordHasher()
{
     return PWHasher;
}

[OpenSpacesAndPlaces]

@davidfowl Does any of the extra details I've provided help?
To reiterate: JWT, Password, User Lookups, Account Creation - all fine.
Just stuck specifically on cookie auth using the built-in mechanisms.

[davidfowl]

You can’t really use the SignInManager in your System.Web application, somethings may not transfer well. I’m not 100% sure what approach you’re taking to port the app nor do I understand what you mean by JWT works. Are you using ASP.NET Core middleware somehow?

[OpenSpacesAndPlaces]

You can’t really use the SignInManager in your System.Web application, somethings may not transfer well.
I was hoping there was just a simple override or some ad hoc methods I could use that I was not seeing.

I’m not 100% sure what approach you’re taking to port the app
Nothing is being ported at the moment. We running a .Net Framework 4.7.1 site, replacing older libraries with .Net Core equivalents.
Eventually we'll move all the code over to .Net Core completely.

nor do I understand what you mean by JWT works.
I'm using JwtSecurityToken/JwtSecurityTokenHandler to create the token and then AuthorizeAttribute (Web API)/JwtSecurityTokenHandler to validate.

Are you using ASP.NET Core middleware somehow?
No middleware. Merely including the the appropriate packages - generally this has worked fine.
The only annoyances are around the lack of a Startup.cs, but mostly that translates to a few helper methods/singletons to fill the gap.

[davidfowl]

I was hoping there was just a simple override or some ad hoc methods I could use that I was not seeing.

Authentication works differently in ASP.NET Core. You may be able to hack enough to get it to work but I wouldn't call it progress.

Nothing is being ported at the moment. We running a .Net Framework 4.7.1 site, replacing older libraries with .Net Core equivalents.
Eventually we'll move all the code over to .Net Core completely.

Understood, I don't think it makes sense to use anything coupled to the ASP.NET Core HttpContext inside of a System.Web application. You can use the other pieces of identity that don't have that dependency (like the UserManager).

I'm using JwtSecurityToken/JwtSecurityTokenHandler to create the token and then AuthorizeAttribute (Web API)/JwtSecurityTokenHandler to validate.

That sounds like you're not using any of ASP.NET Core APIs. What am I missing?

No middleware. Merely including the the appropriate packages - generally this has worked fine.
The only annoyances are around the lack of a Startup.cs, but mostly that translates to a few helper methods/singletons to fill the gap.

Which ones are you using successfully and how are you using them?

[OpenSpacesAndPlaces]

Authentication works differently in ASP.NET Core. You may be able to hack enough to get it to work but I wouldn't call it progress. Understood, I don't think it makes sense to use anything coupled to the ASP.NET Core HttpContext inside of a System.Web application. You can use the other pieces of identity that don't have that dependency (like the UserManager).

More/less your recommendation would be to just roll my own authentication cookie then?

That sounds like you're not using any of ASP.NET Core APIs. What am I missing?
Claim/ClaimsPrincipal at generation and validation would be tying back to identity look-ups.

Which ones are you using successfully and how are you using them?
For things used over-top of Framework, as mentioned, we've used Entity Framework Core (SQL, SQLite, Cosmos) and SignalR Core for a couple dozen projects. (for over year). Those would be main ones. Otherwise it's just misc stuff here/there.

[davidfowl]

More/less your recommendation would be to just roll my own authentication cookie then?

Or keep using forms authentication in ASP.NET?

Claim/ClaimsPrincipal at generation and validation would be tying back to identity look-ups.

Those aren't ASP.NET Core specific APIs. I'm not understanding the flow.

For things used over-top of Framework, as mentioned, we've used Entity Framework Core (SQL, SQLite, Cosmos) and SignalR Core for a couple dozen projects. (for over year). Those would be main ones. Otherwise it's just misc stuff here/there.

Well to use ASP.NET Core SignalR, I'm assuming you're using it in an ASP.NET Core project yes?

[OpenSpacesAndPlaces]

Or keep using forms authentication in ASP.NET?

Unfortunately that doesn't meet the objective, because the idea is to "pre-migrate" the codebase.
So when the transition of the App to .Net Core happens, there isn't much work to switch/change/update.

Those aren't ASP.NET Core specific APIs. I'm not understanding the flow.

Correct - they can be use entirely independently, but in this case they are being fed/validated by Identity Core. You're just getting a username/claims, so unless it's a in-memory case, something has to backend the tokens. I'm not using it, but there are Identity extensions for that too (for a more built-in approach if you fully on .Net Core)
https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.dependencyinjection.jwtbearerextensions.addjwtbearer?view=aspnetcore-2.2

Well to use ASP.NET Core SignalR, I'm assuming you're using it in an ASP.NET Core project yes?

No - you can use ASP.NET Core SignalR right over top of Framework without any trouble. In our case we utilized it for distributed server to server communications.

[davidfowl]

These answers just raise more questions. How are you hosting SignalR in a System.Web application. I don’t understand your architecture enough to comment of the feasibility of a “pre migration”, the way you describe it today.

[OpenSpacesAndPlaces]

I'm going to go ahead and close this thread.
I think my original question has been sufficiently answered.
Thanks for wading through this.