交叉验证选择最佳参数_如何为您的公司选择最佳的身份验证即服务提供商

交叉验证选择最佳参数

by Jeff Okawa

通过Jeff Okawa

如何为您的公司选择最佳的身份验证即服务提供商 (How to choose the best Authentication as a Service Provider for your company)

Have you ever wondered how to choose an authentication service provider?

您是否曾经想过如何选择身份验证服务提供商？

We are amid a growing trend of using federated identifiers to provide authentication to the websites we use everyday.

我们正在使用联合标识符为我们每天使用的网站提供身份验证的趋势不断增长。

We can log in to countless applications using our social media accounts, our work accounts all have SSO capabilities, and we can even log into government websites using our online banking credentials.

我们可以使用社交媒体帐户登录无数应用程序，我们的工作帐户都具有SSO功能，甚至可以使用我们的在线银行凭据登录政府网站。

Conceptually, authentication (and SSO) is simple, but it’s hard and costly to implement correctly. Though businesses have traditionally focused on building features, now in reality they also must focus on lowering user registration contention without exposing the application to vulnerabilities. Just like how cloud infrastructure platforms (like AWS) now allow businesses to focusing on building apps, we see the same happing with authentication.

从概念上讲，身份验证(和SSO)很简单，但是正确实现它既困难又昂贵。 尽管企业传统上一直专注于构建功能，但实际上，它们现在还必须专注于降低用户注册争用，而又不使应用程序暴露于漏洞中。 就像云基础架构平台(如AWS)现在允许企业专注于构建应用程序一样，我们在身份验证方面也遇到了同样的困难。

Authentication as a Service (or authentication service providers) provide authentication and user management services for applications.

身份验证即服务(或身份验证服务提供者)为应用程序提供身份验证和用户管理服务。

They are not just an identity provider, but provide configurable user login pages (or widgets), logout functionality, federated identities with social media accounts, user databases, and some degree of user management. They have out of the box capabilities to support common authentication protocols such as SAML and OpenID Connect.

它们不仅是身份提供者，而且还提供可配置的用户登录页面(或小部件)，注销功能，具有社交媒体帐户的联合身份，用户数据库以及某种程度的用户管理。 它们具有开箱即用的功能来支持常见的身份验证协议，例如SAML和OpenID Connect。

Enterprise customers desiring SSO can often take advantage of easy one-click setups with third-party applications like JIRA, Office 365, and Salesforce though the use of SAML2.

希望使用SSO的企业客户通常可以通过使用SAML2与第三方应用程序(例如JIRA，Office 365和Salesforce)一起使用简单的一键式设置。

你的目标是什么？ (What are your Goals?)

At times, implementing authentication systems for an application can feel like reinventing the wheel. The concept of authentication as a service (AaaS) attempts to solve this problem, but there are things to consider before choosing a provider (or deciding to roll out a custom solution).

有时，为应用程序实施身份验证系统就像重新发明轮子一样。 身份验证即服务(AaaS)的概念试图解决此问题，但是在选择提供程序(或决定推出自定义解决方案)之前需要考虑一些事项。

标准 (Criteria)

Once you’ve come up with a list of important considerations for your organization, it is time to start evaluating the authentication as a service providers (AaaSp’s) in the market. In the last few years, we’ve seen an number of AssSp’s enter and disappear. This makes choosing the right AaaSp that much more critical. They come in all shapes and sizes — from small firms with little clients to large established enterprise venders.

为组织提出重要注意事项列表后，就该开始评估市场上作为服务提供商(AaaSp)的身份验证了。 在过去的几年中，我们已经看到许多AssSp的进入和消失。 这使得选择正确的AaaSp变得更加重要。 它们具有各种形状和规模，从没有多少客户的小型公司到大型成熟的企业供应商。

信任与声誉 (Trust and Reputation)

Entrusting something as important as authentication requires a considerable amount of confidence, so it’s important that the chosen vender should be reputable and a trusted authority in authentication. Consider if their architecture has been reviewed by other security experts and review any online commentary about the provider.

