从我有过专业经验的一些系统中,我在这里提供一个答案:
注意:如果您回答我在评论中提出的关于应用程序参数的问题,我可以进一步定义正/负面。
ASP.NET Identity
这是一个基本的MS用户系统,它使用用户名和密码,并随MVC框架一起发货。其中一个优点是,该概念已经存在了很长时间,并且有大量的教程向您展示如何扩展它以使用诸如电子邮件/密码之类的东西,或者从用户那里收集某些数据,例如他们母亲的狗的中间名或其他任何信息。如果您有一个用户可能共享计算机的环境,请在此处查看。考虑工厂或医院设置等情况。其中一个缺点是,您基本上被迫在应用程序(或应用程序群集)中维护整个用户设置、应用程序角色和用户管理。当涉及到此时,请考虑表单身份验证。如果您的应用程序是外部的,并且暴露AD服务使您的安全团队感到不安,则可能需要查看此内容。
Windows Auth.
您基本上正在对Windows用户帐户进行身份验证,虽然不是必需的,但在大多数情况下,您将把像Active Directory这样的东西视为角色提供程序。其中一个优点是,您的应用程序实际上不再负责用户管理和所有相关支持(weeeeee!),而是更多地授权角色在应用程序中工作。这使得它变得轻松,但一个巨大的缺点是,如果您有可能共享计算机的用户,则这是一个巨大的安全噩梦。您需要定位拥有自己特定计算机的用户,他们来上班并坐在这个计算机旁边。如果您的应用程序在外部托管,则会变成一场噩梦,因为有些服务需要从外部访问AD,这样很容易使AD变得脆弱。
Forms/Windows混合模型
在这种情况下,您基本上需要配置您的网站以运行forms auth,但是您的forms auth系统设置为作为后台进程对AD中的用户进行身份验证。因此,当您有一些共享计算机和一些专用计算机的用户混合使用时,这更适用。您基本上正在设置自己的forms auth网站,该网站除了用户的AD名称和密码外,还接受重定向URL。然后,forms auth网站检查Active Directory中的用户凭据是否有效,设置诸如会话cookie之类的有趣内容,并将经过身份验证的用户重定向回您的MVC网站。在您的MVC网站上,您也有AD连接器(或者您可以具有N层设计来查找它),以告诉您用户隶属于哪些AD组并适当处理。因此,使用此类系统的优点是,您将单个网站的用户管理方面放回到AD中,但同时具有启动基本上为Windows Auth的应用程序的灵活性,以在具有混合用户(具有专用计算机和那些分享计算机的人)的环境中运行。其中的缺点是,初始第一次设置非常繁琐,因为您实质上正在构建多个系统。此外,安全性也是一个问题,因为任何时候您都有共享计算机环境,事情更容易受到滥用。您必须提出良好的会话超时策略,并遵循该策略。此外,您可以将您的forms与站点放置在DMZ中,并将外部托管的应用程序与直接与AD交互分开。其中一个缺点是,您需要处理AD锁定,密码重置,暴力破解等问题。
像OAuth这样的外部提供商,如Facebook,Twitter,Google。
我从未亲自在生产应用程序上走过这条路,因此无法为您提供现实世界的正面或负面意见,但需要提及并且可能其他人可以给我们一些见解。
对于这个回答中的大文本块表示抱歉,当我可以进入桌面时,将使格式更加“漂亮”。