We Keep Coding

Secure web application without login/authentication module

I have an web application that only is uses intern by employees. Is there a alternative to secure access to this web application without implement login/authentication module? I was thinking about a query parameter key, but it seems ugly.

You can use auth0 Passwordless. Auth0 purpose a web kit.
According to the documentation : Passwordless connections allow users to log in without the need to remember a password. Instead, users enter their mobile phone number or email address and receive a one-time code or link, which they can then use to log in.

IdentityServer3 + Active Directory + Self-Hosted User db

I'm trying to find a solution to handle authentication on my new application, and I like the approach of IdentityServer3. I would like to hope my requirements are met by IdentityServer3 and it's just my lack of understanding due to my newness with the technology.
My requirements are as follows, and in order of desired execution:
1) If a user requesting authentication is a local (domain) user, they should be authenticated automatically using Active Directory.
2) If a user requesting authentication is not found in Active Directory, they should be authenticated against our own User table.
3) If a user requesting authentication is in neither Authority, we may choose to grant access via Google or Facebook credentials, but that's not a Phase I requirement.
I currently have a working proof of concept using IdentityServer3 as a standalone security server pulling records from the InMemoryUsers, InMemoryClients and InMemoryScopes, and I'm fairly sure I'll be able to expand on those concepts for pulling from our own database.
This problem comes when I try to use Active Directory as the first checkpoint.
I've looked at a couple of resources in an effort to accomplish the Active Directory, but I'm getting all tripped up as I'm not seeing any concise demo that shows the AD piece of the puzzle.
TJ Robinson has a Gist of an ActiveDirectoryUserService that implements IUserService, and that looks to be the most promising, but because of my n00b status, I can't seem to figure out how to roll it into the scheme.
I would really appreciate any suggestions, and, perhaps, links to examples of how to do AD authentication first with a fallback to local authentication.
Thanks in advance,
Ric

In regard to your first requirement...
I believe you should examine the Windows Authentication Service. This is essentially a mini security-token-service that can work as an external identity provider to IdentityServer to provide Windows Authentication (over the WS-Fed protocol).
If you follow that link to the GitHub page, you will find two links to samples that can you get started with this component. One sample has both Identity Server and the Windows Authentication Service hosted separately and the other sample has them hosted together.
A separate option could be to use ADFS (if you have one) as an external identity provider.
Those samples include a custom user service (ExternalRegistrationUserService) that shows those windows users being mapped to an in-memory collection of users (in Identity Server). Your requirements will obviously demand a different implementation of that user service, but I hope this might help get your started with the Windows Auth part.
When I went through this exercise recently, I found a lot of good information in the closed IdentityServer3 issues (for windows auth). Lots of good info on Stack Overflow as well; good luck!

Single sign on with ADFS

I am looking for single sign on for my application which is built on javascript (no server side language).
Requirement:
Agent log in to Windows (user integrated to Active directory)
Open my web page
Based on who logged in to windows, my application goes to AD and pull some user
specify data (eg email, phone)
How shall I go about it?
As per my understanding I will require ADFS for this.
So:
User goes to my web page
My web page calls some Web services or web application (which is build on c#)
That will authenticate against AD FS and get claim
Either get phone number and email in claim or get username and query AD for phone and email
Return the data to my web page (build on javascript)
It seems there something wrong in my understanding!!
Please suggest more appropriate solution based on my requirement

Frankly, I can't think of a way to make it work without a server side processing. This is because the ws-federation protocol ADFS uses is not just about returning claims.
It is about returing a SAML token. The token contains claims but what is most important about it is that it is signed using the XMLDsig. How are you going to validate the token is a first big question. But there are surely external libraries that allow that.
But then, such authentication can easily be bypassed by modifying scripts in the browser. This is because the ws-federation stops where you get the token and then it is up to you to exchange the token for the actual identity. And this won't work when processed only at the client side.

ADFS 3 does not support the OAuth2 implicit profile, which would be an option, but still you would need to verify the token on the server to avoid session fixation.
You can setup something like AuthorizationServer that supports Oauth2/OpenID Connect implicit profile
http://leastprivilege.com/2013/09/19/adding-oauth2-to-adfs-and-thus-bridging-the-gap-between-modern-applications-and-enterprise-back-ends/
Another option is to use something like Auth0 (Disclaimer: I work for Auth0) which also supports OAuth2/OpenID Connect implciit profile. In that case you wouldn't need ADFS, there is a connector/agent that you install on your network that does not require opening firewalls or anything and it supports implicit profile that is suited to JavaScript apps. This is an example of a single page app tutorial (if you create an account it will tailor the doc with your credentials):
https://docs.auth0.com/singlepageapp-tutorial

Options for single sign-on between ASP.NET and MVC.NET solutions?

I have an ASP.NET solution that acts as the primary customer portal for my customers. On this website the users can log-in access their important financial information and more. The website uses a custom authentication scheme that checks the user's username (their email) and their password (salt-hashed) against a Users table in a local database.
I am building a new MVC.NET solution that is more of a web-app tool to be used by these same customers for ordering. I want to re-use the sign-on mechanism of the ASP.NET portal to authenticate users. The goal is to save the user from remembering two log-ins or even having to supply the same log-in twice.
What are my options for allowing users who sign on to the ASP.NET solution to then be auto authenticated to the MVC.NET solution? I've listed some ideas below but are these "bad" or is there a more elegant solution? I'd love your input.
Common Cookie I could create a common cookie that the ASP.NET site creates and the MVC.NET site looks for. But is that secure enough?
Token in Query String I could create a token id on the ASP.NET site that is stored in the local database and is then passed in the query string of the link to the MVC.NET site which takes the token id and validates it against the same database.
Hybrid A bit of both?
Other? Got a better idea?

I've recently done something quite similar (the major difference being that it was internal to the company rather than for external customers) using OpenId.
The implementation of OpenId for .NET is called DotNetOpenAuth which should be suitable for your purposes.
It did take me a while to implement; but it works very well, is very flexible, and extremely secure.
More information about openid (from Wikipedia):
OpenID is an open standard that allows users to be authenticated by certain co-operating sites (known as Relying Parties or RP) using a third party service, eliminating the need for webmasters to provide their own ad hoc systems and allowing users to consolidate their digital identities.
Users may create accounts with their preferred OpenID identity providers, and then use those accounts as the basis for signing on to any website which accepts OpenID authentication. The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the "relying party").2 An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).
The OpenID protocol does not rely on a central authority to authenticate a user's identity. Moreover, neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common (such as passwords) to the novel (such as smart cards or biometrics).
Oh, and if you'd like further encouragement, Stack Exchange uses it!
#Jmrnet: in response to your last comment:
Perhaps I was unclear. OpenId in and of itself is simply for validating credentials from one location to another (more or less). It's entirely possible to implement as an SSO model where users do nothing different whatsoever - they don't have to choose a provider, or register, or anything like that. For example, in my setup, the user enters a username and password in a web portal, and then clicks a button to launch another site being automatically logged in by OpenId. Nothing different for the user at all! OpenId can be used with any initial authentication model you can think of (note the bolded section in the snippet from wikipedia).