委托与身份验证一样重要的事情需要相当大的信心，因此，所选的供应商应具有良好信誉，并在身份验证中具有可信赖的 权威 ，这一点很重要。 考虑其他安全专家是否已审查其体系结构，并审查有关提供商的任何在线评论。

As we have seen with Stormpath (purchased by Okta in 2017, then dropped the Stormpath API), relaying on a third-party vendor opens the risk of vender abandonment. In the worst case, as it was with the acquisition mentioned above, many were left with no migration path from Strompath to Okta and were required to roll out their own authentication systems.

正如我们已经与Stormpath看到(通过1563，2017年购买的，然后扔下Stormpath API)，中继对第三方供应商打开厂商抛弃的风险。 在最坏的情况下，就像上面提到的收购一样，许多人没有从Strompath到Okta的迁移路径，因此必须推出自己的身份验证系统。

Vender size, client list, and company profile are general guidelines that can be taken into consideration, but you are still taking a risk. Smaller start-up providers can offer significant incentives, but their ability to disappear quickly without proper notice can make them a risky choice. Alternately, larger providers can still shutter their services if that line of business becomes no longer profitable.

供应商规模，客户列表和公司资料是可以考虑的一般准则，但是您仍在冒险。 较小的初创企业可以提供很大的诱因，但如果没有适当通知就Swift消失，这会使他们成为冒险的选择。 或者，如果该业务不再盈利，则较大的提供商仍可以关闭其服务。

目标用户 (Intended Users)

Some AaaS providers, such as One Login, focus exclusively on B2E — providing an SSO experience for a company’s internal employees with their web-based services. Think of company portal pages with links to HR resources, the company Wiki, Sharepoint, and Salesforce. Auth0 and AWS Cognito are providers serving both B2E and B2C and explicitly support clients who have hundreds of thousands of customers.

一些AaaS提供商(例如One Login)仅专注于B2E，即通过基于Web的服务为公司的内部员工提供SSO体验。 想一想带有链接到人力资源，公司Wiki，Sharepoint和Salesforce的公司门户页面。 Auth0和AWS Cognito是服务于B2E和B2C的提供商，并明确支持拥有数十万客户的客户。

供应商锁 (Vender Lock)

Integrating with a AaaSp introduces a more significant amount of interdependence then just integrating an application stack onto a cloud-based solution, because provider-specific code must be written to complete the integration.

与AaaSp集成会引入更多的相互依赖性，而不仅仅是将应用程序堆栈集成到基于云的解决方案中，因为必须编写特定于提供程序的代码才能完成集成。

Not only does this have to be undone, but more integration code for the new provider will have to be written. Moving from an AaaS to rolling out a custom solution is even more costly, since everything would need to be written from scratch.

不仅必须取消此操作，而且还必须编写新提供程序的更多集成代码。 从AaaS过渡到推出自定义解决方案的成本更高，因为所有内容都需要从头开始编写。

Unlike infrastructure changes, where mitigation stargates exist to reduce user interruption, swapping AaaS providers will almost always impact users. Remember, we’re changing components that directly interact with end-users.

与基础架构的变化不同，那里存在缓解星门以减少用户中断，而交换AaaS提供商几乎总是会影响用户。 记住，我们正在更改直接与最终用户交互的组件。

Data ImportMost AaaS providers define a mechanism of importing users into their system by bulk import (where users must go through a password reset flow) or gradual migration process. With the gradual migration, user credentials are first validated against the old database and then encrypted and stored in the new database. In this use case, users are not impacted by the migration.

数据导入大多数AaaS提供程序都定义了一种通过批量导入(用户必须经过密码重置流程)或逐步迁移过程将用户导入其系统的机制。 通过逐步迁移，首先针对旧数据库验证用户凭据，然后将其加密并存储在新数据库中。 在这种情况下，用户不受迁移的影响。

Data ExportThis feature is especially important in the case where applications make use of the AaaS’s datastore. For security reasons, AaaS providers do not publish their password hashing algorithm. Therefore, when an export is required, all users must initiate a password reset flow.

