Setup:
Multiple web servers with synchronized
forms authentication.
Multiple asp.net Applications running on these severs.
What's working:
SSO across all servers
Authorization using asp.net roles
What's not so good:
All roles are "global" - I have "admin-app1" and "admin-app2" etc.
Question:
I know this can be solved by defining different "ApplicationNames" for each of the different applications but what is the most easy way to compile a list of all the different applications a logged on user has a role in?
I would like to do something similar to: CurrentUser.Applications()
to get a list of "all applications in which the current user has any role".
Up to now I have used Roles.GetRolesForUser() to compile the list not very elegant or scalable.
Using the SqlRoleProvider I can hack inte the DB to get the complete list of Applications and then compile an application list for the user by query the different application's role providers. My best shot so far but it doesn't feel like the best solution...
Any hints or comments?
BR, Jens
I have come to the conclusion that this cannot be done using the framework.
Anyone who tries to do something similar e.g. buiding a dashboard of all asp.net applications hosted has either to maintain the list of applications separately or hack into the sql tables if you are using the SqlRoleProvider .
Happy hacking!
/Jens
I think ApplicationName is for completely separating applications while using the same database. Are you sure you can link users in one application name to roles in another?
Your best bet is probably to keep the same application name and implement a custom role provider.
http://msdn.microsoft.com/en-us/library/8fw7xh74.aspx
Related
Does SimpleMembershipProvider use ApplicationName in anyway? I don't see any tables that will help it link in the documentation. I don't see any tables generated or linked in the actual source code itself,
GitHub - ASP-NET-MVC/aspnetwebstack
But isn't membership inherently bound to an ApplicationName? Or is there any workaround I can use to get this associated with. Basically I have an application and an admin portal, I want to use the same tables, but use different applications to identify different users and roles.
Thanks,
Fahad
You can use custom UserProfile table for storing such information. There is a very good information on asp.net blog: Customize the SimpleMembership in ASP.NET MVC 4.0
You may also consider migrate your project to MVC 5 and use OWIN authentication
No they moved away from the idea of partitioning users by ApplicationName (it seems a strange use case).
The preferred way would now be to just specify different connection strings and use separate databases (this assumes you have multiple apps).
If you want to partition users within a single application, you would ideally have 2 providers and direct calls accordingly, but SimpleMembershipProvider doesn't support non-default providers so you can only use one. You can overcome this, take a look at BetterMembership.Net, this supports multiple instances of SimpleMembershipProvider from a single application.
I'm implementing my frist web application on asp.net mvc 4 and I need to differentiate my users according to roles ( show certain menus to some roles and hide them from others) basically what i want is to manage my users and roles. I understand that security is quite an important part of my application so I don't want to risk it by implementing something not secure while there are other options for doing this.
My question is, is there something already built on MVC 4? is it apropiate for my a small site? ( I don't expect more than 50 concurrent users) is it better to implement my own user administrator? if so, where can I start? so far what I've found is the membership provider but it seems quite big for what i need, there will be no user registration instead the new users will be added by system admins.
Thanks for taking the time for reading this, any feedback will be appreciated!
I would have recommended the default membership provider as it makes use of security industry best practices (i.e. salted hash). However, if that seems overkill, there is a simpler membership provider called SimpleMembership Provider
You can use New ASP.NET Universal Providers (updated version of legacy Membership Provider).
It can be used in small application as well as large application (if you application continues to grow).
Password is encrypted with salt, so it cannot be compromise easily.
Follow the Scott Hanselman's link and see the demo. You will see how easy to set up.
I'm creating an ASP.NET website and intend to have multiple "Applications", each with its own set of users. Effectively I need a way to have different groups that people can register with, so "UserA" can be created in "ApplicationA" and "UserA" can also be created in "ApplicationB". I do not want UserA to be created in all Applications, the user has to feel as though they're creating a separate user account for each application.
I think I can do this with ASP.NET's Membership provider and the Applications table, but I'm having a hard time finding good tutorials on how to do this (searching on "Applications" just leads me to how to create ASP.NET Applications, not how the Applications table relates to the ASP.NET Membership). Can anyone point me in the right direction here?
Yes, you can use ASP.Net Membership for your applications that you have stated.
Please use new ASP.Net Universal Provider. (Membership which generates aspnet_xxx tables is an old one.)
Also make sure to set the following in web.config -
set applicationName (in membership, roleManager) for each appliation.
set machineKey
here is the schema:
http://superpatrick.files.wordpress.com/2007/11/aspnet_membership_schema_updated.png
here is some info about the membership
http://www.asp.net/web-forms/tutorials/security/membership/creating-the-membership-schema-in-sql-server-vb
Hai,
i am trying to store the user permissions for my web site.But I am little bit confused with xml and Database. For each user in site have different permissions. Have u ever faced this issue? for Example , if my site is a shopping site , for a local user , the report menu need not to display. A sales man need not to display the purchase page. and so on ..
I think you understood my problem .I have done this user management using a xml file . For each user a new node will create according to the menu and keep in the xml file . Next time the user login ,checks the permissions and and show only the allowed menus.
My boss tell me to do the same thing using the Database. by using XmlDataSource it is quite simple to bind data to the treeview (for setting permission) and binding to the menustrip also.
He is pointing the security problem . i don't think like so.
Which is better ? DB or XML
http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
My advice would be to use asp.net membership and roles (written by Microsoft). It is a very good security solution - login security, roles (permissions) and is stored in a SQLServer database (not sure if it can be stored elsewhere).
I use it on my site and you can use membership controls straight out of the box (login forms, change password, etc.) or you can roll your own.
The only tricky bit I found was setting up the membership tables, views and stored procs in my dB (you download a dB script), but really it was fairly straightforward to implement.
Here's a link to asp.net membership and roles
ASP .NET Membership and Roles (part of the Provider Model introduced on ASP .NET 2) is (IMHO) nice only when you need some basic stuff. The issue is that you need to use the whole system using SQL Server, but if you are planning to move to a different DB provider (MySQL, SQLite, etc..) then you'd have to implement your own provider (which is at best painful), and learn how the whole pieces fit each other. Granted, finding a custom implementation it's quite easy, but is not a copy & paste thing.
Another bad thing of the default provider model is that you will get a ton of SQL stored procedures, also called maintainance nightmares. The issue is that if your site scales, then these SP's will make your life a living hell (been there) and if you even dare to change hostings then you're in for a treat, so my advice would be make your own permissions hierarchy and use it the way you wish. Also, look for advices and some pre-existing solutions to the permissions problem which is quite common.
Website security can be split up into to distinct parts.
Authentication: Logging in
Authroization: Roles/Permissions.
The ASP.NET Forms Authentication Provider is a great way to implement authentication. I recently created a custom provider that communicates with our companies X500 directory (LDAP). It was very straight forward.
For Authorization, we implemented the entlib security application block. It allows you to keep Roles/Permissions in a separate location that can be accessed by your UI as well as your service layers (assuming your developing a scale-able solution). You may also want to look at the Windows Itentity Foundation which is slated to supersede entlib security application block, however it is only available for .NET 4.0.
In my current project, we need to authenticate users of an ASP.NET application against Active Directory. I think it can be achieved using the membership provider without too much problems. but we need also to manage user roles that will be kept in the ASP roles management tool.
Did anyone implement this configuration? Does it look feasible?
Any tip for one or the other point?
Thanks.
David
Yes! The ASP.NET role provider is designed to work exactly in that case - the particulars of the authentication provider are irrelevant to the role provider, and it will store the bare essential information to make the two work together - basically the user's AD identity (domain\user) is tracked in the role database and matched up when necessary.
There is an ActiveDirectoryMembershipProvider that can be used to use Active Directory for authenticating users.
Alternatively, you could roll your own MembershipProvider by extending the abstract MembershipProvider class and then use System.DirectoryServices to check against Active Directory when validating a user (ValidateUser method of MembershipProvider). This is pretty straightforward to do and you need only implement the methods that you actually need in the custom provider.
You might consider implementing your own RoleProvider too, depending on whether the default fits your needs.
Use it all the time, intranet only of course.
You may be interested in the WindowsTokenCachingRoleProvider. In scenarios where performance is essential, this really shines:
http://lvildosola.blogspot.com/2007/02/improve-performance-when-using.html
Simple and elegant.
Please take a look at this question, seems like you're asking for pretty much the same thing, and my answer there should give you what you need.
ASP.NET Membership and Role providers that can be used from ASP.NET and WinForms/WPF clients as needed.