目前,我们有许多使用经典ASP通过.NET 2.0技术开发的Web应用程序(外部和内部).每个Web应用程序都有自己的登录屏幕,针对自己的自定义数据库或使用
Windows身份验证进行身份验证.用户可以访问一个或多个这些应用程序,这意味着他们必须注销并重新登录到他们想要访问的应用程序.所有应用程序都共享后端数据源的一部分.此外,业务逻辑嵌入在UI中,而不是跨应用程序复制,因为没有代码/业务逻辑共享.截图#1简要介绍了现有架构.
截图#2显示了建议的架构,我希望这将有助于更快的开发,代码/业务可重用性,并可能更简单的维护.用户将访问外部或内部URL.在外部,用户将提供凭据,并根据自定义数据库进行身份验证.在内部站点,用户将使用Windows身份验证自动登录.创建一些样本后,我开始喜欢ASP.NET MVC 3.它使业务逻辑与UI分离,我也喜欢单元测试功能.
这是我的问题：
>根据我目前在网络上发现的内容,多个身份验证在单个网站中是不可行的.我的理解是,我必须为每种类型的身份验证(窗体和Windows)托管一个网站.认证后,如何将用户重定向到通用目标网页,以便他们可以看到他们有权访问的模块(链接/菜单)？我是否必须在两个网站上发布相同的代码集(dll和内容)？
>有没有人遇到类似的架构问题？如果是的话,请分享你面临的挑战以及如何应对挑战？设计这种应用程序的行业标准是什么？
>建议的建筑是否有意义或者是一个非常糟糕的设计？在ASP.NET MVC 3中这样做有什么缺点吗？
我非常感谢你的投入.
提前致谢.
解决方法
我将设置一个单独的网站,只处理Windows身份验证.然后,我会依靠OpenID和/或OAuth等来查询凭据/令牌,以确保用户具有正确的访问权限.
想要使用Windows凭据登录的用户通过该过程,因为您正在运行Windows身份验证的IIS服务器难以与其他内容混合使用.
您可以设置某种基于声明的推力网络,您可以在其中从受信任的来源获取凭据,通过该过程,您可以通过许多网站协商和控制访问权限.只要您不做自定义托管或白标标签,您就可以将所有内容都放在一个地方(或者即使您可以设计它,以便您拥有发出认证令牌的中心解决方案).
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
