I have an asp.net application that uses the SQL membership provider. I know how to get multiple applications using the same membership provider so a user can go to multiple sites and login using the same credentials. However the requirement on my current project is that each user is given access only to certain applications. For example, the user is given credentials to access Site 1, then at some point in the future, the user needs access to Site 2 and a manager/admin has to allow the user to access Site 2. Or when the manager creates the user's account initially, he/she approves access to the 3 sites (or whatever) the user needs to access.
So my question is what is the best way to use 1 membership provider for many applications, but only allows users to access applications they're approved for (so a manager can manage access to applications, but give users 1 username and password)? I've thought about using roles, but I already use roles in the application for allowing access to certain features in the application. It seems like that would get messy.
I've read about 50 similar questions on SO but none of them addressed the application approval requirement. Thanks in advance.
The easiest straight forward method here is to use roles.
If you add more roles (one for each app) for this purpose it is no big deal. You have a basic role for each app that must be available and check this on Application_AuthenticateRequest or Application_AuthorizeRequest . There are other ways to do it, but this is the least impact, easiest to code (nothing required but a role check), and easy to follow.
Related
I am creating a project which has a login portal with multiple applications and websites. I want to allow the user to login and then click any application and have access to it. Some considerations are: each application is defined in a user profile, ie which users can see what. also each application privileges are different for each user. so user a may be an administrator of application a but just a normal users in application b.
What i know.
I can have one auth cookie created in the main portal which with setting the machine key and same authcookie name, each application can use it. I have done a test with this and it seems to work.
My problem
As each site/ virtual directory has different privileges per user and per application when the user access a site i need to get his privileges from the databases but I cant then overwrite the auth cookie userdata with the new details because he may have multiple tabs etc open at a time on different sites. So how can i have an extra cookie store per user and per application for holding application specific details. I know I could go to the database each time but that's allot of overhead for each post back.
Maybe another option is to use the main authcooke for checking the user is logged in then have a new auth cookie per aplication and user, but how can i have 2 authcookies, that may get confusing and the second needs to timeout when the main one does et c i think
Any help suggestions would be gratefully appreciated
THanks
------------------- EDIT -----------------------------
we have one user table for all all sites not 1 per each site. then we map the user to an application and then the user application and role. so when you get to an application it has to check if the user has access and what there role is. all other user details are already in the auth cookie when loggedinto the main site. We do it this way because we have to manage users in one application not each application. Hope this helps understand my requirements.
What you are describing is a 'classic' SSO (single sign-on) example. There are lots of ways people have tried this and they are well documented on Google.
One way to do this is to have your SSO server (e.g. the first place you land and log in) to issue a security 'token' (e.g. a Guid) and then either store this in a cookie or append to URLs. Each subsequent call to an application can look-up the token in a database, verify it's validity and carry on (or boot the user out if invalid).
Using a database also allows you to set a timeout for all applications for which the token is valid.
This can then be extended to allow the database to store which apps each user can access etc. I've described this in very broad terms but it may be a good starting point.
Hope this helps
BTW: querying the database on each request isn't too much of an overhead. I have applications that do just that and are still performant when loaded with 300+ users.
I am currently working on converting a Windows Desktop application to a Web Site/Application. The data structure for the entire application is stored in SQL Server databases. Each database represents a different "library". One customer can have many different "libraries" (databases), and I'm contemplating placing many customer installations on the same web server.
This will be an internet site, so I'm strongly considering using Microsoft's supplied user account management for site access. I'm thinking that I would then provide administrator-level access that would allow a user to be assigned privileges on a particular database. (i.e., by default, creating a user account through the Microsoft mechanisms wouldn't give any real functionality.)
User access would have the following generic levels:
1. Read access (without this, the user shouldn't even know the library exists)
2. Insert access (user can add records to the system)
3. Edit access (user can alter the details of a record)
4. Delete access (what do you think this does :)?)
5. Admin access (user can modify other users' attributes)
I'm considering a model where there is a single account in the website that handles all SQL Server interactions. Thus, all of the code to handle allowing/denying access levels 1 through 5 above would be handled by code in my website pages, rather than by SQL Server's user account management.
I'm thinking that I would have one, central database that would contain all user names and to which libraries their account has (at least) read access (level 1 access from above). Then, levels 2 through 5 would be stored in each database for that user and that database.
Two questions occur to me:
Is this approach reasonable? Am I missing another way to do what I want (like, using SQL Server's user management tools) that is safer?
If I were going to enact this method, how would I create the "SuperUser" account on the website? I'm assuming it would be some sort of "NETWORK SERVICE" or "LOCAL SERVICE" account, but I'm still a little bit hazy about which account does what in ASP.NET.
Thanks!
Why cant you use ASP.Net Login authentication using Roles and Membership.. I think this should help you..
I have an existing production application that uses vanilla ASP.Net Membership for authentication.
However, I'd like to provide other means of authentication as well as the current ASP.net membership system, such as Facebook.
The Windows Azure Access Control Service makes this extremely easy and straight forward. Provided, that is, you're starting a new web application from scratch.
So, in this case, how do I
Integrate the Access Control Service authentication into my app without affecting the current login system and its users?
Migrate users over or Link logins? ( not sure if this is even possible)
Thanks all
Roberto
You need to create a custom identity provider based on your membership database. See this article on custom WS-Federation Identity Providers that can be integrated to access control: http://msdn.microsoft.com/en-us/library/windowsazure/gg185933.aspx
Also see this article on one that was written on top of the membership database: http://blogs.msdn.com/b/vbertocci/archive/2009/04/23/enhance-your-asp-net-membership-based-website-by-adding-identity-provider-capabilities.aspx
Approach of creating an identity provider (IP) based on your ASP.NET membership database which Paul Tyng suggested is valid.
However, it means that if you just create an IP you'll allow log in to all people who are authorised with other IPs (e.g. Google or Facebook). I'm guessing it's not what you want - you'd still want people to first register (either plainly with username-password or with their external identity). If that's the case then your task is the following:
Add a data store for users' external identities which is related to your existing Users table.
Modify the ACS login handling within your application to check that the identity returned from ACS actually exists in your members database.
Perform member log in (instead of federated log in) if you found the returned identity in your db.
Add external identity tie in during the registration process so your Identities table can be actually populated.
(optional) Re-use the bulk of the #4 mechanism to provide an ability to attach external identity to existing user accounts (i.e. I already have a normal membership with you and now want to add an ability to log in with Google as well, for example).
There is no one single tutorial/walk-through to achieve this (or I have not found one) so I had to pull bits from a variety of sources to make it work. Please let me know in the comment if I understood your requirement correctly and I'll add a guide on how to set this up. Cheers!
Might be a bit late, but check out the following blog posts by fellow Windows Azure MVP - Dominik Bayer:
Mixing Forms and Token Authentication in a single ASP.NET Application
Mixing Forms and Token Authentication in a single ASP.NET Application (the Details)
Replacing ASP.NET Forms Authentication with WIF Session Authentication (for the better)
Invaluable readings which will help you in any way!
I’ve been asked to upgrade a few applications and I’m planning on merging all of them into one asp.net application. I’m fine with this decision and have spoken with fellow workers and they also think it’s the best option to go with.
The application will be accessed from a small group of users which belong to a larger domain. I’m currently planning on using Windows authentication and only allow this small set of users to access the asp.net application. Also there must be some role management, so that only certain users can view certain functionality.
I really don’t want to have many different windows groups; so I want to avoid having to assign different windows groups to different folders and control permissions in the web.config.
What I’d like to do is:
- Assign one windows group to the small group of users who will access the page.
- Create a custom membership provider and control the user who accesses the application. Depending on the user I will then assign his current set of roles.
- Add an application setting to the web.config, with the name of the current administrator, so if he logs in, he will be assigned all roles, and will be able to create and assign roles to other users.
I’d appreciate some advice if this would be the correct way to go about this.
Thanks!
I would check out the AccountManagement Namespace.
I like to use this. You can create a global security group (one for each 'role'). The account management namespace will allow you to fetch the UserPrincipal from AD with their logon name from the http context. Then you can check them for memebership in the security groups you created using the .IsMemberOf Method.
I'm working on a project that needs to authenticate users based on records in two different databases. All administrators are stored locally and require full functionality to manage their accounts (reset password, etc). Regular users are authenticated against a different database used by another web app, so I only need to check that their credentials are correct.
After entering their username/pass at the logon screen, my app should check if they exist in the local admins table. If so, they are given the role of 'admin' and allowed access. If not, it should then check the other app's user table and give them a 'user' role if successful.
The project is basically a large online book. Users simply need authentication to view it, rate the sections, and bookmark pages. The rating/bookmark data will be associated with their unique id. All user management is handled in the external app. Admins, however, will only be able to view/edit the pages and will NOT be rating/bookmarking things. Their accounts will be managed with this admin area.
What is the best way to accomplish this in a .NET MVC application? By 'this', I mean integrating the logon/authentication system with both and assigning them a role based on which database confirms their credentials.
Thanks in advance!
MVC really doesn't have much to do with your user validation logic - you'll need to implement a custom membership provider to handle connecting to both databases and performing the validation. This membership class could be ported to any application though, it's not specific to MVC.
Once you've got your logic in your custom membership provider, you just need to use FormsAuthentication with your MVC app, of which there are lots of tutorials around, here's a quick one.
The only tip that I would add that pertains to MVC is that you should try to keep your logic for view decisions in your controllers. It's tempting to put something like "<% if user == admin then renderPartial(this) else renderPartial(that) %>" in your View, but that violates MVC principles in my opinion. Much better to use ViewModels or populate ViewData in your controller.