I am using a stateless design for a MVC5 Web API 2, ASP.NET application.
User roles are created by administrators by selecting permissions.
Each user in the application is assigned a custom user role, one role may be shared amongst users.
Razor views are structured based on the permission in the users role.
MVC and API controllers are available depending on the permissions in the users role.
For each request to the server, the users permissions need to be processed.
I can think of 2 ways to do this:
Store the id of the users role in the Role claim and perform a database lookup to retrieve the permissions for each page-load/request.
At the user login, retrieve all the permissions assigned to the users role, serialise them as JSON and store them in the Authentication claim. Then at each page-load/request, de-serialise the JSON back into objects and process the permissions.
Which of these would be the better option?
Option 1 is a lot slower than option 2.
Is there a security risk of storing the permissions in the cookie?
Is there a better or alternative solution which is quick and secure.
Storing permissions and other sensible data inside a cookie is always a very bad idea as it's quite easy to manipulate them. Trusting cookies requires an additional server-side check which defeats the purpose of storing it inside a cookie.
You're way better off only trusting the data that is under your control, aka the data in your database(s).
Depending on your application it might be useful to lazily evaluate permissions only when you really need to access them if the performance hit is too big. Keep in mind that you can make use of things like Redis to improve performance dramatically.
So again, depending on your application I'd probably go for option 1 as it's the more secure way.
Related
I wanted to try this code/solution to my ASP.net (VScode 1.69.1) but I am not sure where is the "Global.asax". Anyone know how I can apply the code below to asp.net core?
https://teknohippy.net/2008/08/21/stopping-aspnet-concurrent-logins/
I would not advise you to use that code, it wasn't even good advice back in 2015, but we can explore the concept and it's flaws which might help you come to a better overall solution.
This post will provide some context to the issue: Single Instance Login Implementation but is not a direct duplicate. The original source article does actually go into better detail about the general issues with this approach: http://www.nullskull.com/articles/20030418.asp
Using an In-Memory cache is not a viable option for production as multiple instances of the application would not share the same cache, especially if the application is hosted across multiple servers or serverless infrastructure that is configured to scale out beyond a single instance.
If all you want to do is block new logins, if the user is already logged in, then a server-based or cache concept itself is the right solution, conceptually to enforce a single instance across different browser sessions and across multiple servers will require that there is a server-side cache or store that holds the source of truth for all active connections. This could be in the form of a database or a distributed cache like REDIS.
But this is not a practical model for how users actually use their browsers and devices. Instead of blocking new logins, it is more practical from a user point of view to expire or force close the existing logins. The problem with only blocking new logins is that if the user doesn't have access to the original browser session that holds the login, then there is no way to log out the previous session, you would have to wait for it to timeout. The challenge with being able to expire a login session is that your clients and the server code must be designed to round-trip to the session store to validate the session token. Most default JWT or even cookie implementations do not do this, they will rely on the expiry or validity information in the token itself, and bypass consulting the store.
Instead of the article you have found, please try these resources:
ASP.NET Core security topics
Can I force a logout or expiration of a JWT token?
JSON Web Tokens (JWT) are Dangerous for User Sessions—Here’s a Solution
I have an ASPNET CORE 2.0 website that is published to a web server farm. I am using Identity Role/User claims for authorization. I have a large number of claims associated with the logged in user, which is bloating the size of the application cookie. I see a few techniques for dealing with this situation, but am unsure what path to take.
Using a custom ClaimsTransformer: create a custom DB store outside of the Identity Role/User claims tables and load the claims on TransformAsync. I'm not sure if there is a better solution that doesn't involve a DB call every round trip to the server.
Specify a Distributed Cache Session Store when specifying the ApplicationCookie. I'm not sure if this will resolve the bloated cookie issue.
Using a sticky Session to store user claims. I don't think that this works with claims authorization ([Authorize])
How do I use Claims Based Identity across multiple web servers when the user has a large number of claims?
Cookie size is basically the strongest argument against "everything as a claim," and it's unfortunate because that model works pretty well, otherwise (I've been in your shoes). Just as you suspect, the best approach is to restrict your claims to the bare minimum and use the identity (subject id) to retrieve more detailed app-specific information from a database as needed.
If database response-time is a concern, you're basically back to stateful session data. Microsoft would likely guide you towards Redis in-memory caching. Not sure if that's an option on Amazon, I use Azure.
I tried the ClaimsTransformer routine, but it became a larger hassle constantly addressing "is this really a claim or just something we're treating as a claim?" versus just separating persistence/retrieval of real IDP claims versus internal application-level user data.
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'm re-writing a website from the ground up for azure. Each user has ownership of a number of objects, and has a number of permissions. Together, these determine what they are authorized to do. The question is, how should this information be stored. I want to do the authentication myself, using custom logic.
For performance reasons, I'd like to cache these authorization lists for each user once they're logged in. Can someone give me a sample for how to store & access this session information securely and efficiently.
Edit
I looked into the App Fabric Access Control, but that seemed overkill as I was going to have to create a separate site for authentication, which doesn't seem to make sense. Would the claims based authentication make sense separately though? How would you do that if it does?
Would it make more sense to just keep the username in a cookie in the traditional way and then re-query table storage with each request to get the permissions etc.? How would storing the username work in Azure?
Cost is a big factor here as it's a very small site (by azure standards) but I want high performance for a small number of users.
If you want to run with a reasonable amount of availability you need to run your site with two instances. If you're running with two instances you need to use a session provider that's no the default InProc one. Your choices are:
AppFabric Caching (which you don't want to use because it's too expensive, fair enough)
Azure Storage Session Provider. Don't use this. It's an interesting experiment, but it's only sample code, it's slow and doesn't cope well in production.
SQL Server session provider.
If the permissions for a user weren't going to change while they were logged in, you could just store their permissions in session. This will probably be fast enough. However this information will need to be read from SQL for each request that uses session and it is overhead.
If you wanted to make things faster you could just store the user ID in session and load the permissions into a static dictionary (keyed on user ID) when needed. These items will need to be expired after a certain amount of time or lack of use.
Well, you could use the Azure App Fabric cache to store the session info. ASP.Net can be configured to use it as the backing store for its session state as like a normal custom session state provider.
This article from MSDN shows you how to configure it:
http://msdn.microsoft.com/en-us/library/windowsazure/gg278339.aspx
From your code you just use the normal ASP.Net way to get/set the state.
Be aware though - it could be expensive ($45/month for 128MB of cache).
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.