IdP使用Sustainsys.SAML2启动的登录-AuthenticateResult没有信息 [英] IdP Initiated Login with Sustainsys.SAML2 - AuthenticateResult Has No Information

问题描述

此票证延续了从此处开始的传奇: AuthenticateResult.成功Okta和Sustainsys.SAML2 是错误的.请参阅该票证以获取基本设置信息.

This ticket continues the saga started here: AuthenticateResult.Succeeded is false with Okta and Sustainsys.SAML2. Please see that ticket for basic setup information.

对于SP发起的登录，现在一切正常.但是，IdP启动的登录也会发生同样的问题.

All is working fine now, for SP-Initiated login. But the same issue is happening for IdP-initiated login.

这是一个日志文件的文本-初始条目来自Sustainsys代码，最后一个条目("SAML身份验证失败")来自我编写的用于在回调方法中调试问题的自定义代码:

Here is the text of a log file - the initial entries are from the Sustainsys code, and the last one ("SAML Authentication Failure") is from custom code I wrote to debug the issue in the callback method:

2020-09-15 16:01:40.574 -05:00 [DBG] Received unsolicited Saml Response Microsoft.IdentityModel.Tokens.Saml2.Saml2Id which is allowed for idp http://www.okta.com/exk1jic9zn7QommF00h8
2020-09-15 16:01:40.590 -05:00 [DBG] Signature validation passed for Saml Response Microsoft.IdentityModel.Tokens.Saml2.Saml2Id
2020-09-15 16:01:40.652 -05:00 [DBG] Extracted SAML assertion id16338952065129118260692652
2020-09-15 16:01:40.652 -05:00 [INF] Successfully processed SAML response Microsoft.IdentityModel.Tokens.Saml2.Saml2Id and authenticated [e-mail]
2020-09-15 16:01:41.433 -05:00 [ERR] SAML Authentication Failure:
authenticateResult.Failure (Exception object) is null;
No information was returned for the authentication scheme;
authenticateResult.Principal is null;
authenticateResult.Properties is null.
authenticateResult.Ticket is null.

