I store user data in a MSSQL table called Users. What I want to is to have accessible all user's data for actually logged user (email, address, phone, if the user is subscriber etc.).
I don't want to use profiles so I decided to use custom MembershipProvider (or do you know some better, less painful way?).
What I don't understand is MembershipUser and Membership.
If I inherite from MembershipProvider, in overriden methods I control access data from and to database.
But how do I use inherited class from MembershipProvider?
If I want to authenticate user by using membership, I should do:
if(Membership.ValidateUser(string username, string password))
{
FormsAuthentication.RedirectFromLoginPage(string username, string password);
}
But where is class inherited from MembershipProvider? And when to use a class inherited from MembershipUser? And what is relation between Membership and MembershipProvider?
While it's not crystal clear on MSDN, it's not all that complicated. There's a trio of classes:
Membership: provides utility methods and a point of entry -- basically a Singleton (static class).
MembershipProvider: acts as a data accessor and factory for MembershipUser objects.
MembershipUser: represents an individual user.
A custom MembershipProvider is selected (by code in Membership) based on your application's configuration: configuration/system.web/membership. Here's where you bring your provider into play. Your MembershipProvider implementation must be written to access whatever data store you prefer for users: your User table in this case.
MembershipUser objects are only created through your MembershipProvider. The MembershipProvider.ValidateUser() method should check against your data store that the user/password combination is valid. The MembershipProvider.GetUser() retrieves user information -- use it within an access protected page and pass in System.Web.HttpContext.Current.User.Identity.Name as the current authenticated user.
This said, I hope you are sure you don't want to use Profiles, and really want to have a separate User table. If you are writing an internal application, using an existing Active Directory or LDAP-enabled data store would reduce administration costs and probably security risks. There are hundreds of things you can easily do wrong when going the MembershipProvider route. Do you use salted hashes? How are you protecting the User table against manipulation? MSDN covers only a fraction of the security issues you may face.
The specific provider used is controlled on the web.config. You can actually set more than 1 provider, and have a default one. Check: http://msdn.microsoft.com/en-us/library/6e9y4s5t.aspx.
When called like that, membership just uses the default provider. You would inherit MembershipUser, if you wanted to provide extra info for the user, but that will tie the rest of your code to your specific provider.
Related
I’m trying to understand why Vaughn Vernon (in the Github Sample code for the red book) includes tenantId in every repository get or find method. Particularly those that are doing a basic getById.
In one example he uses username to provide the identity of a User, and the business rule that usernames must be unique within a tenancy, so:
class UserRepository:
public User userWithUsername(TenantId aTenantId, String aUsername)
Makes perfect sense.
But in his other BCs he is using an identity value object based on a GUID, but still combines that with a tenantId when retrieving from a repository:
class ProductRepository:
public Product productOfId(TenantId aTenantId, ProductId aProductId)
Even the CQRS example, uses a combination of tenantId and entityId for its repositories single get method.
Its ubiquitous throughout, but I can’t understand why it would be necessary. If a product, backlog item, forum, calendar etc all have a globally unique identifier, why would you need anything more to query them?
If using this to ensure only entities for a particular tenant can be retrieved - this doesn’t seem to be a responsibility expected of a repository, but rather authentication etc, and so why include in every repositories query method?
Note, I understand why having tenantId as an attribute of the entity is required, and how it could be used to enforce some unique constraint. When retrieving a product however, wouldn’t productOfId(ProductId aProductId) suffice?
He does touch on this with “In the case of a multitenancy environment, the TenantId instance is also considered part of unique identity.” What value does combining two GUIDs to determine identity have over just the one?
I don't think this is specific to DDD, but to multitenancy. Regardless of how you design your application, you need to be able to tell if a record or entity belongs to a tenant or another. So, even if the IDs are globally unique, therefore don't need another ID part for deduplication, you still need the tenant Id.
On a more practical note, you can find the utility of the tenant Id on every entity if you need to provide a restful API on top of that data. Most likely, your API structure will look like the following:
api/{tenantId}/entity-type/{entityId}
You will have to validate that the user doing the request has access to the given 'tenantId' based, for example, on the claims in the authentication token. If the user has access, then you'll read from the database. But, if your repository only accepts 'entityId', then it will return that entity regardless of the tenant it belongs to and a user from tenant1 could get data from any other tenant only knowing the Id. You can, of course, add a check of the tenant id after loading the entity, but sooner or later you will forget to add it. If instead, you follow the practice of always adding the 'tenantId' to your repositories, then this check is built into the queries themselves, making the whole process more consistent and efficient.
On a side note, there are other ways to add a tenant Id check on all your queries, which will achieve the same goal without having to manually pass it to every repository method call and query implementation. For example, you could put the tenantId on a context and inject it using DI resolving your Repository. With SQL Server, you could use row-level security, so that the tenantId check is part of a table policy, instead of adding it to all the queries on that table.
This question is regarding authorization, not authentication which i will be managing with passportjs. How do i restrict access for data that's bound to specific users without spreading user_id's all over every table in the database?
Should i create a new database user for each new user of my app and restrict access that way? Or is the "user id in every table" approach actually a good way to go?
I'm working on a project right now where someone else wrote the authorization logic and it works using a kind of authorization path in the code so it can find which user a resource belongs to using some breadcrumb logic.
But I'm really at a loss here and I'm having a hard time finding any information regarding this since almost all articles that I find are about authentication rather than authorization. And I do not mean access to a resource, but rather the filtration of data returned from a resource that the user has access to.
If you want to restrict access of users to certain objects, you either have to store that information with the user or with the object.
The latter is the preferred way because it makes permissions disappear with the object. That's the way PostgreSQL does it – it stores an access control list (ACL) with every object.
So you can either use PostgreSQL to implement privileges (then every application user or at least every group with equal privileges has to have a database user, and you can use permissions on tables and columns and row level security), or you implement it in your application and have some sort of ACL with every row in the database.
I'm developing an app using Parse.com for BaaS. Aside from regular security checks, it's my understanding/philosophy that part of security is to assume someone HAS broken in, and then limit the amount they can access/delete/mess up.
One way I'd like to do this is to have a per-user rate limit on certain API requests. I can imagine a sort of naive method where I keep a list of who has accessed recently and when, and check that list before allowing a request of that type to go through (I'm thinking beforeSave for various custom classes).
Is there a better, ideally built-in way?
Though Parse.com doesn't have options for configuring this, parse claims that they keep track of suspicious activities and attempt for DDoS attacks are monitored. But not sure to what extend this is possible, because this specific problem is scenario wise relevant/irrelevant.
You dont have an option to do user level rate limit, but they will report any suspicious activities found like redundant hits from same device.
As given in the Parse docs here, They support two levels of permissions, Class level (via Data browser) & Object level (using ACLs)
Configuring class-level permissions
Parse lets you specify what operations are allowed per class. This
lets you restrict the ways in which clients can access or modify your
classes. To change these settings, go to the Data Browser, select a
class, open the "More" dropdown, and click the "Set permissions" item.
Class level permissions is a manual way of giving access to specific users or roles on a class.
In your case, you might probably need object level permissions based on Access Control Lists(ACL).
Access Control Lists
The idea behind an ACL is that each object has a list of users and roles along with what permissions that user or
role has. A user needs read permissions (or must belong to a role that
has read permissions) in order to retrieve an object's data, and a
user needs write permissions (or must belong to a role that has write
permissions) in order to update or delete that object
Create a new role and add list of users to that role who can access. Then set an ACL like this on the other objects.
{ "role:YourRoleName":{"read":true, "write" : true}}
You can now dynamically add or remove users in that role without updating individual objects.
i'm developing a Symfony2 app which involves users with hierarchical roles. Right now i can register, recover and login into the application without issues as i've implemented roles and users as described in Symfony2 docs.
At that point, i've developed some CRUD's in order to be able to manage objects in the application but in the current implementation i must check current user roles in order to let him or not run "selected" actions. I mean, in each controller i get security context, then user object and check permissions then sometimes i need to check the current user is the owner of the data - i.e if an user has clients i need to check url passed variables/id/whatever are owned/belongs the current user - and then deny access or not.
So, as far i'm used to and feeling comfortable developing the application as mentioned above i'm wondering is there is a better approach or a Symfony2 approach where i can manage roles and data in standard or more understanding way so future developers doesn't need to go through each if or check inside controllers+actions. I also would like to note i would be able to customize how data or objects are fetched or loaded so i can optimize sql's run in background.
Symfony ACLs is exactly what you need. You can assign access rights (i.e. OWNER, EDIT, VIEW etc) to a single user or assign to all users with a certain role (or both).
If ACL is too complex for your needs, than an alternative approach would be to use a custom Security Voter.
Is user profiles an appropriate place to store things like number of items per page in a custom grid user selected? (I you can store it in the view, but it won't be per user this way).
My first though was to store these settings in user profiles, but there are problems with access permissions for programmatically creating user profile properties boiling down to you either have to give every user 'Manager User Profiles' permission in SSP or you have to run the application pool under a domain user, not NETWORK SERVICE. Both scenarios are unrealistic for me, so I'm now looking for another way to store such 'per user' settings.
Thanks!
Edit: I'm now considering ASP.NET profile mechanism with an additional DB to store user properties.
Given that the information is not sensitive a simple database with values stored against AD login should suffice.
And as you have the ASP.Net user database already, storing the information there would be the best option.
Maybe a Global List, that is only accessible for the SHAREPOINT\SYSTEM User and that you can then Query in a SPSecurity.RunWithElevatedPrivileges Function.
Disadvantage: You require Custom code to read/write to that list.
Cookie?
Sure they have limitations, but it is fairly easy to create the control to run javascript to add/edit the value