通过服务(或其他远程方式)的 FormsAuthentication.SetAuthCookie

发布于 2024-08-11 04:39:09 字数 765 浏览 4 评论 0原文

我们目前正在将部分 Intranet 应用程序迁移到 MojoPortal(一个开源 cms 应用程序)。 MP 默认使用 FormsAuth,我们已将其设置为针对当前的 Active Directory 存储进行身份验证。

话虽如此,我们希望用户能够自动从当前系统登录到新系统,以创造无缝体验。新系统(mojo)驻留在与当前系统不同的服务器上。两者都位于同一“company.com”域下,具有不同的子域。

Mojo,通过用户通过 mojo 界面登录时创建的 FormsAuthentication cookie 检查身份验证。我们正在寻求远程重新创建此功能。我意识到 FormsAuth 基于 MachineKey 并存在于单个 IIS Web 实例中,但我对社区可能有的任何想法感到好奇。

目前我们提出的“最佳”猜测是:

创建一个 WCF Web 服务,该服务位于 mojo 站点下的虚拟目录中,接受用户名/密码并创建 cookie。这未经测试,因为我们不确定这是否会真正影响客户。

将用户重定向到 mojo 下的中间页面,该页面接受用户名/密码并创建 cookie,然后再次将用户重定向到所需的 mojo 页面。

这确实使用 MojoPortal 作为提供程序,但真正的问题是如何远程创建 FormsAuthentication cookie。

其他背景信息:

当前系统已经针对同一 AD 存储进行身份验证,因此无需担心创建 cookie对于不存在的用户。两台服务器位于同一个 AD 域中(它们物理上彼此相邻)。当前系统的源代码可供我们使用,也可以进行修改。

We're currently migrating a portion of intranet apps to MojoPortal(an open source cms app). MP uses FormsAuth by default and we've set it to authenticate against our current Active Directory store.

All that being said, we are looking to automatically log in users from the current system to the new system to create a seamless experience. New system(mojo) residing on a different server than the current system. Both live under the same "company.com" domain, with different subdomains.

Mojo, checks authentication via a FormsAuthentication cookie that is created when a user logs in through the mojo interface. We're looking to recreate this functionality remotely. I realize FormsAuth is based on MachineKey and lives inside a single IIS Web Instance, but am curious for any ideas the community may have.

The current "best" guesses we've come up with here are:

Create a WCF web service that lives in a virtual directory under the mojo site, accepts a username/password and creates the cookie. This is untested as we are unsure if this will actually affect the client.

Redirect the user to an intermediate page under mojo which accepts a username/password and creates the cookie, after which redirects the user again to the desired mojo page.

This does use MojoPortal as a provider, but the real issue is how to create a FormsAuthentication cookie remotely.

Additional background info:

Current system already authenticates against the same AD store, so there is no concern over creating cookies for users that are non-existent. Both servers lie in the same AD domain(they're physically next to each other). The current system's source code is available to us and able to be modified as well.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

江心雾 2024-08-18 04:39:09

如果我理解正确的话,您正在尝试在旧系统和 mojo 之间进行单点登录?我过去也做过类似的事情。我们的旧系统创建一个身份验证令牌并将其传递给第二个系统。然后,向旧系统发出 Web 服务调用以验证令牌(您需要添加一些使令牌真实的规则。例如:一次性使用、超时等)。如果旧系统验证了令牌,则设置 cookie。

FormsAuthentication.SetAuthCookie(, true)

从那里重定向回您的 mojo 主页。

If I understand correctly you are trying to have a single sign-on between your legacy system and mojo? I've done something similar in the past. Our legacy system creates an authentication token and passes it to the second system. A web service call is then made back to the legacy system to validate the token (you'll want to add some rules around what makes a token authentic. For example: one time use, time outs, etc..). If the legacy system validates the token then the cookie is set.

FormsAuthentication.SetAuthCookie(, true)

from there redirect back to your mojo main page.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文