iam 证书管理器_为什么必须在您的API管理平台中使用IAM

iam 证书管理器

APIs are key components in any Digital Transformation journey. APIs are enabling organizations to create new business models, connect with partners and customers while providing a seamless experience by linking systems and services together. In this API economy, all modern architecture concepts deeply rely on APIs.

API是任何数字化转型过程中的关键组件。 API使组织能够创建新的业务模型，与合作伙伴和客户建立联系，同时通过将系统和服务链接在一起来提供无缝的体验。 在这种API经济中，所有现代架构概念都深深地依赖于API。

Access delegation is the primary security requirement in an API ecosystem where someone else will access an API on your behalf and you need to delegate the corresponding access rights to the application or service. Providing end users’ credentials or the usage of an API key is not a recommended approach anymore. OAuth 2.0 has become the norm for access delegation. When using OAuth 2.0, the access token is shared with a third party with limited access privileges and an expiry time. Along with OAuth 2.0 OIDC emerged as the authentication layer in API management platforms.

访问委派是API生态系统中的主要安全要求，其他人将代表您访问API，并且您需要将相应的访问权限委派给应用程序或服务。 不再建议提供最终用户的凭据或API密钥的用法。 OAuth 2.0已成为访问委派的规范。 使用OAuth 2.0时，访问令牌将与具有有限访问权限和有效时间的第三方共享。 OIDC与OAuth 2.0一起成为API管理平台中的身份验证层。

By nature, where the digital industry moves hackers follow, when API becomes an industry norm it’s avoidable that hacker’s attention on API echo systems With the amount of data, the severity of the data exposed via APIs and higher usage of API increase the attack surface and the damage. Especially exposing sensitive data such as personally identifiable information (PII) costing companies millions of dollars in repairs and resulting in terrible PR.

从本质上讲，数字行业的发展是黑客遵循的，当API成为行业规范时，就可以避免黑客对API回声系统的关注。随着数据量的增加，通过API公开的数据的严重性以及对API的更高使用会增加攻击面，伤害。 尤其是暴露敏感数据(例如个人身份信息(PII))使公司损失了数百万美元的维修费用，并导致糟糕的PR。

In a typical API management platform key manager component or authorization server mainly focus on the access delegation or securely managing access tokens. But If we check recent OWASP API Security Top 10 it’s clear that API security goes beyond simple authorization capabilities. That’s why we need enterprise IAM solutions in API platforms to fill this security gap. Enterprise IAM not only strengthens the security but brings additional capabilities to enhance digital transformation journey. This article lists down these enterprise IAM capabilities which are essential in your API management platform.

在典型的API管理平台中，密钥管理器组件或授权服务器主要专注于访问委派或安全地管理访问令牌。 但是，如果我们查看最近的OWASP API安全性前10名 ，很明显，API安全性超出了简单的授权功能。 这就是为什么我们需要API平台中的企业IAM解决方案来填补此安全漏洞。 企业IAM不仅增强了安全性，还带来了额外的功能来增强数字转换的过程。 本文列出了这些企业IAM功能，这些功能在您的API管理平台中至关重要。

• Extended Access Delegation Capabilities

  扩展访问委派功能

• End User Identity Management

  最终用户身份管理

• Strong and Adaptive Authentication

  强大的自适应身份验证

• Cross Protocol Single Sign On / Sign Out

  跨协议单点登录/注销

• Identity Federation and Social Login

  身份联盟和社交登录

• Enforce Authorization

  强制授权

• Privacy Management

  私隐管理

Extended Access Delegation Capabilities

扩展访问委派功能

OAuth 2.0 core specification defines five main grant types, namely authorization code, implicit, password, client credential and refresh grant type, but OAuth 2.0 framework is extensible to support advanced access delegation use cases such as SAML 2.0 bearer grant which exchange SAML 2.0 token to an OAuth 2.0 access token, Kerberos OAuth2 grant use kerberos token to authenticate the user. If its a basic API management platform basic authorization grants cater the access delegation needs. But the API management component is a cornerstone in your application which should support extended needs so integrating enterprise IAM solutions with the APIM platform will enable the advanced access delegation support.

