I'm currently developing a full web client administration system on Symfony2. However, the question whether to create a User entity and a separate Client entity or have the User entity manage all client information (like it's credit state) remains unanswered.
From what I've gathered, using a separate entity for each thing permits me to have a better separation between the login system (which needs a User entity with basic properties) and the bussiness logic (which needs a Client entity with all the properties a client in the real world has). However, that would mean having a bigger footprint (if they were saved in a database, I would have to use a join statement) than having a single entity contain all properties.
What would you recommend in this case? Is there anything I'm missing?
For the user login and system you can use FOSuserBundle
If your clients also need to login in same system then i would say that you go for
https://github.com/netmeansnet/NmnMultiUserBundle/blob/master/Resources/doc/index.md
Then you can have separate class for each type os users and define custom properties
They all will use same basic attributes like username , password and then you can have extra information for client Enitity
Related
Background:
I'm incorporating the SqlMembership provider into an existing system where I'm building a web front end. The Membership database will be kept in a separate database.
Beyond the login account, there's an additional mapping between the accounts that needs to be in place in the main database in order for an account to be able to log in.
Let's say that this table gives the user the right to use the system.
My question:
I would like to somehow incorporate this into the provider. Is it possible without too much work? (Or is it better to keep it in the AccountMembershipService class?)
Actually regardless, I'm very interested in learning how to put additional login requirements into the provider.
I'm asking this because when I've been looking at creating a custom membership provider earlier it seemed at that time a little bit overwhelming.
In other words:
I want to understand how to extend the Membership Provider classes in general and how to extend the login method (ValidateUser) in particular.
Given the sample ODBC implementation It looks like one simply could subclass the default provider and override ValidateUser calling base.ValidateUser as the first step.
However it may or may not be that simple, and I'd be very happy to hear any first hand experiences from implementing or extending membership providers.
I wanted to do something similar, one of the requirements was to use an Oracle DB, so I implemented the OracleMembership provider, hence I could not waste my time rewriting the hole oracle membership provider (it works pretty fine), the second requirement was to use a custom authorization legacy system. So I realized that the Internet Application template which comes with the MVC 2 or 3 comes with a small implementation of the security for the site, specifically take a look on the AccountMembershipService class. You could move all of these elements out of the MVC app to a separate assembly so you could use it even on a client implementation. The AccountMembershipService uses the Membership provider as the underlying authentication system with the option of using FormsAuthentication.
So I recommend you to take a look on that implementation. You could put your additional authentication code there so your application would stay cleaner and your don't need to re-invent the wheel and you have the chance to add your own code.
best regards
In order to extend the membership provider make you own tables with one to one relationship with the main database and handle additional requirements through this table. Also while implementing and extending the default membership provider you may need to store extra information in authcookies you may get additional information from here , here and here
In GetUserCredentials you will do your stuff for additional checking and RoleID is some dropdown on your login page that you will receive in the post method of sign in.
FormsAuth.SignIn(userName, rememberMe);
ApplicationRepository _ApplicationRepository = new ApplicationRepository();
MembershipUser aspUser = Membership.GetUser(userName);
SessionUser CurrentUser = _ApplicationRepository.GetUserCredentials(aspUser.ProviderUserKey.ToString(), RoleID);
if (CurrentUser == null)
{
ModelState.AddModelError("_FORM", "Invalid Role ");
FormsAuth.SignOut();
return View("signin");
}
Summary: I need to authorize pages based upon the data present in the query string of a url, not just the page name.
Background:
Let's say I'm building a library inventory system. Users can be created and assigned to a single library in either an Admin or User role. There are hundreds of competing libraries in the same database, so it's important to ensure that users of one library cannot view inventory from another library.
Right now I'm using a pretty standard ASP.NET setup: Forms Authentication using the SqlMembershipProvider. Authorization using the SqlRoleProvider, configured via <authorization> sections in the web.config. Security trimming with the SiteMap provider to hide unauthorized pages.
To control the inventory information from leaking, I'm manually checking a user's associate library ID with every inventory query. It works, but it's tedious and prone to errors. There has to be a better way.
Question:
Now users have the ability to create arbitrary "collections" within a library. (e.g. Collection A has Books 1, 2, & 3 in it.) Admins want the ability to grant Admin / User access on individual collections, not just the entire library.
So, if a user goes to www.com/Book.aspx?BookId=1, the system needs to ensure that user has permissions for the collection that "Book 1" is in before showing the page. If they go to www.com/Reviews.aspx?ReviewId=23, I need to make sure the Review is for a book that is in a collection that they have permission to view.
1) How can I implement this in the most standard ASP.NET way possible?
Manual checking within a base page?
A custom HttpModule?
A custom Role Provider?
I'm not interested in how to store the admin/user permissions, but rather how/where to authorize based on those permissions.
(examples on how to implement any of those are appreciated)
2) To further complicate it, I'd still like security trimming to check if the user has Admin rights on any collection or library and hide the admin pages if he doesn't.
I wouldn't handle this anywhere near the UI (ASP.NET) layer but rather within the application services. Something like:
Build services which take an IPrincipal (or your custom user object)
as a constructor parameter.
When requesting a book/review/whatever, the service is responsible
for looking to checking to see if the user has access to the
resource.
If the user doesn't have access, do some predetermined thing (pass a
message, throw an exception, return null).
This will be alot more testable and usable in the long run then worrying about it from the ASP.NET UI side.
If you have to handle it on the ASP.NET side, I'd consider using a custom IPrincipal and custom RoleProvider to wrap up each library as a role to access, then you could use most of the LoginView, etc. controls.
Normally, this sort of thing is handled at the data level. It has little to do with ASP.NET, other than ultimate you need a user-id (which comes from Membership). What you do is find some part of your entity that you want to control access on, then you create all your queries to filter on that.
For instance, if you make access at the Library level, then you would add an association between the user and the library. This can be a 1:1, 1:many, many:many, whatever your data model requires. The key is that joining through this level will always return no records, thus your entire query will return no records.
Example, assuming a user can only belong to one library.
User table has LibraryID, Books table has LibraryID, This makes an effective many-to-many join between Users and Books. So you join User and Library on LibraryID, and join Library and Books on LibraryID, then only books that belong to a library that the user is associated with will be returned by the query.
In this way, it becomes impossible for a user to query anything they are not directly associated with. The security is entirely in the database, and no business logic is required.
I've got a generic ASP.NET (MVC) application, that uses NHibernate as the model persistence layer, and ASP.NET Membership/role/profile services as the user management layer.
The question is what can be considered as the best practice to create linkings between the domain data and the users. (For example is I want to create a forum system I want to link each topics/posts to a specific user, and want to display the user at each request).
These are the posiibilites I've been thinking of:
Store the user ID in NHibernate (like having a Guid column in all your domain classes (Posts, Topics etc.) that needs to reference a User) and use GetUser each time you need the name of the user from the guid (which might result in n+1 queries)
B variant: Alternatively store the user name too.
Use the same database, and create a read-only NHibernate maintaned domain object User, that maps to the same data as the M/R/P services do.
Forget about M/R/P and create a separate user management service based on NHibernate
Forget about both and use J2EE/RoR/merb/DJango/etc. (please don't pick this option :) )
other...
I would go for step 2 (almost, as it does not necessarily needs to be readonly) and create a custom membership provider for NHibernate.
To save time you can use an existing one like the one from Manuel Abadia.
With that you keep the full power of NHibernate (lazy loading, etc.) and enjoy M/R/P services too.
There is also a NHibernate based Membership provider at CodePlex
4 guys from rolla have an excellent post if you want to buil your own provider on top of the asp.net membership API : https://web.archive.org/web/20211020114106/https://www.4guysfromrolla.com/articles/110310-1.aspx
I'm in need of a RoleProvider with the following functionality:
Dynamic Assignment of Roles to Tasks
Authentication / Authorizaiton of IPrincipals based on the dynamically allocated tasks in the system they have privilege to access
Reporting showing who is currently logged in, and other common usage statistics.
I'm pretty sure I'm going to have to roll my own, but wanted to make sure I didn't miss out on something OSS or even from MS.
I'm also using ASP.NET MVC and so my basic plan is to write a custom attribute like: [Authorize(Task=Tasks.DeleteClient)]
and place it over the methods that need authorization.
Rather than authorizing against the Role, I'll authorize the task against the role based on whatever settings the user has configured in the DB.
Thoughts?
You might want to check out NetSqlAzMan. It allows you to define tasks and assign them to roles and then authenticate and authorise your IPrincipal objects.
You may need to roll your own security attribute but NetSqlAzMan should help make that a reasonably easy task.
We had a similar issue with one of our systems. The first thing I'd do is create more AuthorizeAttribute classes for your specific tasks - e.g. DeleteClientAuthorize etc. You can then add specific logic into your classes.
As long as you can access the routines that trigger the change of roles for the current user you should be OK. Just call Membership.DeleteCookie() and this will force the next authorisation request to re-query your data store. It's at that point that you can determine what roles are required now.
Okay,
I know I'm doing something wrong - but can't figure out a better way.
I am developing a website which is going to allow users to setup their own mini-websites.
Something like Ning.
Also, I have only 1 basic login and access to each mini website is provided (right now) via roles.
So the way I am doing this right now is:
Everytime a new mini website is created - say blah, I create 2 roles in my application.
blah_users and blah_admin
The user creating the mini website is given the role - blah_admin and every other user wanting to join this mini website (or network) is given the role - blah_user.
Anyone can view data from any website. However to add data, one must be a member of that mini site (must have the blah_user role assigned)
The problem that I am facing is that by doing a role based system, I'm having to do loads of stuff manually. Asp.Net 2 controls which work on the User.IsAunthenticated property are basically useless to me now because along with the IsAuthenticated property, I must also check if the user has the proper role.
I'm guessing there is a better way to architect the system but I am not sure how.
Any ideas?
This website is being developed in ASP.Net 2 on IIS 6.
Thanks a tonne!
I afraid standard roles-related stuff of ASP.NET is not what you need. You can try to change authentication module so it will:
Log you in with cookie.
Determine what roles does your visitor have. Perhaps you will use some special table that corresponds user and site.
Make custom principal with user roles enumerated and assign Identity and Principal to the current request.
I also don't think that making special roles for each site is good idea. When you would have hundred sites, you would also have two hundred roles. Pretty unmanageable, I afraid.
When we were solving similar task, we were just not using standard controls. We had single set of roles used on all sites. Membership of concrete user is determined according to current site and his relations to this site.
Addition: Another possibility to investigate is Application that exists in ASP.NET authentication system. Maybe it's possible to isolate each subsite into separate application?
Update: Method that works for our application.
Do not make a lot of cloned roles. Use only two: users and admin. If your sites are public then "users" role could be just global - user on one site doesn't differ from user on another site. If "users" and "everyone" are different roles, then of course "users" should also be bound to a site.
Use standard ASP.NET Membership users, but do not use standard role mechanism.
Make a mechanism for storing relation between site and user. It could be simple table that holds site id, user is and role.
What you have to override is IsInRole method. (Methods to be exact, i'll cover it later). This method is in IPrinciple interface, so you have to make your own principal object. It's quite simple.
Method IsInRole of this type should look take current site (from HttpRequest) look into the site-user table and get roles
Then you have to associate your principal with a request. Do it in PostAuthenticateRequest event.
There is also RoleProvider. Honestly I'm not sure when is it used, but it also have IsInRole method. We can override it in the same way. But other methods of this provider are harder. For example AddUsersToRoles. It accepts array of user names and roles, but to what context (site) should it be added? To current? Not sure, because I don't know when this method is called. So it requires some experiments. I see (Reflector helps) that RopePrincipal by itself uses RoleProvider to fetch list of roles, so maybe it's implement only RoleProvider, using standard principal. For our application this is not a case, so I can't say what problems could be hidden here.