I am new to ASP.NET and I am working on ASP.NET Web Site Application in which i have some Internal (OR Domain specific) Roles. Like, BoardOfDirectors, Managers, Secretary belonging to Employee class and ShareHolder another Role, another one as Company Administrator/Creator/Owner etc. All these Roles are internal (OR domain/business model) specific Roles which delimit the business functions a specific Role/Actor can perform.
One of my colleagues told me to do R&D on ASP.NET Forms-Based Authenticatoin, Authorization and MEmbership class etc. With this i initally got an idea that probably ASP.NET provides a ready-made Role Management Module that can be customized to any domain specific needs (just as we see in ready-made CMS Systems)
But, After some googling, i reallized that Form-Based Authentication limits the Roles on use of Web Resources specificlaly Pages. This leads me to idea that Internal (OR Domain Specific) Role Management is not related to ASP.NET Form-Based Authentication. Instead Form-Based Authentication (as it restricts access to pages in website) can be used to manage External Roles of the website like Web Site Adminsitrator (Having a different website folder/file structure which should be accessed merely by a Role specified in database like Site Admin or so. Similarly, Form-Based Authentication can be used to discriminate between a Site Member and Free User/Visitor.
For my internal/Domain specific Roles, I really do not see any reason to create multiple pages in different Role-Based folders with duplicate OR overlapping functionality like A Company Creator will be able to do business functions that manager can do, so i would not like to create two separate folders/files; one for Company Creator and other for Manager with Manager page duplicating some of functionality from Company Creator. I feel that it would be appropriate to handle Domain Roles using Business Logic (in my Domain Model Layer).
I need your suggestion if i am wrong in my understanding/assumption, OR if i am missing something?
Regards
Do not mix up Authentication and Authorization.
Authentication in your case is going to be done by using Forms-based Authentication, and Authorization is going to be based on User Roles.
Authentication would ensure that the system recognizes the User. Authorization would ensure that whether or not that user is allowed to perform certain actions or functionality.
Related
I'm developing a Single Page Application using ReactJS + .Net Core 5 which has several fine-grained authorization checks.
So, in my application there are users, roles and userroles to link these two information. Then, I have a Permissions table and RolesPermissions to link the permissions (or actions) for each roles. But this diagram cannot work correctly because some roles are tailored on resources (so, I can be Editor on resource A and Reader of resource B, where A and B are the same type of resource). To summarize, some roles are directly linked to resource.
How can I manage the authorization in this case? I read on Resource-Based authorization (https://learn.microsoft.com/en-us/aspnet/core/security/authorization/resourcebased?view=aspnetcore-2.1&tabs=aspnetcore2x#operational-requirements), but in this case the permissions design on database side would be useless and I have to write a lot of C# code to manage each possibilities (a lot of if/else). I'm looking for some alternatives... also because, after correctly managed the permisssions on backend side, I need to pass information to frontend in order to segregate the layout (for example, the button "Create" must not be displayed if you are only reader on a specific resource).
I am developing an application which consists of two types of admission, one for employees of the company that must manage administrative elements and the other should be for users who need to make a purchase in the company, what solution should implement for the kind of access? because access of administrative employees is done, thanks.
PD: Users should not see the menus administrative staff.
Have different roles for each user type. Also have two different master page, one for administration one for users. All your administration related modules must use administration master page (this will have all administration related menus) and general user module must use user master page. After login according to their role type redirect to respective action methods.
Are you using the same authentication layer for both types of users? If so, implement Role Based Access Control (RBAC) -- here's a link to a relevant MSDN article.
If you're not using the same authentication system, then the admin interface should be a separate application than the user system; consider implementing both as "microservices" that share some portion of a persistence layer. Or have the admin app act through an API on the primary application.
In my Windows Store App (c#) I have own authorization mechanism:
User past their account name / password and sent it to server.
Server generate unique token and returns it to user.
For all next requests user used this token.
Now I'm in trying to make authorization with using only Windows Account.
MSDN provide UserInformation class and I can get name for the user account or domain name for the user. But I thing this is not enough for my authorization scheme.
Also method GetSessionInitiationProtocolUriAsync looks very interesting, but I don't know how correct use such Uri for authorization.
How I can use Windows Account for authorization in my application?
note: I'm interested in both situation: when user inside domain or not.
Thanks.
There is numerous was to implement this but if you want to keep it simple and own the process you could implement your own authentication method which on a successful authentication you could build a hash value from their password and secret salt which could be returned to the user as a cookie etc. which you use to validate on every request there after.
On regards to authorisation you can implement your own or use a role based provider linked to the local machine group or active directory by using the classes below or just using the plain old RoleProviders.
You could implement your own method of authentication using the method described below or using the Authentication and Authorisation provider for ASP.Net (if your server runs on .net). Basically the Asp.Net Membership and role Providers. However the method detailed below will allow you to access and modify roles and other information about the user too.
In .Net 3.5+ there is a new namespace called System.DirectoryServices.AccountManagement.
Snippet from MSDN
The System.DirectoryServices.AccountManagement namespace provides
uniform access and manipulation of user, computer, and group security
principals across the multiple principal stores: Active Directory
Domain Services (AD DS), Active Directory Lightweight Directory
Services (AD LDS), and Machine SAM (MSAM).
System.DirectoryServices.AccountManagement manages directory objects
independent of the System.DirectoryServices namespace. Managed
directory services applications can take advantage of the
AccountManagement API to simplify management of user, computer and
group principals. Solutions that previously required intricate
knowledge of the store or lengthy code, such as finding all groups to
which a user belongs, are accomplished in a few lines of code with the
AccountManagement API.
You can easily authenticate a user credential on AD using the code below:
bool valid = false;
using (PrincipalContext context = new PrincipalContext(ContextType.Domain))
{
valid = context.ValidateCredentials( username, password );
}
If you want to validate using a local machine account you can change the constructor too:
new PrincipalContext(ContextType.Machine)
You can check the documentation for other options and additionally this will let you get all sort of information from the store like membership etc.
The new namespace was Microsoft attempt to simplify DirectoryServices which I think was successful but if you want even more control you could use the DirectoryServices classes but that would increase the complexity of the solution.
I hope this helps if you require further information or you think it is not quite what you are looking for let me know I will endeavour to improve the answer.
First, I'm afraid you're confusing authentication and authorization.
Authentication - proving a user's identity (like me presenting an ID when going to the bank)
Authorization - deciding whether an identity is allowed to perform some action (like whether the client "Nitz" can drain account #44422).
A Microsoft account can only provide you with authentication - the client will use some scheme to prove to your server that it belongs to bla#microsoft.com, and it's up to you to decide if it is allowed to do stuff in your application (authorization).
With domain accounts, you can use domain group membership to help with your authorization (it's even common in windows server applications), which you usually get "for free" with the user's authentication token.
Assuming I understood you correctly and you're indeed looking for authentication, you have to provide two behaviors - one for using domain authentication and one for Microsoft account authentication. This is because libraries and communication protocols are very different between the two.
Providing authentication
Using this this tutorial from Microsoft Azure's guys, you can set up a sample application / website combination that utilizes Microsoft account authentication.
To use domain authentication (kerberos / NTLM), you can follow this post and simply enable "integrated windows authentication" in your web site/service (I'm assuming it's IIS). If you're new to enteprise authentication, I'll shortly say that when set up properly (no time differences, AD issues etc.), the authentication is seamless. If there are issues, fall back to a simple "hello world" website and test it from Internet Explorer.
For each scenario, you best create a "hello world" method returning the user's authentication information, to make sure you got it right.
Providing authorization
with each authentication method you end up with a unique ID (Microsoft account: UserId. Domain accounts: SID). Your logic should translate this info to a set of permissions - e.g. Maintaining a table that has the ID in one column, and isAdmin in another. Your application should consult this logic when deciding whether to allow or deny an action from a client.
Combining enterprise and public
Since the methods to authenticate public users are different from the ones used for enterprise users, you'll probably end up with different IDs for the same user when connected from different methods (e.g. DOMAIN\bla and bla.blason#outlook.com). If you intend to provide both authentication methods at the same time, you have to account for that (for example, by creating a "user" table that has one column for Microsoft account IDs, and one for Domain SIDs). It usually makes little sense to provide both authentication methods at the same time, but it's your app.
Hope I helped!
Once i had the similar situation, (A client app need to connect to server with few identity credentials. after the custom authentication , a token will be grant for the client with few claims, then each client request will be validated against the given token) , if you are in something like this, consider this link, it helped me to solve the issue.
http://bitoftech.net/2014/06/09/angularjs-token-authentication-using-asp-net-web-api-2-owin-asp-net-identity/
Note: you can implement custom authentication, and authorization by extending claimsAuthenticationManager and Claimsauthorizationmanager respectively
I am developing an MVC3 application and I have gotten to the point where I need to start securing out different areas of the intranet site to particular users.
The site is being used on the intranet and uses windows authentication for login.
Within the database I have a users table which contains numerous fields that determines the users role. This is maintained in the admin area of the site.
Certain users will have the ability to access the admin area, some users will only have the ability to read certain areas of the site but not contribute, etc etc. There are some complicated business rules.
I am looking for how to secure out different areas. I have read a good few articles around using the authorize attribute on controllers for particular groups, this doesn't seem to be a good fit as I understand it I would have to control what users are in what groups from within the configuration of the application whereas the admin users of the application should be ones controlling this via the application itself.
Any suggestions are welcome.
If you are mainly concerned about managing users, ASP.NET does a great job of this with their built-in Web Application Administration Tool. On the top-right of the Solution Explorer, to the right of the refresh button, is a hammer-and -earth tool that you can click on. It allows you to manage users and roles, and from there you can assign the users to roles. Perhaps your admins can use this.
This tells you how:
http://www.asp.net/mvc/tutorials/mvc-music-store/mvc-music-store-part-7
As far as having to put authorize attributes on the controllers/methods, I don't see any way around that. Let me know if I have misunderstood your question.
Assign users to roles and use AuthorizeAttribute.
We are building an intranet application that would use integrated windows authentication. The application would require custom actions and roles to secure different parts and functions.
My current idea is to extend active directory by storing the roles and actions in a different database linked to an active directory user using the SID. That way we know who the user is and fetch his allowed roles (with the actions) from our database without much hassle.
Do you think this is a good approach or are there better ways of dealing with these things?
I have read this post: User Group and Role Management in .NET with Active Directory
But Active Directory does not support programmatically creating roles and there is no support for custom actions whatsoever.
A couple of options spring to mind:
you could use ADAM (aka AD LDS) for your roles store - the programming model is the same as AD, which is nice;
you could us AzMan (aka Authorization Manager) - it integrates nicely with ASP.NET and you can use it with the builtin Roles provider. It can store its data in XML or in the AD. Also, the EntLib comes with an AzMan wrapper so you've another way to use it. I quite like AzMan because you can make changes to user roles on the fly.