Web应用程序-跨域的用户身份验证
我们的一位客户联系我们开发一个应用程序，和往常一样，范围日益扩大。
最初，它是作为一个仅限于公司网络内的专用应用程序开始的。 用户身份验证是通过获取用户的 Windows 登录名并使用 SQLServer 数据库来托管访问权限来建立的。 一切都很简单。
他们现在想要以下内容：
- 基于网络的应用程序
- 在公司网络外部托管的应用程序
- 用户身份验证以相同的方式工作（不使用密码，只需 Windows 登录）
更复杂的是，他们希望应用程序的各种功能可供另一个仅触发 HTTP 请求的应用程序使用。< br> - 用户登录公司网络
- 用户启动公司应用程序
- 用户处理客户详细信息
- 用户单击按钮
- 企业应用程序向我们托管的 Web 应用程序发出 HTTP 请求
- HTTP 请求包括必要的身份验证和客户详细信息
- 用户身份验证“自动”完成（无需人工参与）
- 客户数据安全传输
他们非常希望我们为他们做到这一点，因为我们最初的方法正是他们想要的。 尽管此类托管网络应用程序不是我们的专长，但他们仍然希望我们这样做。 所以我现在联系专家；
- 有人对如何解决这个问题有任何建议吗？
- 有人对可能要避免的陷阱有任何警告吗？
A client of ours has approached us to develop an application, and as usual the scope grows day by day.
Initially it started as a dedicated app confined within their corporate network. User Authentication was established by aquiring the user's Windows login and using a SQLServer Database to host the access rights. All quite straight forward.
They now want the following:
- Application to be Web Based
- Application to be hosted outside of the corporate network
- User authentication to work in the same way (no using passwords, just windows logins)
To complicate it further, they want the various functions of the application to to be usable by another application which just fires of HTTP requests.
- User logs in to corporate network
- User launches corporate application
- User processes customer details
- User clicks a button
- Corporate Application fires a HTTP request to our hosted web app
- HTTP request included necessary authentication and customer details
- User authentication is completed 'automatically' (No human involvement)
- Customer data is transmitted securely
They are very keen for us to do this for them as our initial approach was very much what they wanted. They still want us to do this even though such hosted web apps are not our speciallity. So I now approach the experts;
- Does anyone have any advice on how to approach this?
- Does anyone have any warning about the possible pitfalls to avoid?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
基本上他们谈论的是联合访问。 您将在其网络内托管一个身份验证点，该身份验证点又将令牌转发到您的应用程序，该应用程序解析它并允许（或停止访问）。 这是相当标准的，MS 在 Geneva Framework< 中为此提供了良好的基础/a>. 这也适用于 Web 服务调用，前提是他们可以更改其应用程序以使用 WSFed 作为协议并与安全令牌服务对话，安全令牌服务会默默地发出身份验证令牌。 在大多数情况下，您将为此使用 SAML。 它还具有额外的好处，即身份验证详细信息永远不会超出其公司网络。
基于证书的身份验证的建议很有趣，但在推出 PKI 基础设施方面需要做更多工作。 这可能代价高昂。
CardSpace 不起作用——它并不像他们想要的那样安静。 OpenID 也不是一个启动者，它也不是沉默的。
如果您正在查看 Azure，则需要额外加分 - Azure 的身份验证位也在底层使用 SAML/WSFed，并且其中包含一些Geneva。 因此，如果您迁移到云，那么您的每个客户只需在其网络中配置一个登录页面 - 您所要做的就是信任该页面向您颁发身份验证令牌并根据您的规则解析它们。
Basically they're talking about federated access. You would host an authentication point inside their network which in turn forwards a token to your application which parses it and allows (or stops access). This is pretty standard, and MS provide a good base for this in the Geneva Framework. This will also work for web service calls providing they can change their application to use WSFed as a protocol and talk to a security token service which silently issues the authentication token. In most cases you'll be using SAML for this. It also has the added bonus of authentication details never going outside of their corporate network.
The suggestion of Certificate Based authentication is an interesting one, but requires more work in rolling out a PKI infrastructure. This can be costly.
CardSpace won't work - it's not silent as they seem to want. OpenID is a non starter as well, it's not silent either.
Extra points if you're looking at Azure - the authentication bits of Azure also use SAML/WSFed under the hood, and has bits of Geneva in it. So if you moved to the cloud then each of your customers would just have to configure a login page within their network - all you would have to do is trust that page to issue authentication tokens to you and parse them according to your rules.
也许 WCF 通信具有基于证书的身份验证，即对于使用公司为他们提供的有效证书的服务的外部用户。 这样就不需要用户名密码，而是直接引导用户通过。
Maybe WCF Communciation with Certificate based Authentication i.e. to external users who use the service the company provides them with a valid certificate. This would then not require a username password but take the user straight through.
您是否已经看过 SAML ？
Did you already have a look at SAML?
查看 Windows CardSpace，因为它确实与您的 Windows 登录集成，并允许他们所需的 SSO 方案。
Check out Windows CardSpace since it does integrate with your windows login and allows for the SSO scenario they require.
根据应用程序的构建方式，您可以修改 web.config 中的 machineKey 以允许通过单点登录 (SSO) 进行 AJAX 调用。
这将涉及公司网络内的一个小型 asp.net 应用程序，只是为了发出身份验证令牌并重定向到您的托管应用程序。
如果两个应用程序共享相同的 machineKey，那么 ASP.NET 身份验证系统将很乐意允许用户进入您的托管应用程序。
这种方法存在问题：
Depending on how your app is constructed, you can fiddle with the machineKey in your web.config to allow for AJAX calls with single-sign-on (SSO).
This would involve an small asp.net app within the corporate network just to dish out authentication tokens and redirect to your hosted app.
If the two apps share the same machineKey then the asp.net authentication system will happily allow users into your hosted app.
There are problems with this approach:
我会为此使用私有 OpenID 提供商/服务器。
I'd use a private OpenID provider/server for this.