I am wondering what the best way to secure our applications is for the following situation. Basically, we have a page where we authenticate users, and once they user has logged in they have an option to select from various applications. My dilemma is how to pass that the user is authenticated from our login page to the various applications. I would also need to pass the user id. Currently we pass an encrypted userid to each application once they sign on. Is there an easier way to do this through forms authentication? The applications are "Applications" in IIS and run under different app pools so I haven't found anyway of passing Sessions between the Membership and the applications.
IIS 7.5 Structure:
-Sites
-Website
-Membership
-Application 1
-Application 2
-Application 3
There is no way to directly pass a session between applications in separate pools. You'd have to build a transfer mechanism.
If these are internal applications and you have a Windows domain, the simplest way is to use Windows Authentication and avoid the problem altogether.
Barring that, you may want to look at the Enabling Single Sign-on Using ASP.NET article on MSDN.
Related
I am aware of ASP.NET Authentication using Identity. So, if my application already has Authentication enabled, why would I want to enable IIS authentication on top of that?
Also, if I have both enabled, will that require a user to type in his or her credentials twice (once for the application login and then for the IIS login)?
Both are different things altogether.
ASP.NET Authentication using Identity in your web application is used for authentication & authorization of End-User in your application.
IIS authentication is for security and access management for hosted application.
If we explore a little further why this is needed. End-user just need to rights for viewing data & doing operations using User Interface Screen.
IIS user(used for IIS autehntication) might need right for creating schema, modifying schema as in Continuous Integration (CI) when you deploy code, new schema is created or existing schema can be modified.
Also in multi-tiered application, we can choose to run service(web services, web API, WCF
etc) under end-user authentication if needed OR user with more rights is required.
All decisions depends on your architecture, needs & security requirements. No choice is good for all architecture needs. We need to choose what suits our requirement best in given scenario and we design in such way application is further extensible/scalable for higher loads and easier for maintaining code too in long support.
I currently have an MVC 5 App which uses Windows authentication, from the intranet template. I would like to now expose this to internet users and utilize oauth. It seems that many of the files in oauth walkthroughs are missing from my project. Is there a nuget package I can use to refill the missing files that would have been in the "Individual Users" template, or do I really need to create a new project as OAuth and back fill Windows auth into it?
You can't really simultaneously use both Windows Auth and Forms Auth (Individual User Accounts), with or without OAuth. There's hacky ways to invalidate what I just said, but they're just that: hacky. Really, the only real approach is go Forms Auth and then connect to LDAP manually to sort of proxy authentication from the domain to Forms Auth (basically, you'd have to create a local user account that represents a domain account).
Really, if you need to use simultaneous different forms of auth, the safest and easiest bet is to use separate projects and just share as much of the code as you can, with class libraries, Razor Generator for compiling views, etc. You'd of course have to host each project separately, but you could simply use a subdomain (i.e. internal.mysite.com vs www.mysite.com), or if you got your own network DNS server, you can even map internal requests vs external requests to the two different sites using the same domain.
I have an older ASP.NET (.NET 1.0) web application that is using Windows authentication. We want to remove the Windows authentication since the AD server for this particular web application needs to be decommission. We want to keep some type of authentication for this older web-application. I am thinking this leaves us with Forms and Passport authentication modes (but not sure of support in a .NET 1.0). I am trying to avoid a major rewrite since the web-application is not being used much anymore (only being used by one user). Any idea of a quick and simple solution to remove Windows authentication to something else for authentication?
If the domain controller is to be decommissioned I take it the entire office will reverted back to a domain-less workgroup environment. I also take it all workstations will be configured to leave the domain prior to destroying the domain controller once and for all.
Since it's only down to one user for a web application that has little value in enhancement, you may be able to get away by creating the very same user account with the same password on the web server. That way when s/he accesses the web app on that server, the Windows authentication mechanism will attempt to negotiate as SERVER\username in the local SAM store instead of relying on the previous DOMAIN\username account.
Currently, we have many web applications (external & internal) developed using Classic ASP through .NET 2.0 technologies. Each of those web applications have their own login screen authenticating against their own custom database or using Windows authentication. Users have access to one or more of these applications, meaning they have to log out and log back into applications that they would like to access. All applications share some part of the back-end data sources. Also, the business logic is embedded in the UI in addition to being duplicated across applications because there is no code/business logic sharing. Screenshot #1 gives a brief idea of the existing architecture.
Screenshot #2 shows the suggested architecture, which I hope will help in faster development, code/business re-usability and may be simpler maintenance. Users will access either external or internal url. In external, users will provide credentials and will be authenticated against custom database. In internal site, users will be automatically logged in using Windows authentication. After creating some samples, I have begun to like ASP.NET MVC 3. It keeps business logic separate from UI and I also like the unit testing capabilities.
Here are my questions:
Based on what I have found on the web so far, multiple authentications are not feasible within a single website. My understanding is that I have to host one website for each type of authentication (Forms and Windows). How do I redirect users to common landing page after they are authenticated so they can see the modules (links/menus) that they are authorized to access? Should I have to publish the same code set (dlls and content) to both the websites?
Has anyone faced a similar architecture problem? If yes, could you please share the challenges that you faced and how you tackled them? What are the industry standards in designing applications of this sort?
Does the suggested architecture make any sense or is it a really bad design? Are there any drawbacks in doing this in ASP.NET MVC 3?
I would really appreciate your inputs.
Thanks in advance.
I would set up a seperate web site which only handles the windows authentication. I would then rely on something like OpenID and/or OAuth to ask for credentials/token to make sure to user has proper access.
The user that want to sign in using windows credentials go through that process because you are right in that a IIS server running windows authentication is hard to mix with other stuff.
You can set up some kind of claim based network of thrust in which you applications get thier credentials from trusted sources and through that process you can negotiate and control access privileges cross many web sites. As long as your not doing custom hosting or white label branding you can have everything in one place (or even if you did you could design it so that you have a central solution of handing out authentication tokens).
Keep in mind the difference between Authentication and Authorization. You presumably want a single authentication mechanism (or maybe two, one for internal and one for external users). There is a similar post here that lays out some pretty good guidelines: How to allow multiple authentication methods in ASP.NET?
On one project we built a common controller class used in every page of the site. It handled authentication and access control. When a user tried to access any page it checked to see if they had a session identification cookie. If they did not they were required to authenticate(login). A challenge was doing a good implementation of the security. Current browsers have many flaws that make this difficult.
Mine is a web product (delivered to a browser), being built on ASP.Net (Framework 4.0).
Most customers seek Single Sign On, such that their users should directly logon to the application on its invocation with the Windows or Active Directory login, they're using. Some other customers want the application to accept form based login credentials. So basically my web application should be able to adjust (configured) based on the customer's requirement. Their may be claims based authentication is some stray cases as well. I'd like to know the best way to achieve this in ASP.Net.
.NET open auth is your friend.
http://www.dotnetopenauth.net/
Then, there's active directory/LDAP:
http://www.codeproject.com/KB/system/everythingInAD.aspx#35
And your own provider + WinForms should be clear.