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.

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

Is there a way to get the email address associated with a Windows Live ID?

I have a client that wants to use Windows Live ID Delegated Authentication SDK 1.2 to provide authentication for their website.
The architecture that they proposed was to have a database table that contained the email addresses of users who were authorized to use the site. Once the user logged using Windows Live ID web authentication, they wanted to compare the email address associated with that live ID to the table and allow/disallow the user access to the site based on that.
Is this possible? I can't find any documentation that talks about how to get the email address associated with the Windows Live ID.

I was originally looking for the way to do this with the Rest API, but it doesn't seem to work.
Using "wl.basics, wl.emails" solved the problem, albeit I don't have a fallback for when javascript is disabled.
Example from Rup:
http://isdk.dev.live.com/ISDK.aspx?category=Core+Concepts&index=1

What's the difference: Windows Authentication, Passport Authentication and Form Authentication?

Just going to start making a web application and was wondering which was better, or at least what are the main differences between them (as it probably matters what I am using them for)?
Windows Authentication
Passport Authentication
Form Authentication

I would say it greatly depends on what your web app will be doing, as each one has its place. Here is some brief details about each one.
Windows authentication enables you to identify users without creating a custom page.
Credentials are stored in the Web server s local user database or an Active Directory domain. Once identified you can use the user s credentials to gain access to resources that are protected by Windows authorization.
Forms authentication enables you to identify users with a custom database such as an ASP.NET membership database. Alternatively you can implement your own custom database. Once authenticated
you can reference the roles the user is in to restrict access to portions of your Web site.
Passport authentication relies on a centralized service provided by Microsoft. Passport authentication identifies a user with using his or her e-mail address and a password and a single Passport account can be used with many different Web sites.
Passport authentication is primarily used for public Web sites with thousands of users.
Anonymous authentication does not require the user to provide credentials.
http://msdn.microsoft.com/en-us/library/eeyk640h.aspx - ASP.NET Authentication further details on forms and window authentication
Edit
Rushyo link is better: http://msdn.microsoft.com/en-us/library/ee817643.aspx

Situation as when you can use what :
Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.

This should cover everything you're looking for (and more):
http://msdn.microsoft.com/en-us/library/ee817643.aspx
[Snap - I was totally going to use that exact same quote as well ;)]

Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.

Single sign on with ASP.Net Web Application

Client requires major applications to provide users with “single sign on” authentication feature based on the corporate solution (Active Directory).
This means the business application trusts the credentials provided by the browser and does not request user to provide standard login/password pair. The server/browser trust is built on Windows Integrated Authentication mechanism.
Ours is an ASP.Net Web application on dot net framework 2.0 hosted on IIS 5.We need to implement the SSO feature.How do we do it?

I'm pretty sure this is the same requirements that almost all intranet apps follow.
If you just enabled Windows Integrated Logins in IIS, then you'll be set for the #1 item.
I don't know if #2 is even possible, because it conflicts with your other requirement. The browser only passes the locally logged in user's credentials (as required by #1). If you built a web form to authenticate via AD, then you would be in violation of the requirements listed in your narrative/paragraph.
What do your clients think #2 really means? What do they want here? A way to log in as a different user? They can just log off the computer and log in as the other user.

In general, SSO requirements are best addressed by Claims-based protocols such as WS-Federation or SAML 2.0. In principle, you can implement these protocols yourself since they are open standards, but it requires a lot of specialist knowledge.
The new Windows Identity Foundation (formerly known as Geneva framework) contains protocol implementations that can enable SSO scenarios, although it will require you to upgrade your platform.

Use Custom Forms Auth instead that wont ask user to enter ID and password.
Prerequisites:
1> Database table having user details such as email, role etc
2> Enterprise active directory where user profiles are stored
3> Write a VBCOM or ActiveX or other components that can read user's domain and name from the windows machine through browser.
Steps:
On pageload for all the forms call the component<3> to connect to Active Directory<2>. That method should read current user's name, domain from windows system.
Search AD with these details. If exists then query and extract the email address or whichever is the unique key in the AD user profile.
Using this key query the database<1> where you stored application specific user details such as email, roles.
If user email from AD match with email in Table then grant the user appropriate rights else deny access if user does not exist or role is null/restricted.
If valid user then create a cookie that is encrypted and can be read by other applications to really implement any sort of SSO.