使用Saml2和Okta作为服务提供者在Asp.NetCore 3中进行用户身份验证

Question

我正在用Okta替换我们内部发明的身份验证服务，并且需要在我们的应用程序中使用Saml2支持SSO。Okta可以配置为服务提供者，发送SAMLRequest并接收和验证SAMLACK。到目前为止一切顺利：我能够在Okta中配置身份提供者，接收断言，并且根据日志，断言已成功验证并用户自动配置。

但是从现在开始会发生什么呢？

< li >在Idp启动的流程中，如何将用户重定向到应用程序url？由Idp配置的< code>RelayState是否只是选项？我不喜欢这样的想法，如果我们改变我们的应用程序url，我们所有的客户都必须做出改变。我希望有可能将Idp链接到Okta应用程序，因此重定向url将由该应用程序配置。 < li >重定向到我们的应用程序站点后，如何在Asp.Net核心中验证用户身份？我实现了自定义的< code > AuthenticationHandler ，它读取Okta在重定向时设置的< code>sid cookie，并从Okta检索会话信息。在那里，我获取用户名并创建< code >主体。这种方法可行，但在我看来是错误的——它太手动了，我希望是Okta。Sdk为我做到这一点(如果这是正确的认证方式)。 < li >断言验证成功后，是否可以将saml令牌交换为OAuth令牌，以便在应用程序中进行身份验证？

Answer 1

最后，我能够让它按照我想要的方式工作。目前，我在Idp启动的流方面遇到了问题，如果找到解决方案，我将更新答案。

> < li>

首先将贵组织的Okta配置为外部Saml IdP的Saml Sp。Api文档在这里。UI说明在这里。您应该会从外部IdP收到< code>SAML协议设置的信息(IdP发行者URI、IdP单点登录URL和IdP签名证书)。

下一步在 Okta 中创建 Web 应用程序。您的登录重定向 URI 应以 /authorization-code/callback 结尾，否则您必须在代码的 CallbackPath 属性中对其进行配置（见下文）。你不需要实现此终结点，框架会为你执行此操作。

现在安装Okta.AspNetCorenuget并将此代码添加到配置服务方法中

 services.AddAuthentication(options =>
 {
     options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
     options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
     options.DefaultChallengeScheme = OktaDefaults.MvcAuthenticationScheme;
 })
 .AddCookie()
 .AddOktaMvc(new OktaMvcOptions
 {
     OktaDomain = "<okta_domain>",
     ClientId = "<app_client_id>",
     ClientSecret = "<app_client_secret>",
     Scope = OktaDefaults.Scope,
     //CallbackPath = "/authorization-code/callback" <= it's default value, change it if required
 });

您将在步骤2中创建的web应用程序的“常规”选项卡底部找到app_client_id和app_clint_secret。

现在是最有趣的部分。如果要为内部用户（而不是外部 Saml Idp 用户）触发身份验证过程，请调用 ChallengeAsync 方法。像这样：

 [ApiController]
 [Route("[controller]")]
 public class AuthController : ControllerBase
 {
     [HttpGet("login")]
     public async Task Login()
     {
         var properties = new AuthenticationProperties
         {
             RedirectUri = "/"
         };

         await HttpContext.ChallengeAsync(properties);
     }
 }

每当您点击/auth/loginurl时，您将被重定向到Okta进行身份验证。

如果要为外部 Idp 用户触发身份验证过程，则应在身份验证属性类中添加 idp 参数。

[ApiController]
[Route("[controller]")]
public class SsoController : ControllerBase
{
    private readonly ILogger<SsoController> _logger;

    private readonly IOktaClient _oktaClient;

    public SsoController(ILogger<SsoController> logger, IOktaClient oktaClient)
    {
        _logger = logger;
        _oktaClient = oktaClient;
    }

    [HttpGet]
    public async Task Sso([FromQuery] string name)
    {
        var idpProviders = await _oktaClient.IdentityProviders.ListIdentityProviders(q: name, limit: 1).ToListAsync();

        // search is case insensitive and "starts with", and not "exact match"
        var idp = idpProviders.FirstOrDefault(p => p.Name.Equals(name, StringComparison.InvariantCultureIgnoreCase));

        if (idp == null)
        {
            _logger.LogWarning($"idp name '{name}' doesn't exist");

            var authenticationProperties = new AuthenticationProperties
            {
                RedirectUri = "/"
            };

            await HttpContext.ForbidAsync(authenticationProperties);
        }
        else
        {
            var properties = new AuthenticationProperties
            {
                RedirectUri = "/",
                Items = { ["idp"] = idp.Id }
            };
            await HttpContext.ChallengeAsync(properties);
        }
    }
}

当您点击/sso？ name=MySamlIdpurl时，您将查找步骤1中定义的MySamlIdp身份提供者，并使用其id告诉Okta重定向用户进行身份验证的位置。Nuget中定义的IOktaClientOkta.Sdk。

Answer 2

基于纯SAML方法回答您的问题:

1. 您可以使用SP发起的SSO-您将实现在某些页面上登录的相同目标。假设您的应用程序作为SAML服务提供商驻留在＜code＞my.app中。com，您希望用户登陆https://my.app.com/foo/bar在他们通过身份验证后。发布＜代码＞https://my.app.com/foo/bar发送给您的客户端/用户将导致在他们最终单击此链接时启动SP init流。在IdP和SP之间来回移动一段时间后，用户将登陆https://my.app.com/foo/bar作为他们的最终目的地

您可以通过在您的应用程序中或您的堆栈中的应用程序上游进行额外的重定向，对IdP启动的流实施相同的想法。这有时被称为虚荣心网址。例如，如果虚饰URL是https://my.app.com/home,，你的应用程序或另一个上游组件可以将这个URL转换为另一个目标URL，并发出一个到目标的重定向。如上所述，目标URL可以启动具有RelayState的IdP发起的流或SP发起的流。你的应用程序或上游组件必须维护虚URL和目标URL之间的映射。

Okta不提供SAML工具包或SDK。NET应用程序作为SAML服务提供商，他们推荐第三方库。ASP.NET不支持开箱即用的SAML......这是Okta推荐第三方的另一个原因。（微软不是这些第三方之一）。两个流行、免费且广泛使用的选择是可持续性和ITFoxTec。查看他们的文档，选择一个并实施它。之后您不应该求助于您的cookie解决方案。

根据您使用 Okta 作为 SAML 服务提供商的方法以及使用另一个 SAML 身份提供商的身份存储来回答您的问题。流为 2 个跃点：SAML IdP -

您的应用程序必须通过前端通道回调（类似SAML）或API回调（类似oAuth）与Okta集成。后者或多或少需要前者，尽管此路径有很多变化。下面的答案假设集成的前端回调风格。

> < li>

您的应用程序将通过RelayState“调用”,方法是让Okta在处理来自第一跳的SAML响应后重定向到RelayState中的URL。如果你让你的RelayState为< code > https://my . app . com/foo/bar ，那么在IdP和SP与你的app之间来回一些之后，用户将登陆< code > https://my . app . com/foo/bar 作为他们的最终目的地。您的应用程序必须通过IdP启动或SP启动的SAML流激活第一跳来触发此序列。

在前端回调风格的集成中，您将使用微软接口Okta libs，如Okta的例子所示。

使用Okta作为您的身份存储和经过身份验证的主体，您可以通过其他步骤从Okta获取令牌。如果您的目标是通过Okta从第3方对您的应用程序启用API调用，请研究集成的API回调样式。