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.
Related
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
I am trying to figure out how to use .net core identity authentication with cookies and sessions. I want to be able to view currently logged in users/devices and revoke their sessions if necessary.
When doing services.ConfigureApplicationCookie() there is an option to specify a session store instead of keeping the user's login information/claims in a cookie. Can or should this session store be used for tracking users and logging them out? Or is this just supposed to be used for making the cookie size smaller?
I only need my session for authentication purposes (for a rest web api), I'm not sure if I need to separately use services.AddSession() and manually set session data when logging in and out - it seems the implementations I found for a RedisCacheTicketStore correctly add a cache entry on login and removes it on logout when I call signInManager.PasswordSignInAsync() and signInManager.SignOutAsync().
But I notice in those implementations the entry key is a randomly created GUID (similar to this implementation for a memory cache ticket store) - which means I would need to add something identifiable to the key like the user's ID to make it searchable or store that key again somewhere else?
I don't really want to use JWTs or IdentityServer / OpenID etc. if at all possible.
Here is my development environment:
Intranet Website
Active Directory Authentication/Authorization
Asp Net Core
I am trying to get the data stored in Active Directory attributes when a user enters firstly to any page in our application. All users rights and permissions, employeeid, studentid, etc.... are stored in AD Attributes and Security Groups. Some Attributes need to be displayed on the website too.
Let's say my website got the following urls...
http://mysite/Home/Index
http://mysite/Student/Index
http://mysite/Student/MyJobs
http://mysite/Staff/Applications
etc....
Any users can go onto some areas/urls of the website freely from other Intranet portals and I don't know where should I write the code to fulfill that criteria. The problem is that, there is no specific entry point to the application like http://mysite/Login or Authenticate, etc. If there is, I could load all users details and rights from AD on that single entry point.
In MVC5 era, I used Custom Global Authorize Attribute and put it on the BaseController is inherited from all other controllers to load that AD data. I put the AD's data into Session on the first hit and use the Static Class to display on Views and use in Controllers. But when I did some research in MVC Core, some say that it's outdated and I should use the Authorize Policy instead of custom Authorize Attributes.
Getting the data from Active Directory is already achieved by using my old webservices and we don't need to worry about .Net core not supporting AD yet.
I looked at the tutorials about Policy and saw something about Claims and Custom User Managers. I couldn't decide which one I should use to load data from Active Directory to the object (probably Scoped Object DI) which lasts for the whole user's session.
Should I load the data onto claims attributes
Eg...
var claims = new List<Claim>();
claims.Add(new Claim("UserName", "John.Smith", ClaimValueTypes.String, Issuer));
claims.Add(new Claim("RefNo", "02343001", ClaimValueTypes.String, Issuer));
claims.Add(new Claim("Email", "MyEmail#email.com", ClaimValueTypes.String, Issuer));
Or Should I write customized SignInManager and IdentityUser?
Eg...
public class ApplicationUser : IdentityUser
{
public string RefNo { get; set; }
public string Email { get; set; }
}
Is there anywhere I could put my code to check AD and load data?
And should I store the data in that Claimed Object rather than using Session Data?
Could you guys please advise me? Feel free to criticize if I miss anything and my idea is not working.
You're right in saying there's no System.DirectoryServices yet (it's on the backlog, I promise) so there are a couple of places to do this.
If you're already using Integrated Authentication you have SIDs for group membership, which are resolved when you call IsInRole(), so you can use role based membership (rather than Claims based) to solve basic authentication problems.
However if you want to support a forms based mechanism then you should look at using the cookie middleware, raw, to at least give you a simple login, calling your web service to validate your login. You could query your API in the controller code, and write an identity cookie. This cookie automatically encrypted and signed, so it can't be tampered with.
The problem comes when you want roles, and attributes. If you head down the cookie route you might be tempted to put all of those as claims in the identity before writing the identity out as a cookie. This might work, provided there are not too many - cookies have a maximum size (browser dependent, but under 4k usually). You can used chunked cookies, but there's a performance impact here. Instead you might use a reference cookie, where you put in a reference to another store where the actual fully populated identity is stored, be it session, redis or something else.
Then in the claims transformation middleware you can pull the reference out, go to your store, and rehydrate the identity.
I'd honestly avoid trying to merge all of this into ASP.NET Identity. That's mean to be the sole source for user information in an application, and in your case that's not true. Your sole source should be AD.
There's also a port of Novell's ldap library to core, which should stand in nicely for DirectoryServices should you want to avoid your web services approach.
I'm looking at the AspNetIdentity_2fa sample and trying to modify it to include some dynamic claims for users. Let's name it calculated_value claim which is created dynamically when a user is authenticated, and then is included in the user's claims list and passed with the the authentication token. I know I could create a separate Web API to get this value but since it is small data and that it is needed as soon as a user is authenticated, I thought I'd just pass it as claim. In the samples I see that claims always coming from static or hard-coded data. How can I create dynamic/late-bound claims?
Thanks!
Some time ago I spent some time on trying to integrate Identity Server v3 with Active Directory. I wanted to authenticate users via AD and to read "claims" from AD. To do so I provided a custom implementation of IUserService. It was more or less based on in memory implementation of these interface i.e. InMemoryUserService.
When your custom implementation is ready you have to register it. However, AspNetIdentity_2fa sample project already registers a custom implementation of IUserService i.e. UserService (just search a project for this class). It is derived from AspNetIdentityUserService which implements IUserService.
So, instead of providing completely new implementation try to modify it. I think that you should look at AuthenticateLocalAsync, AuthenticateExternalAsync and GetProfileDataAsync methods (see InMemoryUserService for reference) and override them. First 2 are used to authenticate users and the last one to read requested claims for users.
I am still pretty new to ASP.NET Web API. I am currently working on the authentication part of a new application based on Web API, which is developed using some libraries/kinda framework of the company.
There is already some MVC application - they are using forms based authentication and they are not using the IPrincipal to store information about the user, rather a unity based approach, keeping data in a custom IUser object (basically kept on the session).
The Web API application is going to be stateless (no session), just that I am going to add some user related information in the authentication cookie (retrieved per request in the Application_PostAuthenticateRequest).
I am a bit undecided to keep this user related data in a custom implementation of IPrincipal (as I noticed to be a practice) or use the current approach of other applications in the company utilizing an IUser - served by Unity, using a per request lifetime manager.
Which do you consider to be the better approach?
If you're keeping track of Users per session, try using Singleton classes, if you're about to make a log of the users that entered the session, write it down in a textfile like a whitelist.