数据导出在应用程序使用AaaS数据存储的情况下，此功能特别重要。 出于安全原因，AaaS提供程序不会发布其密码哈希算法。 因此，当需要导出时，所有用户都必须启动密码重置流程。

If that doesn’t sound bad enough, many AaaS providers DO NOT provide a bulk data export feature, thus adding extra complexity and manual steps to migrate user data out of an AaaS.

如果这还不够糟糕，那么许多AaaS提供商都不会提供批量数据导出功能，从而增加了额外的复杂性和手动步骤，将用户数据迁移出AaaS。

Sub ContractorsSome services offered by AaaS providers are fulfilled by yet another third-party service. 2fa/mfa and email are sometimes features which require separate registrations (and additional payment) with the third-party.

分包商 AaaS提供商提供的某些服务由另一第三方服务提供。 2fa / mfa和电子邮件有时是一些功能，需要分别向第三方注册(和额外付款)。

Taking 2FA as an example, some AaaS services do not allow you to choose the underlying 2FA provider and force you to use their preferred vender. Not only are you forced into a partnership with that vender, but you are also forced to pay their rates (where cheaper alternatives are sometimes available).

以2FA为例，某些AaaS服务不允许您选择基础2FA提供程序，并强迫您使用其首选的供应商。 您不仅被迫与该卖方建立合作伙伴关系，而且还被迫支付他们的税率(有时可以使用更便宜的替代方法)。

技术支持 (Technology Support)

ProtocolsMost AaaS providers support the major federated protocols (OpenID Connect and SAML). Others have additional connectors allowing for customized data sources (Microsoft AD or LDAP) and easy setups to third-party applications like JIRA, Office 365, and Salesforce though the use of SMAL.

协议大多数AaaS提供商都支持主要的联合协议(OpenID Connect和SAML)。 其他一些具有附加的连接器，允许使用SMAL来定制数据源(Microsoft AD或LDAP)，并轻松设置到第三方应用程序(如JIRA，Office 365和Salesforce)。

IntegrationIntegration of the AaaS’s service into your application can still be a significant task (especially if you are running a legacy application). Therefore, one consideration is to see if the AaaS offers libraries for your technology stack.

集成将AaaS服务集成到您的应用程序中仍然是一项艰巨的任务(特别是如果您正在运行旧版应用程序)。 因此，一个考虑因素是查看AaaS是否为您的技术堆栈提供库。

For example: Most major AaaS providers along with social media websites provide client libraries to request, consume, and validate various authentication tokens and documents. If you are running a Java stack, many services offer Java libraries to include with your project for any backend processing. If your stack is supported, the integration process can be as simple as dropping in a JS file, including a JAR, and filling out some values in a property value.

例如：大多数主要的AaaS提供商以及社交媒体网站都提供客户端库来请求，使用和验证各种身份验证令牌和文档。 如果您正在运行Java堆栈，则许多服务都将Java库包含在您的项目中，以进行任何后端处理。 如果支持您的堆栈，则集成过程可以很简单，只需放入一个包括JAR的JS文件，然后在属性值中填写一些值即可。

DocumentationAmple, well-written documentation and community support will go a long way to make integration easier. Some providers offer seed and sample projects to get you started.

文档大量，写得很好的文档和社区支持将大大简化集成。 一些提供商提供种子和示例项目来帮助您入门。

Other FeaturesMany services offer add on features such as user profiling, email, and 2fa/mfa.

其他功能许多服务都提供附加功能，例如用户配置文件，电子邮件和2fa / mfa。

可定制的用户界面和流程 (Customizable User Interfaces and Flows)

AaaS providers allow varying levels of customization for UI pages, widgets, and user attributes. In addition, some systems have “hooks” where customization of flows can take place (checkout Auth0 and AWS Cognito for more detail).

AaaS提供程序允许对UI页面，小部件和用户属性进行不同级别的自定义。 此外，某些系统具有“挂钩”，可以在其中进行流的自定义(签出Auth0和AWS Cognito以获取更多详细信息)。

Depending on your specific organization, it can be difficult to strike the balance between meeting UX wants and what is customizable (within reason) by the provider. In some cases, business requested flows may not be supported by your chosen AaaS.

