We are doing a slow rollout of pages. basically the Login page is in ASP.NET and the old pages are in ASP Classic which are placed in an Iframe below the menu. They have two different servers that process the menu/pages. What is the best way to pass the users session from .NET to ASP Classic.
I had thought maybe it would be possible to modify the .NET login to send the user credentials to ASP page at the same time when they post their login. Is there any issues with this or is there a cleaner way of doing this?
Your ASP.NET code can read all the cookies in the domain, including the classic ASP session cookie, even though it doesn't use it. You can take advantage of that.
Handle signon on the ASP.NET side. The framework should create both an ASP and an ASP.NET session for you, passively, in addition to whatever other cookies are created by your authentication process.
Write ASP.NET code that reads the classic ASP session cookie and creates a JointSession record in the database indicating which user is currently signed on. Store both the ASP session cookie value and the current ASP.NET session ID (each in their own column), along with the user ID, roles, and whatever else needs to be shared between the two sites.
Write ASP code that reads its own session cookie and looks up any corresponding JointSession database record. If one is found, the ASP side of the site can infer that a user has signed on to ASP.NET, and can create its own matching session, initializing it from the fields in the JointSession record.
If you need to pass data between ASP and ASP.NET, add columns to JointSession, or perhaps use EAV schema. If it were me, I'd just add a VarChar column and throw some JSON in there.
Related
I'm using IdentityServer 4 but I think this question applies to ASP.Net identity in general.
We are considering to adapt an external (WinForms) tool to automatically delete (and later also create and manage) users. This tool has direct access to the IdentityServer database.
Is it as simple as deleting the record in the AspNetUsers table (and any additional records in profile/preferences/settings/roles tables) or is it more involved? Would we have to cycle the IdentityServer application pool as well?
In addition, if the user is logged in and actively busy on the Identity Server website, will the cookies be invalid as soon as the user tries to load a page with the [Authorize] attribute (after the record is deleted)?
We'll also have to notify all sites that make use of the tokens coming from the IdentityServer, but it looks like there is an existing solution for that (Backchannel Logout) which looks quite clumsy at first glance... It looks like a request is sent to the client to clear the cookies... I hope I'm seriously misunderstanding something here...
So in a .Net web forms project, I would simply use session variables to be able to set and get them across different pages. What is the proper way to do that in Blazor Web Assembly (with core hosting) ? i.e a user logs in, things like their ID, email, first name, etc are stored and then needed to be accessed in other pages.
in a .Net web forms project, I would simply use session variables
Your Wasm app is a regular C# app so you can use most normal storage mechanisms. I would stay away from static but you can use your own SessionStateService. Just a bunch of properties. Inject it as a singleton or use it as a Cascading value.
But ye old Session data was stored server-side. That means there is a subtle difference with Blazor wasm solutions as soon as the user opens a second tab with the same app. Every tab runs its own instance of the app so your data will be local to that tab. There is no sharing.
When you do want to share between tabs, use JavaScripts localstorage (persisted) or create an endpoint on your API server (persistance is up to you).
things like their ID, email, first name
Those should preferably be stored as claims in a JWT. Especially when you want to base some (serverside) authorization or logic on those values.
You use a Scoped DI service to maintain state, and inject it into any components that need to use or add/update the information.
See Ms Docs - https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/dependency-injection?view=aspnetcore-6.0
I'm using IdentityServer4 and EF Core in my Blazor WASM project with ASP.NET Core hosted option and in that project I use multiple databases.(dynamic string connection - duplicates of databases)
In the login page you choose what database to use and I store the database name in the cookies.
The system should work like that when you login using one database you can't use the other databases.
Every thing is working fine except that that I can change the database name in the cookies and then use the other databases.
My question is how can I modify the IdentityServer4 authroize so when you login using one database you can't access the another databases(return 403 error code when send http request if you changed database name in cookies) - database depended.
I thought maybe I could check each request if token is stored in AspNetUserTokens table ,but I noticed that the table is empty even after logged in successfully.
It sounds like the current database value should be set as a Claim on the user's identity, rather than in a raw cookie. Adding custom claims to the identity will protect them in an encrypted token.
Here's some documentation around this scenario, in particular look at implementing an IProfileService that adds your claim.
I am new to working with Blazor and Authorization. Background is desktop apps in Vb.Net, so I have been reading everything I can on it, but it still is very confusing when I only want a specific subset of the options out there.
I have a very simple intranet Razor Server based app that is getting the windows user name correctly with default authentication. (I use the name in calls to stored procedures for logging, so I know that is working correctly.)
What I need is to implement authorization (role based would be fine) based on information I have already in the database tied to the user name).
Where and how does one add roles to an existing authstatetask or other object instantiated by the default processes?
Everything I have seen deals with the EF version of Identity or wants to override the authorization task.
I have Simple DB calls being made in Dapper which will return an identifier from which I can set roles.
I just need pointers to the proper method and where in the app I should put it. I have just a single .razor page being loaded, Navbar is disabled.
You can either :
Implement Identity stores for Dapper following instruction in this blog : ASP.NET CORE IDENTITY WITHOUT ENTITY FRAMEWORK
Use Policy-based authorization and create authorization handlers meeting your requirements
In our current system (.net 4.5) to handle user authentication throughout the app we have created our own IIdentity and IPrincipal objects. So on every request we decrypt an attribute in the cookie (stored at login) and using this we check the cache for the user object (which also provides us with the client object). If the user is in the cache, great we then set the HttpContextBase.User and the Thread.CurrentPrincipal to be our own version of IPrincipal. If the user isn't in the cache then we get them from the db and set the above.
This works really well as we then have a BaseController with 2 properties, one for the current user and one for the current client. These are accessed by casting User.Identity to our own IIdentity.
We are now looking to move our app over to .netcore but we are not sure how to achieve the same as above given that we don't seem to be able to replicate it. We are currently using cookie middleware with ASP Identity (Shown Here), we are setting some claims (id, name etc) but we aren't sure how to or where we should be checking the cache and setting some properties on every request.