Take a look at SAML:
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
It works using XML and supports encryption.

I am currently implementing two SSO solutions for the same project.
In one, we are interfacing with an external partner and are using SAML.
In the other, we are allowing logged in users access to our Sharepoint and using the "Token in Query String" approach, since we trust Sharepoint to access our membership tables. This approach is much easier than dealing with SAML tokens.

There are many methods you can use, Mansfied described OpenID and RandomUs1r described SAML. Also, you can store relevant information in localStorage or in the session. I believe you should store relevant information with session.
It is not safe to put this in the query string, because if I register and log in, I will see something like UserID=1234 in the URL. If I change that to UserID=1235 and the ID is existent, then I can do some things in the name of the other user. This is called identity theft, which should be prevented by any means possible. So you should never have this kind of info in your URLs. Also, if you store the id of the user, you should obfuscate it somehow. For instance if you store the value in local storage and instead of 1234 you store encrypt(1234, salt), then the consistency of user action will be maintained.

Single sign on for .NET application integrated with Active Directory

We have several customer using our web application (not intranet), some customers want their login should be integrated with their organizations Active Directory.
They just want that user should login to their windows account and can access the web application without entering any user credentials.
I have read some articles regarding ADFS, but still not sure how to integrate that or implement it.
Any proposed solution ?
Thanks!

If you develop a .NET based application, Microsoft provides a library called WIF, which is used to communicate with the AD FS in a +- comfortable way (configuration + little code adaptations to get the claims from the authentication message provided by the AD FS).
There are few protocols that both AD FS 2.0 and WIF support, to make the SSO work, the most common ones are (afaik) SAML 2.0 and WS-Federation. Both are built on XML messages, but you are not required to know the details, if you use WIF.
For WS - Federation, the WIF library provides a plugin for Visual Studio, which allows you to configure your site as the relying party with your AD FS.
You CAN use the credentials within your DB to identify users, you can actually customize AD FS's entire login page and authentication events. However the basic installation requires each user to be defined within your Active Directory. You can also use your DB as a claims store (another data base AD FS will use to provide the relying applications with information about users). Note that if you intend to use an AD behind the AD FS, your AD FS service must be able to access it and LDAP query it, which I'm not sure will work for you, if your users login to their local domain that the AD FS is not familiar with.
IF you are not required to support industry SSO standard protocols (SAML 2.0 I've mentioned), I'm not sure implementing AD FS will be such a good solution. It forces you to work in a certain way, which is not always that comfortable.

Your question doesn't explicitly state that whether you are limited to using ADFS for implementing SSO. ADFS is certainly one way of doing this. You may want to look at OpenID-LDAP (was at www.openid-ldap.org, but project is now defunct) and other identity providers as alternatives for implementing SSO.
One alternative is to implement an OpenID provider that uses integrated windows authentication. They can install it in their DMZ exposing that to the internet, instead of ADFS. It may allow single sign on from Internet Explorer and Chrome.
Implementing an OpenID provider is a non trivial matter. You'll have to pay close attention to security. Fortunally, there are a number of frameworks like DotNetOpenAuth that may help you.
When using OpenID, your "cloud" application will act as an OpenID rely and get a claimed identifier amongst other attributes from the OpenID provider. You should store this in your database to uniquely identify the user. You may choose to implement the OpenID provider such that it can also provide your cloud application with the minimal information like email address, the person's name etc.
The benefit of using OpenID is that your "cloud" application can continue to support other well known OpenID providers like Google and Yahoo without much change.
In the end you'll need to ask your customers what technologies they are comfortable with. You'll find that a lack of trust (a business trait) between organizations is more often than not the challenge rather than technology.

More detail needed as per comments.
There's a good source here: AD FS 2.0 Content Map.
The "e-book" is here.
I could imagine one scenario where you bind your cloud application to Azure ACS, your customers install ADFS on top of their AD and federate their ADFS with ACS. That would give you the functionality you require.
Update after comment:
ADFS can only authenticate against AD. It cannot authenticate against a DB. It can get attributes from a SQL Server DB which it can then transform to claims i.e. it can use a SQL DB for authorisation.
If you want to authenticate against a SQL DB, you can two choices.
Create a custom STS
Use an existing "custom" STS like Identity Server which allows this functionality.