根据您的特定组织，可能很难在满足UX需求和提供商自定义(在合理范围内)之间达成平衡。 在某些情况下，您选择的AaaS可能不支持业务请求的流程。

有关自定义的说明： (A note about customization:)

Ready out-of-the-box authentication capabilities are one of the great benefits of using an AaaSp. When the pre-built components are used, integration is incredibly simple.

现成的现成身份验证功能是使用AaaSp的一大优势。 使用预构建的组件时，集成非常简单。

On the other hand, heavy customization of the UI and flows increases time and complexity. You may find yourself so heavily and extensively customizing the UI and authentication flows that you must question if it will be cheaper to roll out a custom in-house solution (also considering the yearly cost). The answer might be YES.

另一方面，大量定制UI和流程会增加时间和复杂性。 您可能会发现自己过于繁琐地自定义UI和身份验证流程，因此必须质疑推出自定义内部解决方案是否更便宜 (还要考虑年度成本)。 答案可能是 。

My recommendation is to withhold as much customization as possible within the AaaS framework. This is especially the case when it comes to the authentication and password reset flows, as adding customization to these components tends to increase the complexity of integration and create vendor lock-in.

我的建议是在AaaS框架内保留尽可能多的自定义。 对于身份验证和密码重置流程尤其如此，因为向这些组件添加自定义往往会增加集成的复杂性并创建供应商锁定。

开发和测试支持 (Development and Testing Support)

开发，质量保证和生产环境 (Development, QA, and Production Environments)

Some companies have isolated development and QA environments. To support these requirements, some AaaS providers allow a single account to have multiple identity databases. This unfortunately, is not a universal feature and multiple accounts with the AaaS may be required to support each testing environment.

一些公司隔离了开发和QA环境。 为了满足这些要求， 某些 AaaS提供商允许单个帐户拥有多个身份数据库。 不幸的是，这不是通用功能，可能需要多个AaaS帐户来支持每个测试环境。

负载测试 (Load Testing)

All AaaS systems prohibit unauthorized load testing. This may be a problem if your application requires an end-to-end load test to be approved for production. In this case, some AaaS providers do allow load testing if it is pre-authorized prior to the test taking place. There are often stringent constraints and timeframes the test must be run under.

所有AaaS系统均禁止未经授权的负载测试。 如果您的应用程序需要进行端到端负载测试才能批准生产，则可能会出现问题。 在这种情况下，如果在测试之前已获得预先授权，则某些AaaS提供商确实允许进行负载测试。 通常存在严格的约束条件和必须进行测试的时间范围。

More realistically, you will probably have to implement a login by-pass mechanism for the application to support load tests.

更现实的是，您可能必须为应用程序实现登录绕过机制，以支持负载测试。

价钱 (Pricing)

Pricing models vary significantly between AaaS providers. Some providers have incentives for small start-up organizations and have a free or very affordable lowest tier. Generally speaking, expect to see a price/user graph like the following:

AaaS提供商之间的定价模型差异很大。 一些提供商会鼓励小型初创企业，并提供免费的或非常实惠的最低等级。 一般来说，期望看到如下的价格/用户图：

Price per user is initially very low (or $0), which is great for small organizations or start-ups with low volumes. However, as your user base grows, price/user stays consistent. Eventually it will start to decrease after a certain point, because you’ve either reached the highest usage tier or are in a position to negotiate prices.

最初，每位用户的价格非常低(或$ 0)，这对于小型组织或小批量的初创公司来说非常有用。 但是，随着用户群的增长，价格/用户保持一致。 最终，由于您已经达到最高使用量级别或可以协商价格，因此它将在某个点之后开始减少。

The cost may seem reasonable as you start off, but once you are locked in, an application with 100,000 active users in a month could see a yearly bill of 150k to 200k!

开始时的成本似乎很合理，但是一旦锁定，一个月内拥有100,000个活跃用户的应用程序每年的账单就将达到15万到20万！

If your application already has a user base of several hundred thousand users, it might be cheaper to roll out your own solution! In addition to the per-user fees, there are often fees for additional services you may incur (again, 2fa and email).

