I have a web app and I can login as admin or customer in it. Admin has access to all pages, customer has access to certain pages only.
When customer logs in, the required pages, say 3 pages are shown, after he logs out and the admin loges in, still only those 3 pages are shown. Although, After manual refresh, I'm able to see all the required admin pages.
How do I refresh automatically when user logs out? I'm using Angular 10 framework.
Since you're question is pretty generic, it is hard to get into specifics.
You must have some login code, so presumably you are loading a users permissions from some system and storing those permissions as part of the app--presumably as a cookie?
You can protect routes using auth guards. We primarily use canActivate guards.
You can hide elements on a page--such as screen navigation links--with an *ngIf. We created our own structural directive to accept in a list of allowed user permissions, and the current user's permissions and use that to determine if certain dom elements should be created or not.
I'm not sure about C#, but in Java we created a Spring Annotation to validate user permissions when a user tries to access a REST Endpoint. I suspect something similar must exist in the .NET world.
Conceptually it is not much different than our Angular custom structural directive; comparing allowed permissions to perform the action with user permissions, and then either allowing or denying the action.
It sounds like your users are getting elevated permissions by reloading the app; so I suspect there are some underlying security issues with your full implementation, but without a code review cannot begin to speculate what that is.
Related
I'm creating a website using ASP.NET core with MVC where a few people will have accounts to manage a database. Since anonymous users will be able to view the website, I don't want them to be allowed to create accounts and mess stuff up. I'm not sure if adding the [Authorize(policy)] attribute to the create account page is possible since the ASP.NET core template hides the page that I need to add it too. Is there a way I could do it? Now that I'm thinking about it, does individual authentication even allow you to do such a thing?
Before you say this is a duplicate question, I've looked through previous answers only to find that they just add [Authorize] to the create account page, which I said I'm fairly certain I can't do. Unless there is something I missed, of course.
Take a step back and think about what you are saying. You want to enforce authorization on anonymous users. Does that make sense to you? How can you authorize someone you don't know?
If you don't want anyone to be able to create accounts, your action simply cannot be exposed to anonymous users. You should remove the code generated by the template or at the very least, hide it behind an authorization scheme like the other answers have suggested.
That leaves you with the problem of how to create a user when the page to create a user cannot be accessed. I've dealt with this in a couple of ways in the past:
Create a user with admin rights programmatically (if it doesn't already exist) on application start. This user is authorized to access a page within the app (usually an admin panel on a separate Area) where he/she can create other users. You use this account to grant access to other accounts and assign proper roles as needed. OR,
Have the application check for initialization on start up and if it hasn't done it before, show a workflow that allows you to create an admin account (kind of like a first time installation step). Once created, you use it the same way as in option 1.
In both cases, you will be applying the Authorize attribute to your controllers and/or actions as desired and will need an "admin" facility where users with proper rights can manage things.
We have an application (C# on the server, using AngularJS / Web Apis for a single page application) that assigns users different roles, which are stored in the database. When the user logs in, the user object (including RoleID's and RoleName) is transformed into a JWT and sent to the user, which is then used as authentication.
We're having trouble determining the best way to maintain and use these access roles however. Specifically, to use them in the current set up, it would seem that we have to hard code either the name of the role or the ID into the application.
For example, on the client side, if we want only users with a Manager role to be able to see and click a button, we would have to explicitly state that, ie if (UserService.HasRole('Manager')) { doStuff(); }.
Conversely, we'd have to do the same thing on the server side (because everyone knows relying on client-side security is bad). When the server gets a request on the API, it checks the JWT for validity and, if valid, checks the User's roll to see if they are allowed access to the specific web API endpoint.
This all seems prone to breaking if a role is renamed, or the ID changes. I generally hate hardcoding things like this. Is there a better methodology or approach that can be taken here?
In the past, when we've done RBAC (Role Based Access Control), we decouple the Role from the Permission e.g.
Role Permission
===============================
Manager Create Order
Manager Delete Order
Till Operative Create Order
Administrator Create User
Administrator Suspend User
etc.
This could be stored in a database and cached in something like Redis. Two tables, Role and Permission, where the Permissions need to match the ones built into the application (you could script this).
So your permissions grow with your application e.g. you add a new dining service, you can add a "seat diners" permission. The permissions for existing/mature bits of the software should rarely change (unless they were written incorrectly), whereas the roles are entirely fluid and can be renamed etc.
You can then use an annotation/security framework to ensure that the user making each API call on the server side has the correct role required.
You can even make it additive and allow a user to occupy multiple roles at once to blend things together.
You may maintain your user to role mapping in the database also in another table (using FK constraints) or you may use something like LDAP with the mapping being looked up from the DB/cache.
On the server side, Microsoft has built in management for roles. I would first look at
http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity
And then I'd also look at the the IdentityServer project for working with JSON Tokens on the server side.
https://brockallen.com/2013/04/14/getting-json-web-tokens-jwts-from-adfs-via-thinktecture-identityservers-adfs-integration/
On the client, I would suggest storing the tokens as either just in memory javascript or if you want them to persist, I would store them as cookies but make sure to set the cookies to not be accessible by JavaScript by using the httponly parameter when creating the cookie.
HTH's
I have a web application which is largely a content system - that is, it displays help for another system. It doesn't matter who views it. However, there is a list of users I would like to display, and also provide a way to edit the list. On that one page I want to detect the user's Active Directory information, and if the user is in the list of users authorized to change the data, then display an edit icon button to provide a means of editing some element. I do not need nor want Windows Authentication determining whether the user can get to the page, only to discobver the user's logon creds.
In short, I want this:
// Get the user's creds
// Is user a page editor?
if (IsPageEditor(UserCreds))
{
// put icon buttons for editing
}
else
{
// don't put icon button there
}
First of course is, getting the user credentials. I should add that this will all be on a private company intranet, and every user will be signed into the network.
I do not need nor want Windows Authentication determining whether the user can get to the page, only to discobver the user's logon creds.
Why not? Windows Authentication is the obvious, secure way to discover the Windows identity of the connected user.
Any other mechanism is insecure, i.e. a user who is not authorized to edit could spoof an authorized user's identity. Using Windows Authentication doesn't preclude you from allowing any user to access the application.
My understanding of setting Windows.Authentication ON is that it will challenge the user to give user name and password before allowing to view the page
No, this isn't correct. If the server is in the same domain as the client, and the server is configured to allow all domain users to connect, there doesn't need to be a prompt to the end user.
Our trouble ticket system "knows" who we are when we access the page -- it must be getting this information from Active Directory, from the current logged in user.
Probably it is using Windows authentication. Try examining the HTTP flow between the browser and your trouble ticket system with a tool such as Fiddler: you'll probably see an authentication challenge/response.
To get the current logged in user you need to call WindowsIdentity.GetCurrent();
From there you can do a lot of things depending on your requirement, get users groups, get OU information etc. For a full AD wrapper I have a full article here
http://macaalay.com/2010/06/28/active-directory-c/
The Problem
I'm an ASP.NET newb who has been given the task of creating a multi-user password management system for use within a secure intranet. Essentially the user will be automatically logged in via windows authentication, which will then provide them with an appropriate view depending on their group. For example, a user of group 'admin' would be able to access all password entries, and a user of group developers would be able to access all password entries belonging to users in the 'Developers' active directory group. Users should be able to create, update, and hide (delete) password entries.
What I have so far
So far I have essentially been figuring out what will and will not be impossible, and researching technologies. Windows authentication itself appears to be easy, however it breaks when I enable the role provider, which appears to be necessary for providing different views for users. By 'breaks' I mean specific users are still recognized, but entire groups are not.
The different views must be automatically served, and I have come up with two techniques to do this:
Checking the role (group) on the home controller, and serving the appropriate view. This would require a long list of messy 'if' statements, however.
Serve a common view and allow or disallow viewing certain elements according to group. This would require putting a lot of logic in a view, which is as I understand inappropriate.
There will be a password.cs model class which will hold all information on a password entry including which groups should have access to it. I cant really think of any other necessary models, as the user information would not need to be stored.
Security concerns
I understand that storing such sensitive data in a single location could be a recipe for disaster. Passwords will be appropriately encrypted using pre-exising libraries which I have access too. I will have help with this area. Also, passwords will not be view-able as plain text on the system to avoid shoulder-surfing, but will be displayed as asterisks and will be copy-able to the users clipboard.
My questions
Essentially I would like some advice on how to structure the system and the most simple ways to enable active directory authorization with windows authentication. I would like some advice on how to provide the appropriate view for the user, and how the different areas should fit together. I am not expressly asking for any help with the password security side of things, but any insight or discussion would be warmly welcomed. Essentially, I would very much appreciate any help, links to tutorials, or suggested readings.
My tools
At my disposal I have Visual studio professional 2010, MVC 4.0 and .NET framework 4.0, and standard (non-admin) access to the server.
I will be able to give experimental code which I currently have in place tomorrow (It's 22:30 GMT, I'll be back in the office tomorrow morning). Let me know if you need any more information.
I have implemented two solutions where I had to integrate MVC with Active X Directory. There are multiple solutions (e.g. Security Application Block from Enterprise Library). However, I ended up using AzMan and the RoleManagerAzManProvider. I ended up with this combination because I did not need to deploy any additional libraries.
I started with this article: [http://msdn.microsoft.com/en-us/library/ff649313.aspx][1]
Even though it is written for ASP.NET, I was able to use it for MVC. I placed my XML Local Policy Store underneath app_data and configured the web config
<add name="LocalPolicyStore" connectionString="msxml://~/app_data/MyPolicyStore.xml" />
This worked out nicely for me because the Policy Store allowed me to define Application Roles and, when deployed at my client, map those roles to AD Accounts.
After that, I implemented a custom Authorize Attribute that I registered in the Global filters. This is where I made the decision which page the user would be redirected when they logged into the app. Finally, I used the standard Authorize Attribute on controllers based on group names.
I have thought about writing a set of Custom Editor Templates and Display Templates that would take roles into account so that I can render different UI for controls based on the User's application role (render a span instead of input).
Although your application is probably already written, I hope this helps.
Chuck
I want to implement roles and permissions on a web app we have created and I am looking at using System.Web.Security.SqlRoleProvider to implement this.
My problem is that each client will want to be able to configure who can and cannot perform actions in the system and no two clients will want the same, so creating basic
Admin, User, Manager roles to cover all won't suffice.
What I am proposing to do for each screen is create roles as follows
Screen1Create, Screen1Update, Screen1Delete, Screen1Read
Screen2Create, Screen2Update, Screen2Delete, Screen2Read
and so on.
I would then allow the client to select the roles per user, which would be stored in a cookie when the user logs in.
I could then read the cookie and use user.isinrole to check if each method can be called by the current user.
I realise there is a size constraint with cookies that I need to be aware of. Apart form that, does this sound feasable, is there as better way to do it?
Many thanks for any input.
Really if you want to program this all yourself to the cookie level you're risking opening security holes. The way to do this is with forms authentication combined with role based authorization. Asp.net will give the user a tamperproof cookie.
If you implement roles you can then easily mark methods:
[PrincipalPermission(SecurityAction.Demand, Role="Screen1Create")]
or use code to see if someone is in a particular role.
Lots of info:
http://weblogs.asp.net/scottgu/archive/2006/02/24/ASP.NET-2.0-Membership_2C00_-Roles_2C00_-Forms-Authentication_2C00_-and-Security-Resources-.aspx
Remember that cookies are user-supplied inputs, so if you're going to store the privileges of users in cookies, you must use a keyed hash function (such as HMAC-SHA256) to make sure that users do not grant themselves additional permissions.
Or, if you store all the permissions in your database, it'll be persistent across client computers and you won't need to validate its integrity every time you wish to use it.