My organisation has several web facing ASP.NET Web Forms Apps. They currently use Windows Authentication with impersonation enabled. The web apps are hosted internally but are exposed publicly via different domains e.g. www.abc.com & www.xyz.org.
A new requirement, is that a single log on page will be provided for all users of these apps to log in via.
Some of the solutions proposed are:
Implement an OpenId Provider backed by Active Directory (DotNetOpenAuth), modify existing apps to become relying parties of this OP.
Implement SSO through MS Forefront Threat Management Gateway.
I don't have experience with either of these. Are the proposed solutions feasible? What are the pros and cons of each? Are there other solutions that might be more appropriate?
OpenId Provider is a fairly good idea. It will be an easier route and there are some good details around the web.
You may also want to look into Active Directory Federation Services.
http://msdn.microsoft.com/en-us/library/bb897402.aspx
It is not uncommon for businesses moving to hosted solutions look to implement federated services and this is something Microsoft anticipated when setting up and creating Azure - to be corporate friendly.
They have put together a comprehensive guide here, which while not directly related to your question, does have extensive details about the technology behind federated services.
http://msdn.microsoft.com/en-us/library/windowsazure/hh127796.aspx
For more thoughts and information on, specifically the pros and cons, take a look at these articles which answer it in more depth:
http://technet.microsoft.com/en-us/magazine/ff721824.aspx
http://windowsitpro.com/active-directory/ease-cloud-security-concerns-federated-identity
http://www.csoonline.com/article/221034/the-truth-about-federated-identity-management
Some DotNetOpenAuth thoughts:
http://www.codeproject.com/Articles/325228/Choosing-technologies-for-NET-project
http://social.msdn.microsoft.com/Forums/en-US/windowsazuresecurity/thread/7a1c4e0c-346c-4008-9e5c-87ba1273b2aa/
Finally, we have personally gone with OpenAuth for one of my teams solutions. The implementation was fairly painless once we took time to really understand the RFCs (which was no easy feet, but worth taking the time to do). There are also a ton of resources on the web to get a hang of the implementation.
Related
Haven't done security in ASP.NET before. Need to secure an MVC site - simple username/password access for admin access to the site's logs and admin areas, not for general users.
Looked into Identity/OWIN, and it is, as of this writing, half-baked. There are multiple ways to do things, the docs are few or non-existent, and blogs dicuss deprecated or alpha versions. The samples don't correspond to anything in the docs or blogs. In short, it's a mess.
Security is hard, so I want to use something that was written by an expert, works and is tried-and-tested. Must be from Microsoft, not some third-party stuff.
So what security API came before Identity/OWIN, which works well and hasn't been compromised? They've released many, so I don't know which to use?
Forms Authentication with custom Membership and Role Providers were used for years and still can be used. The SimpleMembership is something that tries to simplify the original provider model but sacrifices too much, in my opinion plus it us still not that simple.
There are thousands of tutorials on Forms Authentication and you should be able to start immediately. The Membership/Role Provider model is also extremely well documented.
In terms of correspondence
Membership/Role Providers correspond to the Identity api
Forms Authentication corresponds to the owin security api
The predecessor to Identity/OWIN was SimpleMembership.
However, according to my question "What is MVC4 security all about?", SimpleMembership is an oxymoron.
I want to know the difference between multi-tenancy and single tenancy.
Is tomcat supporting mutli-tenancy .Can you explain both with an example.
I am asking this question in context to http-servers.
Definition
From Wiki definition
In a multitenancy environment, multiple customers share the same application, running on the same operating system, on the same hardware, with the same data-storage mechanism. The distinction between the customers is achieved during application design, thus customers do not share or see each other's data.
So you can imagine that single tenancy is the other way around.
Example
Let's take JIRA as an example,
If you use OnDemand JIRA Service, it is multi-tenant, cloud-based service.
If you download JIRA Standalone and install it for you organisation. It is single tenancy case.
Designing multi-tenancy software
Designing multi-tenancy software is nothing to do with the hosting technology. It's actually about the way you architect the software.
Tomcat in your case, is absolutely suitable for multi-tenancy software.
I'm the custodian of a pretty sophisticated, yet antiquated, ASP.NET application. It is essentially a platform that makes creating database applications easier - with tools to read in database schemas, auto generate forms, reports, charts, and provide extremely extensive tools to manipulate those things within the UI. There are some pretty big clients using the platform for some niche applications, and despite the age of much of the code (some of it written as early as 2001), everything runs pretty well.
The company is doing well enough that i need to start considering a new version, and rather than plastering on some new features, i'd like to consider a fresh start. The current solution is a ridiculous 150 projects - down from about 220 when i first started working on this full time.
Does anyone have any tips or suggestions for the general structure of an enterprise(ish) level application? What new technologies should i consider? Maybe some particular books or websites i should review?
I've got a good handle on all of the specifics that make our platform so flexible - but because i've been locked into the general structure of our code for so long, i feel like i'm way out of touch with how the entire thing needs to be structured on a large scale. The current application still has a bunch of .NET Remoting for communication with the databases (just a tad out of date), and a ton of incredibly inefficient code written by someone who wasn't really a programmer.
WCF to serve info from the data access layer? WIF to authenticate? I'd really like to be able to assemble an API that my business partners can use to connect to the data and use a huge collection of common functions i've got set up - ideally that API could run in a web context or in some other environment.
I know this is a pretty big question that could have a lot of possible answers - just looking for some thoughts on where to really spend our research time.
Thanks!
-RP
If you want to rid yourself of all the authentication / authorization hassles, absolutely go for claims-based applications, WIF, ADFS etc.
That's the Microsoft direction - CMS, SP. Office 365. Windows Azure AD etc. are all now claims-based.
Only problem is that ADFS authenticates against AD. Have a look at Identity Server for something DB related.
Plus ADFS via ACS provides Facebook, Google etc. logons.
HI guys,
We always in our projects implement our own custom login by coding (login, recover, change,...), ASP.NET already have it, but the team leader always ask for a custom login.
I need someone to clarify to me as he is not arguable.
thanks
Simple - time, money, security.
Why spend time and money redesigning, implementing, testing and maintaining as system for which there is already a tested and mature infrastructure that doesn't cost a dime and is very easy to customize?
And consider the scope of the problem domain. There are hundreds of very diverse classes required to capably implement a robust security system. Do you really want to expend the effort to produce a system that is as secure?. There are thousands of man hours , end user feedback, testing etc to support the improvement of the asp.net providers.
What do you want to do? Use a session cookie? ;-)
Do you have people in your company with a better skills and experience as Microsoft has?
Has your company better understanding of ASP.NET, .NET and authentication problems as Microsoft has?
Has your company more financial and people resources and Microsoft has for ASP.NET development?
If you really has a form of Single-Sign-On implemented in your company or another not a solution using proprietary way, then you should describe this in your question. ASP.NET and WCF has a lot of customization possibilities. For example look as http://msdn.microsoft.com/en-us/magazine/ee335705.aspx about Using Active Directory Federation Services 2.0 in Identity Solutions. Other identity solutions are also possible.
You should not invest your energy in inventing of wheel or bicycle. Just use existing invention.
What do large websites built in .NET use for their login components?
I will be implementing the login and membership features of a large .NET web application. As I see it, there are 4 options:
Leverage the default Microsoft Membership Provider
Build a custom Membership Provider
Use a different 3rd Party Component
Build an entirely custom login/authentication framework
I am trying to optimize for reliability, so I would like to know if sites like MySpace or PlentyOfFish have already established a best practice in this area. The real motivation for this question is I want to validate that the MS Membership Provider strategy will scale well.
I know StackOverflow uses OpenID, but I don't think that would be a good solution for what I am working on as a lot of my prospective users will be non-technical. Feel free to pitch why OpenID should be considered if you believe strongly in it.
Always rely as much as possible on platform-provided tools for security tasks such as authentication.
In this case, that likely means inheriting from one of the stock MembershipProviders. That will let you re-use all the existing code for the provider, plus any tweaks you need to make it work with your existing system. It's possible you can find a 3rd party component that works well for you that already does this.