AWS iot-mi documentation change
Summary
Updated terminology from 'managed integrations' to 'Managed Integrations' for consistency
Security assessment
Changes are capitalization updates only. No security vulnerabilities, configurations, or features were modified or added. The authorization server requirements and token security boundaries remain unchanged.
Diff
diff --git a/iot-mi/latest/devguide/roles-account-linking.md b/iot-mi/latest/devguide/roles-account-linking.md index 34c502e9d..96c2acc76 100644 --- a//iot-mi/latest/devguide/roles-account-linking.md +++ b//iot-mi/latest/devguide/roles-account-linking.md @@ -59 +59 @@ The authorization server must either: -Otherwise, your connector will not be able to support the required `AWS.ActivateUser`operation. This will prevent connector usage with managed integrations. +Otherwise, your connector will not be able to support the required `AWS.ActivateUser`operation. This will prevent connector usage with Managed Integrations. @@ -61 +61 @@ Otherwise, your connector will not be able to support the required `AWS.Activate -If the connector developer or owner does not maintain their own authorization server, the authorization server used must provide authorization for resources managed by the connector developers third party platform. This means that any tokens received by managed integrations from the authorization server must provide meaningful security boundaries on devices (the resource). For example, an end users token does not allow for commands on another end users device; the permissions provided by the token are mapped to resources within the platform. Consider the _Lights Incorporated_ example. When an end user starts the account linking flow with their connector, they are redirected to the _Lights Incorporated_ login page which fronts their authorization server. Once they have logged in and granted permissions to the client, they provide a token that gives the connector access to resources within their _Lights Incorporated_ account. +If the connector developer or owner does not maintain their own authorization server, the authorization server used must provide authorization for resources managed by the connector developers third party platform. This means that any tokens received by Managed Integrations from the authorization server must provide meaningful security boundaries on devices (the resource). For example, an end users token does not allow for commands on another end users device; the permissions provided by the token are mapped to resources within the platform. Consider the _Lights Incorporated_ example. When an end user starts the account linking flow with their connector, they are redirected to the _Lights Incorporated_ login page which fronts their authorization server. Once they have logged in and granted permissions to the client, they provide a token that gives the connector access to resources within their _Lights Incorporated_ account.