OAuth 2.0核心规范定义了五种主要的授予类型，即授权代码，隐式，密码，客户端凭据和刷新授予类型，但是OAuth 2.0框架可扩展为支持高级访问委派用例，例如将SAML 2.0令牌交换为的SAML 2.0承载授予。 OAuth 2.0访问令牌，Kerberos OAuth2授予​​使用kerberos令牌对用户进行身份验证。 如果它是基本的API管理平台，则基本授权会满足访问委派的需要。 但是API管理组件是您应用程序中的基石，应支持扩展的需求，因此将企业IAM解决方案与APIM平台集成在一起将提供高级访问委托支持。

OAuth 2.0 only provides the access grant but user identities are not revealed, in the case of identity information is required OIDC which is an identity layer built on top of OAuth 2.0 can be used. In OIDC flow, an access token and a JWT token with the user information is provided. This will be a primary feature in any IAM solution.

OAuth 2.0仅提供访问授权，但不公开用户身份，在需要身份信息的情况下，可以使用OIDC，它是在OAuth 2.0之上构建的身份层。 在OIDC流程中，提供了带有用户信息的访问令牌和JWT令牌。 这将是任何IAM解决方案的主要功能。

End User Identity Management

最终用户身份管理

API management platforms will be used within the organization or beyond, in either case these APIs will be consumed by people, devices or things. Hence managing digital identities becomes a primary concern in any API management platform. solutions have to deal with different types of identities it can be people, devices or things or people and devices access the same system. The number of identities that access the system can vary from thousands to millions. These identities may reside in heterogeneous identity stores.

API管理平台将在组织内部或外部使用，无论哪种情况，这些API都会被人员，设备或事物消耗。 因此，管理数字身份成为任何API管理平台中的主要关注点。 解决方案必须处理不同类型的身份，它可以是人，设备或事物，也可以是人和设备访问同一系统。 访问系统的身份数量可能从数千到数百万不等。 这些身份可以驻留在异构身份存储中。

Furthermore, how users change their forgotten passwords, how you define password strengths, what mechanisms system provides their end user to recover their credentials. Can administrator impersonate an user account if a customer requests to do so. These are typical concerns any system wants to handle if they work with user identities

此外，用户如何更改其忘记的密码，如何定义密码强度，系统提供了哪些机制来帮助最终用户恢复其凭据。 如果客户要求，管理员可以模拟用户帐户吗？ 这些是系统使用用户身份时要处理的典型问题

Identity management is complex, but IAM solutions can effectively manage these complexities. Identities can be in multiple identity stores in different forms, maybe single identity is distributed across multiple identity stores. These are some few concerns that come with identity management, in the initial stage of the API platform you may not come across these but when it starts to evolve you have to face, having an IAM system from the inception of your API management platform you can simply make sure your platform is ready for future challenges.

身份管理很复杂，但是IAM解决方案可以有效地管理这些复杂性。 身份可以以不同的形式存在于多个身份存储中，也许单个身份分布在多个身份存储中。 这些是身份管理附带的一些问题，在API平台的初始阶段，您可能不会遇到这些问题，但是当它开始发展时，您必须面对，从您的API管理平台开始就拥有IAM系统，您可以只需确保您的平台已准备好应对未来的挑战。

Strong and Adaptive Authentication

强大的自适应身份验证

In the scope of api security it’s common that we pay extra attention to access delegation or how we securely manage access tokens, which I think hinders the importance of end user authentication. Even now username and password based authentication is the most commonly used authentication mechanism which is convenient and at the same time least secure authentication mechanism.

