Port Facebook middleware from Katana.

[Tratcher]

Depends on aspnet/HttpAbstractions#113
TODO: CoreCLR WinHttpHandler does not yet support custom server cert validation.

[davidfowl]

When did this happen?

[Tratcher]

In this PR. This data used to be stored in IAppBuilder.Properties, but everything there moved to services.

[lodejard]

We need IBuilder.Properties... I'll file an issue to discuss that in http abstractions

[lodejard]

See aspnet/HttpAbstractions#116

[Tratcher]

@loudej @davidfowl Can we try to get this reviewed today so it doesn't just sit here next week while I'm OOF?

[davidfowl]

Can you point out major differences from the katana middleware?

[Tratcher]

The primary differences are in FacebookAuthenticationMiddleware

• Constructed with DI
• ResolveHttpMessageHandler uses WinHttpHandler on CoreClr. Doesn't support custom server cert validation yet.

Misc:

• SetDefaultSignInAsAuthenticationType & IDefaultSignInAsAuthenticationType
• Renamed Options.Provider to Notifications, same as we already did for the cookie middleware.
• Uses Microsoft.AspNet.WebUtilities for shared helper APIs. See Add form and query helpers needed for Facebook auth. HttpAbstractions#113.

[Praburaj]

Some of the katana middlewares expose something like OpenIdAuthenticationDefaults.AuthenticationType, WsFederationdefaults.Authentication type. Do we plan to consolidate it now in vnext? In other words do we want a FacebookAuthenticationDefaults.AuthenticationType?

[Tratcher]

Updated

[lodejard]

I wonder - with the vNext IOptionsAccessor<TOptions> would we change how that last object could be passed in? Don't need to change in this PR, but something to consider

[lodejard]

[Tratcher]

Updated to use IBuilder.Properties.