上面的日志来自Okta IdP，但是当我配置应用程序以使用测试IdP时，我也得到了相同的准确结果(即 https://stubidp.sustainsys.com/).

The logging above is from an Okta IdP, but I also get the same exact result when I configure the application to use the test IdP (i.e., https://stubidp.sustainsys.com/).

但是，请注意，它在我的Visual Studio 2019开发环境中运行良好，并且 在部署到桌面上的本地IIS实例时也运行良好.

Note, however, that it works fine in my Visual Studio 2019 development environment, and also works fine when deployed to a local IIS instance on my desktop.

仅当将相同的代码部署到生产VM时，才会出现此问题.这使我怀疑这是VM环境所特有的(就像最后一个问题一样)，但是我对如何进一步调查一无所知.

The problem only arises when the same code is deployed to a production VM. This makes me suspect that it is something particular to the VM environment (as the last issue was), but I am at a loss on how to investigate further.

任何帮助将不胜感激.谢谢！

Any help would be most appreciated. Thanks!

更新:如果有用，这是启动文件中的更新代码:

Update: Here is the updated code from the Startup, if useful:

var usingSAML = Configuration.GetValue<bool>("Authentication:UseSAML");
      var usingJWT = Configuration.GetValue<bool>("Authentication:UseJWT");
      AuthenticationBuilder authBuilder = null;

      if (usingSAML)
      {
        // added to address bug with Okta integration 
        // see https://www.developreference.com/article/10349604/Sustainsys+SAML2+Sample+for+ASP.NET+Core+WebAPI+without+Identity
        // and https://stackoverflow.com/questions/63853661/authenticateresult-succeeded-is-false-with-okta-and-sustainsys-saml2/63890322#63890322
        services.AddDataProtection()
          .PersistKeysToFileSystem(new DirectoryInfo("Logs"));

        services.Configure<CookiePolicyOptions>(options =>
        {
          // SameSiteMode.None is required to support SAML SSO.
          options.MinimumSameSitePolicy = SameSiteMode.None;

          options.CheckConsentNeeded = context => false;

          // Some older browsers don't support SameSiteMode.None.
          options.OnAppendCookie = cookieContext => SameSite.CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
          options.OnDeleteCookie = cookieContext => SameSite.CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
        });

        authBuilder = services.AddAuthentication(o =>
        {
          o.DefaultScheme = ApplicationSamlConstants.Application;
          o.DefaultSignInScheme = ApplicationSamlConstants.External;
          o.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
          o.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        });

        authBuilder.AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, options =>
        {
          // see https://stackoverflow.com/questions/46243697/asp-net-core-persistent-authentication-custom-cookie-authentication
          options.ExpireTimeSpan = new System.TimeSpan(365, 0, 0, 0, 0);
          options.AccessDeniedPath = new PathString("/login");
          options.LoginPath = new PathString("/login");
        })
        .AddCookie(ApplicationSamlConstants.Application)
        .AddCookie(ApplicationSamlConstants.External)
        .AddSaml2(options =>
        {
          options.SPOptions.EntityId = new EntityId(this.Configuration["Saml:SPEntityId"]);
          var allowIdpInitiated = Configuration.GetValue<bool>("Saml:AllowIdPInitiated"); 
          if (allowIdpInitiated)
          {
            var siteRoot = this.Configuration["Saml:SiteRoot"];
            var siteRootEncoded = WebUtility.UrlEncode(siteRoot);           
            var returnUrl = string.Format("{0}/api/Security/SamlLoginCallback?returnUrl={1}", siteRoot, siteRootEncoded);
            options.SPOptions.ReturnUrl = new System.Uri(returnUrl);
          }   
          options.IdentityProviders.Add(
              new IdentityProvider(
                  new EntityId(this.Configuration["Saml:IDPEntityId"]), options.SPOptions)
              {
                MetadataLocation = this.Configuration["Saml:IDPMetaDataBaseUrl"],
                LoadMetadata = true,
                AllowUnsolicitedAuthnResponse = allowIdpInitiated
              });
          options.SPOptions.ServiceCertificates.Add(new X509Certificate2(this.Configuration["Saml:CertificateFileName"]));
        });
      }

更新:我发现，使用测试IDP( https://stubidp.sustainsys.com/)，更改了断言消费者服务URL的大小写与受众字段中使用的大小写匹配，从而改变了行为.发生这种情况时，我没有像在AuthenticateResult中那样获得空值，而是被重定向回了IdP，就像执行SP启动的登录一样.当然，仍然不是期望的行为.

Update: I found that, using the test IdP (https://stubidp.sustainsys.com/), changing the case of the Assertion Consumer Service Url to match the case used in the audience field changes the behavior. When this happens, instead of getting the null values in the AuthenticateResult, I am redirected back to the IdP as if I were doing a SP-initiated login. Still not the desired behavior, of course.

但是请注意，这种情况在我的本地PC(Windows 10专业版)上完全没有区别.它仅在服务器上表现不同.)

Note, however, that case makes no difference at all on my local PC (Windows 10 professional). It only behaves differently on the server.)

推荐答案

此处的根本原因最终是由Okta最初发布到的网址和某些重定向中使用的URL的不同引起的.URL匹配，但大小写不匹配.这会导致Cookie不能被后来调用的方法读取，这些方法被发送到另一个URL，即使该区别只是路径的大小写不同.一旦确保所有路径完全匹配(一直到套管)，它便开始工作.

This root cause here was ultimately caused by differences in the case of the Url to which Okta initially posted and the case of the URL used in some redirections. The URLs matched, but the case did not. This caused cookies to be unreadable by later-invoked methods which were being sent to a URL which was different, even though the difference was only in the casing of the path. Once we made sure that all paths matched exactly, down to the casing, it started working.

这篇关于IdP使用Sustainsys.SAML2启动的登录-AuthenticateResult没有信息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！