在api安全性范围内，通常我们会特别注意访问委派或我们如何安全地管理访问令牌，这些都妨碍了最终用户身份验证的重要性。 即使是现在，基于用户名和密码的身份验证仍然是最常用的身份验证机制，它既方便又是最不安全的身份验证机制。

Multi-factor Authentication (MFA) emerged as an answer to this problem where it created a layered defense and made it more difficult for an unauthorized person to access a target such as a physical location, computing device, web service, network or a database. MFA concept is based on the assumption that if one factor is compromised or broken, an attacker still has at least one more barrier to breach before successfully breaking into the target and therefore it’s more secure.

多因素身份验证(MFA)可以解决该问题，它创建了分层防御，使未经授权的人员更难以访问目标，例如物理位置，计算设备，Web服务，网络或数据库。 MFA概念基于以下假设：如果一个因素被破坏或破坏，攻击者在成功闯入目标之前仍至少还有一个突破的障碍，因此它是更安全的。

Authentication factors in MFA rely on two or more independent credentials of the three categories.

MFA中的身份验证因素取决于三个类别中的两个或多个独立凭据。

Knowledge factors — Things only the user knows, such as passwords

知识因素-只有用户知道的事情，例如密码

Possession factors — Things only the user has, such as ATM cards

拥有因素-只有用户拥有的东西，例如ATM卡

Inherence factors — Things only the user is, such as a fingerprint

固有因素-只有用户才是的东西，例如指纹

The level of security provided by MFA has made it the best way to authenticate in the modern world. Given that one of the factors is compromised by an attacker, it is highly unlikely that all the other factors are also compromised.

MFA提供的安全级别使其成为现代世界中进行身份验证的最佳方法。 鉴于攻击者破坏了其中一个因素，其他所有因素也极不可能受到破坏。

Even though MFA’s provide high security it hinders the usability. Static set of authentication flow is not convenient for different sets of users. Adaptive authentication is the ability to switch the authentication flow based on the context. This shouldn’t be misunderstood as a completely different mechanism that replaces MFA. Adaptive authentication orchestrates different authenticators based on the context during the user authentication process. The best part is that most times users won’t even know that the authentication process has changed. Adaptive authentication intelligently takes various factors in the current authentication process context and provides the authentication flow to the user.

即使MFA提供了很高的安全性，也阻碍了可用性。 静态的身份验证流集对于不同的用户集不方便。 自适应身份验证是根据上下文切换身份验证流程的能力。 这不应被误认为是替代MFA的完全不同的机制。 自适应身份验证在用户身份验证过程中根据上下文编排不同的身份验证器。 最好的部分是，大多数时候用户甚至都不知道身份验证过程已更改。 自适应身份验证会在当前身份验证过程上下文中智能地考虑各种因素，并将身份验证流程提供给用户。

Cross Protocol Single Sign On / Sign Out

跨协议单点登录/注销

At a glance we can say that the primary focus of the API management platform is to securely manage APIs exposed in the system. But in a complete digital transformation project API integration is just a fraction and there are multiple applications where consumers want to access to do a given business use case. Single Sign-on (SSO) is the mechanism that ensures customers have a consistent login experience with common credentials across different digital properties

乍一看，我们可以说API管理平台的主要重点是安全地管理系统中公开的API。 但是在一个完整的数字转换项目中，API集成只是一小部分，并且有多个应用程序供消费者访问以执行给定的业务用例。 单一登录(SSO)是一种机制，可确保客户使用不同数字媒体资源中的通用凭据获得一致的登录体验

Few authorization servers may support OIDC based single sign on, even though modern applications support OIDC based federation most of the applications still widely use SAML and there are applications which use Ws-Federation as well. In most digital transformations projects we can see most of these protocols are being used in applications hence you have to pick an IAM solution that supports all of these federation protocols specially that solution should support cross protocols single sign on along with sign out.

