i have a web site that uses forms authentication. the problem is that i have the site installed multiple times on the same production servers because i need to have a few different login pages (based on the domain in this case). after the domain specific login page, the rest of the site is the same. obviously, this requires a lot of maintenance as each new version has to be installed multiple times on the server (with varying the login page in the web.config file).
so i thought is there a way to install the site on 1 folder on the disk, have a web site on the IIS take in all the needed domains and make some http module (or some other solution) in which i could give it a list of domains and the forms authentication for that domain. this way make the login page used by each site change according to the domain while still having only one site to maintain on the server.
Thanks
Dani Avni
I have seen this go a number of ways and a lot of it depends on how you have things setup in IIS.
If all domains are on the same IIS website the most common solution would be to create a httpmodule, or even an actual .aspx page, that loads configuration and based on the requested URL send the user to the right login page. You could even do a "Server.Transfer()" if you want the users URL to stay the same. Then in the web.config you still set a single login page. Just make sure that each other login page allows anonymous users access.
If all domains are separate IIS sites, i would recommend at that point just maintaining different copies of the sites. But the real question is why you need different logins.
My workplace has a couple of web applications that do exactly what you are trying to describe. There are a couple of approaches we have used, depending on the situation.
The more common approach we use is to have all the actual sites on IIS point to the same directory. The logic for the login gets the URL, determines which client site is being requested, and takes that into account on login. The actual login page is the same for all client sites, though, so it's just determining which database to use.
If you want to do anything fancier than that, another approach we have used is to create our own MembershipProvider, at which point you can basically do whatever you want. You should have access to HttpContext.Current if your class is being called by the ASP.NET authentication provider (you would set the membership provider in Web.config to your provider).
Related
I have 40 individual asp.net webform websites created for different purposes with different databases.
Now my task is to get all this in one roof.
Since everything is indivdual websites the user login credentials are available in separate tables with authorization rights from sql table which controlled in webconfig.
My problem is that each websites consist different Login Tables with user data.
One user is allowed in 4 websites.
One user may be allowed in 25 webites.
One user may be restricted to use only 1 website.
Tot user count is 3000.
What is the best approach to merge all this websites in one roof with same kind of individual website login authentication mode?
I tried to keep root level webconfig and folder level webconfig. The root level webconfig will check the user login and allow to enter home page.
In Home page 40 websites are listed. When user clicks any website it go to the concerned websites folder and act like individual website like current method. But it is not working since folder level webconfig is not allowing to have authentication mode getting stored in it.
Any suggestion / direction will be highly helpful.
Well, assuming you have all web sites under one site?
Then you would have a user role that secures each site, and if the user is not a member of that security group (role), then they would not be able to use that sub site.
So, you need/want 40 roles, and then you can have one logon, and then assign a role to that user for each web site.
with some kind of admin page, you could list out the sites (the role for each site) and have the admin check which sites they belong to.
So, assuming your using standard web security (most likly FBA), then you not have to write new or additional code for this to work. But then again, this also assumes that roles are the same for each site, since if security was used in each site - based on role of course, then you would have to keep the existing roles, and add one more new role to each user that allows use of the given site.
I have looked at numerous articles and tried a multitude of settings, but I can't seem to achieve what I'm looking for in my intranet site. Even if I don't get a solution, a definitive "you can't do that" will help me move forward. Here is what I'm trying to do:
Web site recognizes the user's network login credentials - ONLY so I can get their user ID without a login
The website uses some generic account (IUSR or something like that) to access a SQL Server that the same network users can NOT access EXCEPT through the website
Users can upload files to a set of folders created on-the-fly by the website to contain their files for later reference by them
The website can construct web pages on-the-fly with links to the users' files - and ONLY theirs - so they can open / download them through the web pages
Users can NOT access the uploaded files through a network share on the web server
All of the folder creation, file upload, and file serving occur under some generic account like IUSR
I currently have things configured to use Windows Authentication and I could probably live with that except I don't want to require a login to the site. Apparently, in order to make this happen, I need to have the server configured as a trusted delegate and IT is dragging their feet on doing that. Also, this config allows the users to access the SQL Server and folders/files through means other than the web site and I don't really want that. I only need to pick off their user ID so I can use it to get information about them out of Active Directory and keep track of their interactions with the web app.
In reviewing your post I must first say "Yes" it seems like what you want to accomplish can be done. However the enormity of your question precludes simple posting answers. From what I gather there are three security issues you want to navigate 1) Windows Authentication, 2) Admin only SQL access, 3) User only Access to files and directories while authenticated using Active Directory.
I have been building ASP.net intranet web applications using Active Directory (Windows logins) for a few months. I would encourage you to explore this article: http://www.mikesdotnetting.com/article/216/windows-authentication-with-asp-net-web-pages for details on setting up windows authentication in an ASP.net web application. You can add elements to your web pages using a section of Visual Studio [Toolbox] called 'Login', which contains elements such as 'LoginName'.
Next I am pretty sure you can control the SQL server query access using authentication parameters of your choosing. In the portion of the connectionString that is normally 'Integrated Security=True;' you will need to switch that to 'Integrated Security=False;username=sqlAdminUserName;password=sqlAdminPassword'. For more information I suggest reviewing this post: Integrated Security = False.
For the third security issue once you have isolated the user's windows login identity you should be able to dynamically build web pages, files, directories, and whatever other resources you require all customized for that individual user. I believe the generation of all those materials can be done with an IUSR account with the only needed ingredient being the Windows login user identity.
Good Luck and I hope my suggestions help move you ahead.
Actually, the answer is not all that complex and it is a real mystery why it is so difficult to find a single source on the web to spell it out. Here is my IIS authentication for an intranet app that acts exactly how I want:
Enable ASP.NET Impersonation and edit to Authenticated User
Enable Windows Authentication
Advanced Settings->Extended Protection->Off
Advanced Settings->Enable Kernel-mode authentication->unchecked
Providers->Available Providers->Negotiate:Kerberos and move that to the top
Disable all other authentications
Most critical: Make the server a 'trusted delegate' in Active Directory
That should do it.
BACKGROUND: We are giving our web site users the ability to create fundraising pages.
TECHNOLOGIES: asp.net 3.5 (web forms), Sitecore CMS 6.4, IIS 7
ISSUE: I'm trying to determine which url scheme is most convenient for users and which is more maintainable from a code perspective.
Idea #1: Create a subdomain - fundraising.mysite.com/johnspage
Idea #2: Use main domain - www.mysite.com/johnspage
Here are some thoughts that come to mind about using sub domains or not.
THOUGHTS:
We are using Sitecore CMS 6.4 so we will not be creating a separate website if we use a sub domain. The sub domain will simply point to the main domain.
If we use a sub-domain or not I plan on having a handler that redirects each fundraising page request to an actual page which looks up the users fund raising information and displays it. (the handler will inject a cookie or querystring). If we use sub domains it will be easier for our handler to know the request is for a fundraising page.
If we use a sub domain I want our handler to redirect to our actual site. This will avoid cookie issues between domains and sub domains. (Sure the cookie issues can be overcome, but I want to avoid them out of the box). So if the request is fundraising.mysite.com/johnspage the handler would turn this into www.mysite.com/actualpage?parameters... (or maybe use cookies)
With a subdomain we can avoid the issue where a user creates a page that has the same name as an existing 'real' page. We are using Sitecore CMS so pages don't actually exist in Sitecore but we would not want a users fund raising page to resolve to a sitecore item. (if you are not familiar w/ sitecore you can think of trying to avoid the problem where the users fund raising page has the same name as one of your existing pages, using a subdomain makes this problem easier to manage. I guess you could also do this w/o a sub domain just put the handler logic early in the http request pipeline).
When the user goes to share their page, www.mysite.com/johnspage might be easier to remember for the user. They could simply say go to mysite.com/johnspage instead of fundraising.mysite.com/johnspage. The subdomain makes the url different then the main site and longer to pronounce. Sure users can cut and paste any url we give them, but if they are verbally sharing the url then having a sub domain could be inconvenient.
QUESTION: Would you use sub-domains or point to the main domain or is their another approach I am not thinking of? Any other thoughts you can provide?
Maybe I am misreading your question, but these statements are telling me that you don't want an actual item for each fundraising 'page.'
redirects each fundraising page request to an actual page which looks up the users fund raising information and displays it
as well as:
we would not want a users fund raising page to resolve to a sitecore item
I might suggest that you look into using 'wildcards' and setup a structure such as:
/sitecore/content/home/fundraisers/*
Now, your sublayout/rendering for the wildcard page would be responsible for resolving the specific user, fetching the data and render it.
There are a bunch of resources on Sitecore Wildcards such as:
http://www.sitecore.net/Community/Technical-Blogs/Getting-to-Know-Sitecore/Posts/2011/09/Wildcards-and-Data-Driven-URLs.aspx
I have a question that doesn't need any specific answer, just a general direction of what to do. I work for a company that has many sites. Each site requires a login at some point. We have a single Accounts database that all of the sites hit.
One of the requirements for the login system is that if we login on one site, we should automatically be logged in elsewhere.
The way it works right now is that on page load (or init, forget which) at any of our sites (let's say site1.com), it redirects to a "master" site (let's say sitemaster.com). On sitemaster.com there is a web service which checks to see if a cookie exists on sitemaster.com for that user. If it does, it redirects back and lets site1.com know that the user has already logged in (site1.com then creates a cookie for site1.com so we don't have to redirect to sitemaster.com in the future). If the user is not logged in at sitemaster.com, site1.com will then ask the user to login and, on submit, it redirects the user to sitemaster.com which logs them in, creates a cookie under sitemaster.com domain, redirects back to site1.com and lets site1.com know that the user is logged in (which then creates the cookie for site1.com).
On logout a similar method is employed.
Is this the best way of handling universal logins, or auto-logins across multiple sites? Is there a better way of doing things?
Some requirements:
Most of our sites are in .NET 2.0, but there are plans to update them all to .NET 4.0. We want the best method for this auto-login system so if something requires .NET 4.0, that's ok.
The solution should not require javascript (our current solution requires javascript during the login process).
The solution should not require Flash.
It's ok to use iframes, as long as javascript is not requred.
We would like to be able to do AJAX logins (using jQuery) without having the site refresh. The current solution, due to the redirects, prevents us from doing that. (eg: Pop up a modal box asking the user to login, and when they do, the modal box disappears and some content is changed, but no site refresh required). This isn't absolutely necessary, but at the very least we should be able to verify a login using AJAX before any redirecting takes place.
Any articles or suggestions will be very helpful. I also have some questions related to the best way of re-using the auto-login code across sites (varying from ASP.NET 2.0 Forms to ASP.NET 4.0 MVC, but I'll save that for another question).
Bara
At a simple level, your system works very much like OpenID. It might be worth implementing your own internal OpenID provider and save yourself all of the custom work and maintenance/bugfixes etc for a bespoke system. OpenID is supported by many many sites, including stackoverflow.com.
http://openid.net/
and
http://wiki.openid.net/Run-your-own-identity-server
which leads to:
http://www.dotnetopenauth.net/
-Oisin
What you've described is a federated Web Single Sign-On scheme. Ultimately, I'd recommend that rather than rolling your own, you adopted the WS-Federation standard. The advantages being that you're less susceptible to introducing security vulnerabilities and also have the ability to achieve Single Sign-On with applications other than bespoke ASP.NET apps.
Our customer has a requirement to extend the functionality of their existing large government project. It is an ASP.NET 3.5 (recently upgraded from 2.0) project.
The existing solution is quite a behemoth that is almost unmaintainable so they have decided that they want to provide the new functionality by hosting it on another website that is shown within the existing website.
As to how this is best to be done I'm not quite sure right now and if there is any security issues preventing it or that need to be considered.
Essentially the user would log on to the existing web site as normal and when cliicking on a certain link the page would load as normal with some kind of frame or control that has within it the contents of the page from the other site. IE. They do not want to simply redirect to the other site they want to show it embedded within the current one such that the existing menus etc are still available.
I believe if information needed to be passed to the embedded page it would be done using query strings as I'm not sure if there is even another way to accomplish this.
Can anyone give me some pointers on where to start at looking to implement this or any potential pitfalls I should be aware of.
Thanks
if the 2 sites are hosted from the same network (low latency between them) you could use state server for session management. that way, when you authenticate on one site, you will also be authenticated on the other, and share user state across them.
its pretty simple, in your web config of each web server you'd point to the state server (which could be located on one of the web servers)
<configuration>
<system.web>
<sessionState mode="StateServer"
stateConnectionString="192.168.1.103:42424"
/>
</system.web>
</configuration>
http://en.csharp-online.net/ASP.NET_State_Management%E2%80%94Storing_Session_State_out_of_Process
create a virtual directory under the primary domain. If your domain is www.mydomain.com then create a virtual directory www.mydomain.com/site and port the new website application under /site virtual directory. This was linking should become very much relavant. With this the virtual-directory application will also retain all domain cookies set by primary domain.
I would suggest to make the second website look exactly like the first one or at least use the same MasterPage, so you can redirect from one site to another without any visual difference.
If your site needs authentication, consider that you would need to do something to prevent the user to log in twice, an option could be to send an encrypted token to the second site.
All of this if you are forced to have a second site, if not just use a virtual directory
You could use something like UFrame. I've used it a couple of times and seems to do quite a good job with it...
"goodness of UpdatePanel and IFRAME combined"
http://www.codeproject.com/KB/aspnet/uframe.aspx
I would use an iFrame to embed that website in within your existing application. Just set the "src" attribute and pass in any query string parameters the other site needs to render correctly.
You can still pass in sensitive data in the query string, however it would make sure to encrypt it before sending it in.
I know it is not the most elegant solution, but it gets the job done. And from the description of the existing app, it doesn't seem like your customer cares for "elegance" :)
Hope this helps