AzureAD should be a first class citizen

[mbeckenbach]

An azure ad middleware (that supports also multi tenant or mixed mode with local users) should be as important as the facebook login.

.Net is still mostly used in enterprise. Enterprises need something made for enterprises. not facebook.

Please extend your development, documentation and support for your own authorization technologies. On MyGet there are already vnext packages for google, facebook and co. but nothing for windows auth or azure ad. Even on "vLast" azure ad via oauth / open id is not really good documented or implemented until today.

[blowdart]

Windows Auth and WS-Fed are generally complete identity providers. They don't get used as secondary providers to Identity. Forms auth had a half hearted attempt to make AD work with forms login, but it still didn't hook into a membership database.

Mixing auth modes is dangerous and something we strongly discourage and always have.

Whilst this is on the backlog for now I remain unconvinced this is anywhere we want to take asp.net identity as we expect you to choose the Organizational Account option when you create a new project in Visual Studio not shoehorn it into an non-enterprise identity package.

[brockallen]

Well, in a sense some of the middleware already does favor Azure. What might be nice is an inheritance structure where base class middleware doe the raw protocol (and hopefully the full protocol) and then derived/extended middleware adds in or is tailored for the azure specific bits.

My $0.02, fwiw

[mbeckenbach]

@blowdart Mixing Authentication modes is exactly whats done when having local users and social logins. Don't see any security impact as Long as AAD is implemented in an oAuth way.

In Business Apps there is a real demand for having AAD for company employees and local users for Customers.

For (real simple) multi tenant scenarios there should also be a posibility to use multiple AADs and also local users. This can already be done with the current openID katana middleware.

[blowdart]

I don't agree. Social logins have been adding additional metadata and an alternate login, security decisions were not made on the metadata or the login as it mapped back to a "forms" identity.

Now if you wanted to ignore the benefits, the roles and claims that AAD provides then sure, add it via OpenID but that's not where we would take AAD in my opinion, and that's not what you're illustrating when you say you want to use the login type as a way to differentiate between employees and customers - that most certain is mixing authentication types and it's a security nightmare that identity will not address because, put simply, that's not identity's target market.

The folks that tend to want to combine Windows Auth with Forms with WS Fed have non-generic requirements and are also well aware we don't support it or recommend it and are happy rolling their own approaches.

[mbeckenbach]

I totally get your point. In application where strong security matters, that's absolutely correct. Thats where one should not use openID.

But there are also a lot of scenarios where you really don't need all the claims and roles. And not every app has to be fort nox.

In a huge base of small apps the only thing customers want is not to remember another password for employees.

Don't get me wrong. I'm not talking about recommending mixed auth for everyone.

I'm talking about making it possible / easier to go that way if there is no need for a big solution.

What's better for Microsoft? Giving devs a possibility to create a solid and supported proven mixed auth or having lots of custom implementations with security issues everywhere?

Don't want to talk for other devs. But i don't think i can build a solid and secure mixed auth scenario within one or two days. This is what your budget looks like in small projects.

So i would like to rely on that one small nuget package from MS and satisfy my customer.

[blowdart]

The problem here is people have an expectation that we deliver secure code. That takes time and resources and neither of those are limitless. I won't ship anything I feel isn't secure by default nor anything that could lead people into a pit of security failure, and mixed authentication types is just that.

Right now we neither have the time nor resources to even begin to approach this securely.

[blowdart]

@brockallen There's finally some oauth base classes that everything inherits from, @Tratcher did a lot of work around that.

[Tratcher]

This issue was moved to aspnet/Security#102

[blowdart]

Reopening so the non-middleware discussion can keep going in the right place grin

[guardrex]

@blowdart I'm just arriving to the issue. https://github.com/AzureADSamples/WebApp-WebAPI-OpenIdConnect-AspNet5/tree/master/TodoListWebApp is broken for dnxcore50 ... it's so old it actually names aspnetcore50, so it's not surprising it doesn't work. https://github.com/r2musings/AzureADTest/tree/master/src/AzureADTest2 works, but only for dnx451 ... I couldn't get a dnxcore50 version working. Do you know of any dnxcore50 sample that will handle a vanilla AAD Identity authentication? ... or is the middleware just plain broken right now for Core CLR?

[Eilon]

We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have.