AWS amazonq documentation change
Summary
Expanded documentation with detailed explanations of Jira permissions, ACL inheritance, access controls, and failure handling
Security assessment
Adds comprehensive security documentation about permission structures, ACL enforcement, and access requirements but does not address a specific vulnerability
Diff
diff --git a/amazonq/latest/qbusiness-ug/jira-user-management.md b/amazonq/latest/qbusiness-ug/jira-user-management.md index 0b1f35af3..4fe60ddd4 100644 --- a//amazonq/latest/qbusiness-ug/jira-user-management.md +++ b//amazonq/latest/qbusiness-ug/jira-user-management.md @@ -11 +11 @@ Amazon Q Business supports crawling ACLs for document security by default. -When you connect an Jira data source to Amazon Q Business, Amazon Q Business crawls ACL information attached to a document (user and group information) from your Jira instance. If you choose to activate ACL crawling, the information can be used to filter chat responses to your end user's document access level. +Jira organizes work into Projects, which serve as containers for Issues—the core tasks, bugs, or stories that teams track. Each issue belongs to a project and can have Comments, Attachments, and Worklogs to facilitate collaboration, provide context, and track time spent. Projects can be Team-Managed (private, limited, or open) or Company-Managed, offering flexibility in workflows and permissions. When you connect an Jira data source to Amazon Q Business, Amazon Q Business crawls ACL information attached to a document (user and group information) from your Jira instance. If you choose to activate ACL crawling, the information can be used to filter chat responses to your end user's document access level. @@ -13 +13 @@ When you connect an Jira data source to Amazon Q Business, Amazon Q Business cra -The Jira user IDs are mapped as follows: +**Identity crawling** : The connector extracts project-level permissions based on the project key. It identifies direct users and group members, capturing their account IDs and emails. Federated groups, synchronized from external identity providers, appear as local groups in Jira but are managed externally. The connector respects Jira’s permission structure, ensuring that permissions remain intact even when users are removed and later reinstated. Suspended users are included in API responses but marked as inactive, preventing unauthorized access. @@ -15 +15 @@ The Jira user IDs are mapped as follows: - * `_user_id`—User IDs exist in Jira on files where there are set access permissions. They are mapped from the user emails as the user IDs in Jira. +###### Note @@ -16,0 +17 @@ The Jira user IDs are mapped as follows: +For all types of projects, you must have at least 'Browse Projects' permissions (direct or indirect), and Email visibility must be set to "Anyone" for AWS to validate permissions correctly. The "Anyone" email visibility setting is required for proper integration with AWS and other third-party tools due to Jira's API limitations. @@ -17,0 +19 @@ The Jira user IDs are mapped as follows: +**Permissions Inheritance** : Global Permissions determine who can access the Jira instance and perform high-level actions. Project Permissions, governed by permission schemes, define user access within projects, such as viewing, editing, or assigning issues. In Company-Managed Projects, permissions flow from the Jira instance down to projects and further to issues, attachments, comments, and worklogs. Issue Security Schemes further restrict access to specific issues within a project. In Team-Managed Projects, access is defined by project roles and project visibility settings: Open (accessible to all), Limited (viewable by all but editable only by members), and Private (restricted to project members). While permissions in Company-Managed Projects follow a structured hierarchy, Team-Managed Projects rely on role-based access. Inheritance applies at the project level, meaning that issues, comments, attachments, and worklogs inherit permissions from their parent project. However, Issue Security Levels can override project permissions by restricting visibility at an issue level. @@ -18,0 +21,5 @@ The Jira user IDs are mapped as follows: +**ACL Mapping** : ACL mapping rules differ between company-managed and team-managed projects. In company-managed projects, project permissions and issue-level security must be met for access. If issue-level security is disabled, only project-level permissions apply. In team-managed projects, users must meet specific conditions. Private projects require explicit role membership, while limited and open-access projects do not. The Jira connector inherits ACLs from parent entities without custom logic. The connector supports ACLs for both company-managed projects and open/limited access team-managed projects. Federated groups are treated as local groups after syncing, with no duplicate issues. Email visibility must be set to "Anyone" for user context filtering to work. Ownership does not translate to automatic access; access is granted at the project level. Admins do not need explicit ACLs on every document. Jira does not support explicit deny permissions, and shared links still require users to be part of the project. + +**Change Management** : Change Log Mode in Amazon Q Business enables incremental updates by capturing modifications made to content in Jira. Instead of re-indexing all documents, it indexes only newly added, updated, or deleted items since the last crawl. Any changes to user or group access permissions are also recorded, ensuring accurate and up-to-date indexing. + +**Failure handling** : The connector follows a fail-close approach, skipping documents from ingestion in case of API failures or permission-related issues. Please note that if a document has no ACLs attached and ACL enforcement is enabled by the admin, it will be ingested and made publicly accessible to configured users.