很少有授权服务器可以支持基于OIDC的单点登录，即使现代应用程序支持基于OIDC的联合身份，大多数应用程序仍然广泛使用SAML，并且有些应用程序也使用Ws联合身份验证。 在大多数数字转换项目中，我们可以看到大多数协议都在应用程序中使用，因此，您必须选择支持所有这些联合协议的IAM解决方案，特别是该解决方案应支持跨协议的单点登录和注销。

Furthermore if this platform contains legacy applications which use proprietary protocols for federation then obviously, yours selected IAM solution should have the capability to extend its federation authentication support for these non standardized protocols as well.

此外，如果该平台包含使用专有协议进行联盟的旧版应用程序，那么显然，您选择的IAM解决方案也应该能够将其联盟身份验证支持扩展到这些非标准化协议。

Identity Federation and Social Login

身份联盟和社交登录

Having a sophisticated API management platform with less developer attraction is not the organization objective. One indicator of the success of an APIM platform is the developer community around it. It’s common that developers use Git, and almost all the developers have at least one social account such as Facebook, Twitter, LinkedIn etc. Hence allowing developers to use their social accounts in login to the APIM platform will attract more developers.

拥有复杂的API管理平台且对开发人员的吸引力较小，这并不是组织的目标。 APIM平台成功的一个指标是围绕它的开发人员社区。 开发人员通常使用Git，并且几乎所有开发人员都至少拥有一个社交帐户，例如Facebook，Twitter，LinkedIn等。因此，允许开发人员使用其社交帐户登录APIM平台将吸引更多的开发人员。

Even if you use API management platforms internally you want internal users to access this platform, but you may have different business units in your organization, while employees of these BUs reside in BU specific identity stores. In this particular scenario we can use identity federation to let these internal users to seamlessly access the new platform. Further organization will grow with acquisition and mergers even in that case we can simply use Identity federation to do this complex identity integration in a simpler manner and let new users onboard to the APIM platform in a few minutes.

即使您内部使用API​​管理平台，您也希望内部用户访问此平台，但是您的组织中可能拥有不同的业务部门，而这些BU的员工却位于BU特定的身份存储区中。 在这种特定情况下，我们可以使用身份联合来让这些内部用户无缝访问新平台。 即使在这种情况下，我们可以简单地使用身份联合会以更简单的方式完成此复杂的身份集成，并在几分钟之内让新用户加入APIM平台，从而使更多的组织随着收购和合并而增长。

Enforce authorization

强制授权

Authentication is the mechanism of verifying the identity of the person or the things, with the authorization it checks whether that verified identity is authorized to do the given action or access the given data. In other words authorization ensures users or things can only access what they are authorized to access. Implementing authorization in API we need to consider two levels of authorization, first need to validate the authorization in the API entry point whether this user can execute the given action then need to verify whether use can access the exposed data.

身份验证是一种验证人或事物身份的机制，通过授权，它可以验证所验证的身份是否被授权执行给定的操作或访问给定的数据。 换句话说，授权可确保用户或事物只能访问其有权访问的内容。 在API中实现授权我们需要考虑两个级别的授权，首先需要在API入口点验证该授权者是否可以执行给定的操作，然后需要验证使用是否可以访问公开的数据。

OAuth 2.0 scope comes as the best choice for enforcing resource level authorization. Either this can be validated in the back end service level or in the API gateway level where enforcing API gateway level would be the clean approach. In the typical OAuth 2.0 flow scope validation should be handled in two levels. At the time the client requests the scopes need to validate if authenticated users are eligible to grant the requested scope and then API invocation time if the API is accessible with the given scope. In the initial authorization validation if you are using an enterprise IAM solution its possible to use more fine grain authorization using XACML or open policy agent (OPA).

OAuth 2.0范围是执行资源级别授权的最佳选择。 可以在后端服务级别或在API网关级别验证API网关级别，这是干净的方法。 在典型的OAuth 2.0流范围验证中，应分为两个级别。 在客户端请求范围时，需要验证经过身份验证的用户是否有资格授予请求的范围，然后验证API调用时间(如果可以使用给定范围访问API)。 在初始授权验证中，如果您使用的是企业IAM解决方案，则可以使用XACML或开放策略代理(OPA)使用更精细的授权。

