In my application I need to register users. The users can be any of three: admin, client and general. They have different attributes (Admin may have only name, client may have company address and so on). The default MVC membership scheme is okay but how can it be extended to register more information during registration time? Or should I use custom membership?
I need to have a record of clients and general users with clientID or generalID.
The default MVC membership scheme is okay but how can it be extended
to register more information during registration time? Or should I use
custom membership?
I think too many people, yourself included, are expecting to get too much from the default ASP.NET Membership Provider. It was never designed to handle application-specific things, like what company your customer works for, your admin's name, and so on. It's main purpose is storing passwords for authentication.
Sure, the password needs to be linked to a username, so that there can be a 2-key authentication pair. Sometimes you also need the user's email address, when it is different from their username, in order to contact the user regarding their password. But don't store anything else about your users in the membership store. Store it in your application database.
In order to join data between your application and the membership provider, use the membership provider's UserName or ProviderKey as a column in one of your database tables. You end up with 2 entities which are not explicitly related. You can even have your SqlMembershipProvider implemented in a separate database from your application database. Even if they are in the same database, avoid having a foreign key between any of the provider tables and your application tables. This muddies the waters between what you own, and what you "outsource" to the membership provider.
You end up with 2 physically isolated representations of your user. One is the MembershipProvider, which contains a password for your user. The other is your application, which contains other business-specific details. The two are only logically associated within your application. After you authenticate a user with the membership API, their UserName and/pr ProviderKey become available to your application. You can then use that piece of data to query your app database and get the additional details. This is where you might put something like the clientID or generalID you mentioned.
If you look at the System.Web.Security.Member* API, this should make things clearer. It does one thing really well -- associating your users with passwords and other information related to password resetting (like the email address, question and answer, etc). So outsource just the password provider, and rely on your application to do the important stuff.
You could customise the default profile provider or create your own... Follow this reference
http://msdn.microsoft.com/en-us/library/8zs47k7y
You can add new properties to the profile for anything in the web.config too
I highly suggest creating your own membership roles. It's dead simple and nothing can beat the flexibility of having your own implementation.
Here's a video I made a while back showing you step by step how to achieve this:
http://www.youtube.com/watch?v=BsxUsyMSGeA
The gist of it is, you create your own AuthorizeAttribute and create your own roles; protecting each controller or even individual Action methods along the way.
The one drawback of this approach is that you can determine what Role a user has in your system, but not what a Role can do in your system. Does that make sense?
There are other choices if you need to edit what a role can do at runtime.
Related
Is there any way to login other users account for admin user ?
Currently authentication based on Meteor Accounts
I saw this post but didn't working at all now.
The feature is important for us because when user have problem in system then admin need to see it this by simulating user account.
Thanks in advance.
It seems you want to impersonate a user. This means that you want to have Meteor.userId (or this.userId depending on context) reflect the _id of a specific user both on the client and the server.
afaict the only way to do this is to login as the user. Presumably you don't want to ask the user for their password so you have a couple of choices:
Save their existing password, replace it (temporarily) with a password of your choosing, then after you're done impersonating their account, restore their existing password.
You probably don't want to ask the user for their password and you don't need to. All you need to do is set aside Meteor.user.findOne(userId).services.password.bcrypt, then reset the password to your temporary value, then restore the original bcrypt value later.
The downside is that the original user would not be able to login while you are logged-in. Plus it's really hacky.
Extend Meteor's Accounts package to provide impersonation capability in a more elegant manner.
You might also look at validateLoginAttempt. The docs are unclear as to whether a failed login attempt could be overridden with a successful one but if it could then that would provide another pathway to solve your problem.
Instead of logging in as the users, which requires their password and which is a total no-no, you may use rather alanning:roles and allow the admin to assign the role of any user in order to draw views based the user's role.
This requires a well designed role system.
As a plus you could then at least load the documents associated with the user who you want to support.
This requires a well designed document and data model.
But generally spoken you should rather focus on writing good tests (test driven development) for components as unit tests, integration tests and UI tests.
This will reduce the need to manually view the app as an end user a lot.
The most common end user problems can be reduced by creating a good knowledge base like a wiki or video tutorials.
Even if then an error occurs in the end user side, I would rather try to implement a well designed error log that allows users automatically create tickets on error which also include the error stack.
All the above methods are to be favored before logging in AS THE USER.
As #Jankpunkt has already mentioned alanning-roles I can add something you can use without installing any external package.
Just keep a type key in the profile object of the users collection. Then define some types like 1 for super-admin, 2 for admin, 3 for general etc. Then check the authorisation of particular action by checking the value of user.profile.type key.
Caveats: Make sure you are checking the type in server side. By default profile field is writable from the client end, so if you are putting type field in the profile object make sure that you are not allowing users to modify users collection in the client end.
Here is how to restrict client end update in users collection:
Meteor.users.deny({
update() { return true; }
});
Read more on roles and permissions here:
https://guide.meteor.com/accounts.html#roles-and-permissions
I am using vaadin 7, and jboss 7.1.1. There is a business requirement for very granular ui access. There will be parent windows per business function, and in that window functions relative to it. Business requires enabling and disabling those functions within, per user, so as an example, a parent window that represents employees, and when you click that you enter the child window which has functions like editing, deleting, viewing, adding,etc etc but that access must be customized to the user using it, so user x can update but not delete, as an example.
So what i came up with was to store that information in the database. In the database there will be a users table with username and a user guid. Then a parentview table and and parentchildren table and then lastly a userview table. i will store in the userview table the users guid and either the view they have access to and what type of access as in read,write,update,etc... I will on the ui login authenticate against ldap, get the users information and guid and use the guid to pull the users view access from the userview table in the database and store it in the vaadin session, and then on the ui, read that from the session and show the correct access.
I am not sure if this is the best way which is why i am asking if my solution is ok? I have been reading lots of doc's around security but non seem to achieve what i want. Another point of keeping it in the db, is that i can create a user admin ui which can edit the users access simply by updating the db, i dont want to redeploy or do anything with the webserver, I would prefer a ui user access control module and for someone with rights to it to administer that access. I would really appreciate insight and some ideas into this.
Thanks guys, I would appreciate any input.
What you want to achieve, regardless of the environment you are in and technology you are using, is fine-grained access control / authorization.
The way to do that is to use authorization frameworks. Spring Security has one for instance. I'm not sure whether Vaadin comes with anything.
In our company we use Vaadin to develop a management portal and we then use XACML to apply fine-grained decisions to the portal such as which functions to enable for which users and even which items to display in a Vaadin table.
Generally speaking you want to look at the field of attribute-based access control (NIST ABAC). ABAC lets you define authorization constraints based on different factors/parameters such as user attributes (location, department, role...) and resource attributes (where the resource can be data, widgets, functions... You name it).
I actually delivered a webinar yesterday on the topic of fine-grained authorization for Java MVC apps. I think it could prove useful for you.
If you go down the XACML path, you do not need to create a custom database with the information inside as you have done. All you need to do is write authorization policies e.g. a user in purchasing can use the purchasing functions.
There are several open source XACML implementations as well as vendor solutions such as the one I work for, Axiomatics.
I hope this helps. I've also written a lengthier answer here which covers the broader field of authorization.
I am building a multi-tenant site with MVC3. Prior to this project I had never touched either the .NET stack or web development in general, so as you can imagine my domain knowledge is somewhat lacking.
I'm still using the default AccountController architecture, but I pretty quickly determined that I didn't want to use aspnetdb.mdf for authentication, as its design is pretty different from my requirements. I do want role-based authentication, so I ultimately wrote custom User and Role classes as code-first Entity classes and used this tutorial to set up a custom MembershipProvider and RoleProvider.
Everything works fine at the moment, but as I'm building the multi-tenancy functionality it's getting messier. Based on this example, I am using a custom extension of Controller which keeps track of which tenant is using this session, and all my controllers extend this class instead of the base Controller class.
All tenants are using the same database. Each entity has a Tenant property that identifies who it belongs to.
So, here's the problem:
Usernames do not need to be globally unique. Only the combination of username and tenant must be unique. Thus, ValidateUser needs to know the username, password, and tenant. Since my custom MembershipProvider is not a Controller, it doesn't know which tenant is using the session, and the ValidateUser method only accepts username and password so I can't pass it that information.
Furthermore, pretty much everything MembershipProvider does besides ValidateUser is already implemented in a UserRepository class, which that tutorial told me to make. I'm rather fond of the Repository pattern, and it's way more convenient than adhering to MembershipProvider's interface, but now there's a massive conflict of interest between UserRepository and MembershipProvider.
So, my question:
Do I need to use MembershipProvider, or even Membership, at all?
It seems like everything MembershipProvider does would be performed more conveniently by my repository class. At this point all I'd have to do is write a new Authorize attribute that doesn't rely on Membership, and everything should work without any MembershipProvider at all, right? If I don't drop Membership I'm forced to completely mutilate my MembershipProvider implementation to the point that it barely resembles the original interface anyway.
...Either that or Membership does a ton of things I'm unaware of and removing it is blatant stupidity. That is also a distinct possibility.
No, you don't need to use Membership, but consider for a moment exactly what Membership is. Membership does not involve your users names, or addresses, or other information. Membership is strictly related to the login account of the system. It only handles details with creating, validating, updating, or deleting the information needed to login. That's it.
Likewise, the Role system is only assigning a role name to the user.
Ultimately, Membership and Roles are just implementations of the IPrincipal interface. While FormsAuthentication is an implementation of the IIdentity interface. These work together so that you can utlize the built-in ASP.NET Authorization and Authentication system.
Membership actually does have the concept of multiple tennants. This functionality is accomplished via the "ApplicationNane" field of the aspnet_users table (also settable in the Membership class itself)
From the documentation on the Membership class:
The ApplicationName is used to identify users specific to an application. That is, the same user name can exist in the database for multiple ASP.NET applications that specify a different ApplicationName. This enables multiple applications to use the same database to store user information without running into duplicate user name conflicts. Alternatively, multiple ASP.NET applications can use the same user database by specifying the same ApplicationName. The ApplicationName can be set programmatically or declaratively in the configuration for the Web application.
Now, this is designed to typically be set in the Web.Config and stay the same for the life of the app, but I see no reason why you can't use it to specify which tennant you want.
The only issue here is that Membership.ApplicationName is static, which means it's shared by all threads running in the App Pool. However, if you use some kind of lock around accessing it, then this shouldn't be a huge issue (though it could affect scalability at some level).
This would basically allow you to use the standard, out of the box membership provider without any changes. You just have ot make sure to guard the access calls.
You don't have to use the membership provider at all. Its simply provided as a quick and consistent way to get up and running. Some choose it because it supports multiple databases (universal membership providers include azure as well as sql ce, express, and full) but for others trying to map it to your applications rules can be more difficult than the <5 lines of code it takes to authenticate and issue your own forms auth ticket.
With that said I'm assuming you are using forms authentication. You can simply issue the ticket yourself. I would still program against an interface for this which the default MVC template should have, so simply add in a new tenant id.
With that said, I'd consider having unique names. It ensures you don't 'forget' to do an additional tenant check somewhere else in the app and tenant1\userBip and tenant2\userBip surprisingly end up stomping on each others record at some point.
True, testing should uncover this - if testing is complete : )
We have an ASP.NET (well, WCF) application that uses the SqlMembershipProvider to authenticate its users. They log in using their username and password.
However, I'd like to group these users by customer, so that every customer can have its own "admin" or "Demo" user. Consequently, they'd log in using their customer id, username, and password.
I have not found a decent way to this with the MembershipProvider yet. Have I missed something?
Thanks!
You are trying to go beyond the functionality offered by the standard asp.net membership provider. It doesn't have those capabilities. The asp.net membership and role system is extremely simple.
One option would be to use Active Directory (possible Active Directory Application Mode to keep things separate and avoid licensing). In AD you have much more possibilities to group users into different containers and delegate control over users in a specific container to an "admin" user.
How does the default template for asp.net mvc store accounts (the AccountController)? Can I add unique numbered ids, since so far I have found out, that it uses unique login as primarz key? Is there a table containing these accounts? And which classes should I look for to work with them?
Thanks in advance.
It doesn't use the unique login as the primary key, not really. Under the hood there's a provider specific membership identifier, which in the case of the SQL membership provider is a GUID.
MembershipUser membershipUser = Membership.GetUser();
object userKey = membershipUser.ProviderUserKey;
In fact it's even more complicated than that, as you can have multiple applications sharing a membership database, either sharing the users, or using an application name to distinguish their users from each other, but calling ProviderUserKey will get the right result every time.
The default MVC app will generate an ASPNETDB.MDF file in the App_Data directory when the first person registers. This contains the "standard" ASP.NET SQL membership schema, which ties in with the various MembershipProvider classes.
I've not really worked with the SQL membership stuff, but I imagine you could extend the schema and the classes to suit yourself.
Why do you need a unique id rather than using the default?