I am creating a web application that, simply put, allows for the users to create their own "sites" which have their own set of users. I look at the domain name of the request coming in to determine which "site" to display. I need to have completely different sets of users depending on which "site" you are on. For example: If I visit site1.example.com I am able to register as bob. Trying to login to site2.example.com with my credentials from site1 would fail, because I don't have an account there. Likewise, I should be able to create another, independent bob user on site2. Therefore, not only will I need to store additional information with the user (like what site they registered on), I also need to make the username field non-unique. Any ideas on how to accomplish this? I would like to use the built-in security provider in ASP.NET, so I can use things like [Authorize], but if some 3rd-party security suite would work, I am open to that as well.
With Asp.net membership provider ... one easy way is to change "role" s for each set of users. All users registered for site will get role "site1user" assigned. And so on. You can maintain all users in one database ... differentiated by roles.
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 am building an application using azure mobile services, where I have used azure authentication services for user authentication. Each user can store some of their information. I want to add more than one admin who can manipulate the information of all user when needed. I also want to provide admins a separate front-end. Is it possible to implement. If possible kindly provide me some resources.
Mobile Services on it's own doesn't have any concept of what an Admin is in your application. For that reason, you'd have to design the admin system yourself. You can do this in a few different ways including:
Create an Admin only app that the admin's use and send the Mobile Service Master Key over in the headers. This will make the user.level property return "Admin" while user's who are just authenticated to your app will have a user.level property of "Authenticated". You can use this in your server scripts to basically say "If admin, do THIS, otherwise if authenticated, do THAT".
You can create a Role table in your database and check if the user making the request is an admin for reach request. If so, you can then use similar server side logic above to perform specific logic for the admin vs the non-admin.
If you know the specific user IDs of people who will be admin's, you can just check against the user making the request in your server side logic (the advantage of this approach is that it doesn't require an admin only app or an additional check against the database to see what the user's role is).
Again, Mobile Services doesn't have a concept of an admin as far as your users go (only the sense that if the Master Key is sent in the request is "from an admin") so that's something you have to put in place yourself.
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.
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.