Then we need to validate the authorization in the API implementation level to prevent unauthorized access to sensitive data. Even though a user is capable of invoking given API action he may not access the sensitive data. This should be validated in the code level where we need to pass the use information. This is another use case of JWT tokens, so authenticated user information can be passed into downstream services with the JWT tokens.

然后，我们需要在API实施级别中验证授权，以防止未经授权访问敏感数据。 即使用户能够调用给定的API操作，他也可能无法访问敏感数据。 这应该在我们需要传递使用信息的代码级别进行验证。 这是JWT令牌的另一个用例，因此可以将已认证的用户信息与JWT令牌一起传递到下游服务中。

Privacy management

私隐管理

When developing a public facing API management platform, privacy and compliance capabilities are foundational and API management platform should focus on protecting the individual. Privacy standards and best practices continue to evolve in terms of both formal regulations and consumer expectations. API management platform must adhere to an increasing number of consumer protection laws and regulations. For example, the EU General Data Protection Regulation (GDPR), which came into effect in May 2018 in the EU, is top of mind for organizations based in the EU or those that collect and hold data on people in the EU. GDPR primarily focuses on the protection of personal data and individual rights by giving control of their personal data to individuals. The regulation has catalyzed many countries to come up with their own privacy regulations. Multi-national organizations must worry about privacy regulations of each and every country they do business with and use an IAM solution sophisticated enough to ensure adherence to international privacy and data retention regulations when they build their API management platform or digital transformation journey.

在开发面向公众的API管理平台时，隐私和合规性功能是基础，API管理平台应重点保护个人。 隐私标准和最佳做法在正式法规和消费者期望方面不断发展。 API管理平台必须遵守越来越多的消费者保护法律法规。 例如，欧盟通用数据保护条例(GDPR)于2018年5月在欧盟生效，对于总部位于欧盟的组织或收集并保存有关欧盟人员数据的组织而言，它是首要考虑的问题。 GDPR主要通过将对个人数据的控制权交给个人来保护个人数据和个人权利。 该法规促使许多国家提出自己的隐私法规。 跨国组织必须担心与之有业务往来的每个国家/地区的隐私法规，并使用足够复杂的IAM解决方案来确保在构建API管理平台或进行数字转换过程中遵守国际隐私和数据保留法规。

Conclusion

结论

APIs are the main element in any digital transformation journey. This exponential increase in API adoption has made it a prime target for hackers. Hence it’s very important to implement API security correctly. API platforms differ from one to another, sensitivity of the data it shares is different hence, API security infrastructure should be designed to cater to unique requirements in each API platform and its sensitivity.

API是任何数字化转型过程中的主要元素。 API采用率的指数级增长使其成为黑客的主要目标。 因此，正确实现API安全非常重要。 API平台彼此不同，共享数据的敏感性也不同，因此，API安全基础结构应设计为满足每个API平台及其敏感性的独特要求。

Further in a growing API platform consumers are the main assert hence identity management is foundational. API consumers required a seamless on boarding and login experience along with a confirmed security and trust and privacy is a key expectation from both regulatory authorities and consumers. Hence as I discussed throughout this article coupling your API management solution with an enterprise Identity and access management solution is a key requirement now more than ever.

此外，在不断增长的API平台中，消费者是主要主张，因此身份管理是基础。 API消费者需要无缝的登机和登录体验，以及经过确认的安全性，信任和隐私，这是监管机构和消费者的主要期望。 因此，正如我在本文中所讨论的那样，将API管理解决方案与企业身份和访问管理解决方案相结合现在比以往任何时候都更为关键。

翻译自: https://medium.com/swlh/why-enterprise-iam-is-a-must-in-your-api-management-platform-610fa6fe5ac8

iam 证书管理器