如果您的应用程序已经拥有数十万用户，那么推出自己的解决方案可能会更便宜！ 除了按用户收费外，您可能还会产生一些额外的服务费用(再次，2fa和电子邮件)。

B2CNegotiate price if your application has heavy use periods. Some services have variable pricing per moth based on number of actual active users, while others fix the price per month based on an estimate of the heaviest month throughout the year (regardless of how many users actually use the system). The difference between these price plans can be significant.

B2C协商价格(如果您的应用程序使用期限很长)。 某些服务会根据实际活动用户的数量来确定每月的定价，而其他服务则根据对一年中最繁忙月份的估算(无论实际使用多少用户)来确定每月的价格。 这些价格计划之间的差异可能很大。

B2EPrices are always set at an amount per employee account. Beware of minimum fees in the fine print!

B2E价格始终设置为每个员工帐户的金额。 提防印刷品中的最低费用！

用户管理和仪表板 (User Management and Dashboard)

Most AaaS’s have some form of basic user management built into their admin dashboards. In some cases, you can create non-admin accounts for your customer service reps or other associates to make changes to user identities.

大多数AaaS的管理仪表板中都内置了某种形式的基本用户管理。 在某些情况下，您可以为客户服务代表或其他员工创建非管理员帐户，以更改用户身份。

Giving out full-admin accounts to employees simply so they can have access to the user management dashboard should be avoided. The admin account should only be in the hands of the appropriately trained employees, otherwise you run the risk of someone accidentally deleting your entire user database or exposing user identities.

应当避免向员工提供完全管理员帐户，以便他们可以访问用户管理仪表板。 管理员帐户应仅由经过适当培训的员工掌握，否则您将冒有人意外删除整个用户数据库或暴露用户身份的风险。

Whether or not the built-in AaaS dashboard supports your needs is specific to the day-to-day user attribute changes your organization needs to make. Make sure the AaaS provides an appropriate audit tracking/logging trail as per your organization’s policies.

内置的AaaS仪表板是否支持您的需求取决于组织需要进行的日常用户属性更改。 确保AaaS根据您组织的策略提供适当的审核跟踪/记录跟踪。

SLA和客户服务 (SLA and Customer Service)

A direct contact with an account manager of the provider is not offered across all AaaS providers. Free or low-usage tiers often only get access to community forums. Some providers offer paid support, dedicated servers, access to logs, and HIPAA/PCI compliance at an additional cost.

并非所有AaaS提供商都提供与提供商客户经理的直接联系。 免费或低使用率等级通常只能访问社区论坛。 一些提供商提供付费支持，专用服务器，对日志的访问以及HIPAA / PCI合规性，但需要额外付费。

Most AaaSp offer the standard 99.9% to 99.995% SLA uptime, but this still allows for downtimes during the year. This can be of importance if your application must be up during critical periods. Some AaaSp’s offer enterprise solutions (custom deployments) to ensure some form of redundancy in case of a system failure.

大多数AaaSp提供标准的99.9％至99.995％的SLA正常运行时间，但这仍然允许一年中的停机时间。 如果您的应用程序必须在关键时期启动，这可能很重要。 一些AaaSp提供企业解决方案(自定义部署)，以确保在系统故障时进行某种形式的冗余。

结论 (Conclusion)

For start-ups, AaaSp’s provide an affordable solution for authentication so you can focus on your product. For larger organizations with legacy applications and an established user base, you must take into consideration a much broader list of criteria to make sure you select the AaaS that suites your migration, auditing/logging, and budget needs.

对于初创企业而言，AaaSp提供了价格合理的身份验证解决方案，因此您可以专注于产品。 对于具有遗留应用程序和已建立用户群的大型组织，您必须考虑更广泛的标准列表，以确保选择适合您的迁移，审核/日志记录和预算需求的AaaS。

As a follow-up, I’ve written a introduction to federated identities and authentication.

作为后续，我写了关于联合身份和认证的介绍 。

翻译自: https://www.freecodecamp.org/news/evaluating-authentication-as-a-service-providers-6903895a8450/

交叉验证选择最佳参数