Nopcommerce Okta一体化

Question

我有以下几点：

application

• .net
• Okta身份管理w/自定义auth服务器
• .net核web .net核心web api application
• Nopcommerce 4.2 web应用程序

所有这些都运行在Azure应用程序服务中。我开发的web应用程序和api应用程序合作得很好。web应用程序将auth承载令牌传递给API，API使用Aspnetcore.Okta中间件对其进行验证。

然而，我现在需要把我的Nopcommerce应用程序纳入其中。我花了3天时间尝试构建一个插件--即使是一个基本上什么也不做的插件，除了麻烦之外，什么都没有。我用了自己的“官方”模板，它有自己的问题。所以我决定把Facebook外部的auth插件，然后开始编辑它。至少现在我有了一些我可以实际工作的东西。

这是我被困的地方..。我可以继续使用Okta中间件并完成它吗？我指的是以下步骤：

Challenge

• Middleware there

• Middleware中的

1. 添加登录操作控制器以覆盖默认的Nopcommerce登录操作
2. ，如果用户未进行身份验证，则发出应该将其重定向到登录页面(在我现有的web应用程序中)
   1. 用户日志设置会话cookie并将用户重定向回Nopcomm应用
   2. ，该中间件再次启动，查看cookie，调用/verify端点，然后为关联的用户填充ClaimsPrincipal。

   G 223

我的想法是，如果机器键在两个应用程序上都是相同的，那么cookie应该可以正常工作。

您认为这是最好的方法吗，还是应该按照1-4中的相同步骤，除了4之后，将用户发送回Nopcomm站点，其中包含查询字符串中的令牌，然后在Nopcomm端手动验证它？

Answer 1

我想，到目前为止，我会分享我的测试结果，因为它揭示了一些我真的没有想到的事情。也许这些事情对你们大多数人来说都是显而易见的/众所周知的--但对我来说，它们确实是很棘手的。

我学到的第一件重要的事情是，你必须对你的应用程序问题的挑战类型有明确的认识。如果您正在自托管登录页面，则需要使用：

            services.AddAuthentication(options =>
            {
                options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
            })

如果您正在使用Okta (或其他openId提供程序)登录页面，则需要发出另一种类型的挑战：

            builder.Services.AddAuthentication(options =>
            {
                options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
            })

我所了解到的是，如果您在OpenID核心应用程序中使用ASP.NET连接，并且您正在自托管登录页面，则流程类似于：

1. 用户试图访问受保护的
2. 标记，告诉Okta中间件注入自己并完成它的任务。User.Identity.IsAuthenticated是假的，因此它重定向到cookie选项下设置的任何内容，作为登录路径：

            .AddCookie(options =>
            {
                options.LoginPath = new PathString("/Account/SignIn");
                options.Cookie.Name = ".AspNet.SharedCookie";
            })

1. 我的登录页面只是使用Okta小部件，所以点击登录就会将用户发送给Okta，Okta做它的事情，然后将用户发送回应用程序到每个神秘的“授权-代码/回调”url。该url由Okta中间件处理。ClaimsPrincipal.
2. Here中间件处理从Okta发送的令牌，调用/userinfo端点来获取声明(假定您已将该属性设置为true)并填充一个/userinfo，这是我忽略了的一部分，它还设置了一个cookie。从那时起，.net框架将检查用户是谁，以及他们是否经过身份验证。我完全误解了这一点。我以为中间件会在后台调用/authorize或类似的东西.

因此，我在这里学到的最大教训是:仅仅因为两个应用程序都使用相同的OpenID服务器，并不意味着它们可以轻松地共享auth/会话。为了使真正的SSO无缝地工作，他们还必须共享一个cookie。这就引出了我的第二个发现:在ASP.NET核心应用程序之间共享cookies。简短的说法是，你必须：

在两个应用程序b中，将cookie命名为相同的名称。使用IDataProtection接口将您的cookie密钥存储到两个应用程序都可以到达的地方(我选择了Azure)。确保这两个应用程序的cookie域是相同的。

因此，最终，这就是我的代码看起来像端到端(在每个应用程序的启动)。我仍然在处理一些特定于Nopcommerce的奇怪之处，但希望它们能在不久的将来得到解决。

            var oktaMvcOptions = new OktaMvcOptions()
            {
                OktaDomain = oktaDomain,
                ClientId = clientId,
                ClientSecret = clientSecret,
                Scope = new List<string> { "openid", "profile", "email", "address", "groups" },
                AuthorizationServerId = authServerId,
                GetClaimsFromUserInfoEndpoint = true
            };

            services.Configure<CookiePolicyOptions>(options =>
            {
                // This lambda determines whether user consent for non-essential cookies is needed for a given request.
                options.CheckConsentNeeded = context => true;
                options.MinimumSameSitePolicy = SameSiteMode.None;
            });


            CloudStorageAccount storageAccount = CloudStorageAccount.Parse(storageConnectionString);
            CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
            CloudBlobContainer container = blobClient.GetContainerReference(storageContainerName);
            var blob = container.GetBlockBlobReference("somefilename.xml");

            services.AddDataProtection().SetApplicationName("somesharedappname").PersistKeysToAzureBlobStorage(blob);

            services.AddAuthentication(options =>
            {
                options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
            })
            .AddCookie(options =>
            {
                options.LoginPath = new PathString("/Account/SignIn");
                options.Cookie.Name = "somesharedcookiename";
            })
            .AddOktaMvc(oktaMvcOptions);

我希望这能帮助那些在同样的问题上挣扎的人。如果有人能提出一个更好的机制来实现这一点，我很想听听你的想法和建议。