docs: Basic docs for Identity Center Resource Access Requests

docs/pages/admin-guides/management/guides/aws-iam-identity-center.mdx

@@ -37,15 +37,6 @@ For short-term access, users can go through Teleport's standard Access Request
 flow in which case Teleport will assign requested privileges to a particular
 user and automatically unassign once the Access Request expires.
 
-<Admonition type="note">
-The preview release of Teleport's Identity Center integration in Teleport 17.0
-supports role Access Requests only.
-
-Resource Access Requests (ability to request access to a particular permission
-set in a particular account or a particular resource) will be added in follow
-up releases.
-</Admonition>
-
 ## Prerequisites
 
 - Teleport Enterprise or Teleport Enterprise Cloud cluster version 17.0 or higher.
@@ -182,11 +173,60 @@ Clicking the "Log In" button for this app takes you to your Identity Center
 SSO start page which you can use to pick a role and connect to your AWS account
 as usual.
 
+## Background: Account Assignments
+
+The main resource that the Teleport Identity Center integration manages is the
+*Account Assignment*.
+
+An Account Assignment is the combination of a specific Permission Set on a specific
+AWS account - for example "*AdminAccess on Production*" (where *Production* is 
+an AWS account managed by Identity Center). 
+
+When a user has access to an Account Assignment in Teleport, that access is
+mirrored in AWS Identity Center. When a teleport user loses access to an Account
+Assignment in Teleport, that access is similarly deleted in AWS. 
+
+Access to Account Assignments can be granted via Teleport Roles, either directly
+to Users or through Access Lists, or by Account Assignment resources included in
+an approved Access Request.
+
 ## Usage scenarios
 
 Let's take a look at some common usage scenarios enabled by the Identity Center
 integration.
 
+### Just-In-Time Access with resource Access Requests
+
+Teleport represents the imported AWS accounts as Apps in the Teleport Resource
+View, with the permission sets available for each account bundled up inside the
+app. AWS accounts are treated the same as any other Teleport-managed resource, 
+so users can see what AWS permission sets they are allowed to request just by
+checking "Show requestable resources" in the resource view. 
+
+Users can then choose the specific Account Assignments they want access to by 
+selecting from the Permission Sets available to each AWS Account. Users
+can mix Permission Sets from multiple AWS Accounts, and even include other 
+Teleport-managed resources if necessary.
+
+![Selecting Identity Center resources](../../../../img/identity-center/ic-select-ps.png)
+
+Once the used has selected their desired Account Assignments, the Access Request
+submission and review process is the same as for any other Teleport-managed
+resource. Assuming the Access Request is approved, teleport will create the
+appropriate AWS Account Assignments in Identity Center to grant the requested
+access. These AWS Account Assignments will automatically be deleted when the
+Access Request expires.
+
+The user can access their temporary AWS Accounts and Roles from within Teleport
+by assuming the Access Request roles. 
+
+![Assumed Role granting Identity Center Account Assignments](../../../../img/identity-center/ic-role-assumed.png)
+
+<Admonition type="warning">
+The AWS Account Assignments will exist for the lifetime of the Access Request,
+regardless of when the user assumes the associated role(s).
+</Admonition>
+
 ### Managing access with Access Lists
 
 Teleport creates an Access List for each group found in the Identity Center,
@@ -195,11 +235,18 @@ configured during the initial integration enrollment flow and can be adjusted
 as necessary after the initial sync completes.
 
 Each imported Access List is automatically assigned a role (or a set of roles)
-that grant all members of that list access to a particular permission set on a
-particular AWS account based on the permissions the corresponding Identity Center
-group was assigned during the integration setup. Those roles are considered
-system roles generated by Teleport and are named using `<permission-set-name>-on-<account-name>`
-convention (e.g. `AdministratorAccess-on-my-account`).
+that grant all members of that list access to all of the Account Assignments
+assigned to the corresponding AWS Identity Center group during the integration
+setup. 
+
+These Teleport-generated roles each represent a single Account Assignment, and
+are named using `<permission-set-name>-on-<account-name>` convention (e.g.
+`AdministratorAccess-on-my-account`). 
+
+<Admonition type="warning">
+These roles are considered system roles, and any edits or updates to them will
+be automatically reverted. 
+</Admonition>
 
 To give a user permission granted by an already-existing Identity Center synced
 Access List, an owner can add that user as a member which makes Teleport to add
@@ -214,12 +261,14 @@ Removing a member from an Identity Center synced Access List removes them
 from the corresponding Identity Center group effectively revoking privileges.
 
 In addition to membership changes, Teleport propagates changes in Access List
-grants to Identity Center as well. In a scenario where, say, for an Access List
-with roles `AdministratorAccess-on-my-account` and `ReadOnlyAccess-on-my-account`
-one of the granted roles were to be removed, the corresponding Identity Center
-group would see its assignments updated accordingly.
+grants back to Identity Center as well. For example, imagine an Access List with
+the roles `AdminAccess-on-my-account` and `ReadOnlyAccess-on-my-account`. If the
+Access List owner removes the `AdminAccess-on-my-account` role from the Access Lists,
+that change will be propagated back to AWS and the corresponding Identity Center
+group will have its assignments updated to remove the `AdminAccess` Permission Set on `my-account`, leaving the `ReadOnlyAccess`
+assignment intact.
 
-### Using role Access Requests
+### Just-in-time access with role Access Requests
 
 For short-term privilege elevation, Identity Center integration works with
 Teleport Access Requests.
@@ -228,11 +277,18 @@ When an Access Request for a role granting Identity Center privileges is
 approved, Teleport creates an individual assignment for that user in the
 Identity Center. The assignment is deleted when the Access Request expires.
 
-<Admonition type="note">
-In a future version, Teleport will support requesting access to individual
-permission sets using resource-based Access Request flow similar to other
-Teleport resources.
-</Admonition>
+### Long-term access with Access Requests
+
+If a user requests access to Account Assignments that can also be granted via an
+existing Access List, Teleport will offer the reviewer the option of *promoting*
+the Access Request to long-term access.
+
+![Promoting Access Request](../../../../img/identity-center/ic-promote.png)
+
+When an Access Request is promoted to long-term access, the requesting user is
+added to the targeted Access List. This membership change is propagated to the
+corresponding Identity Center group, and the user is then granted their requested
+Account Assignments via group membership.
 
 ### Creating custom Identity Center roles
 
@@ -267,9 +323,13 @@ among their role grants to Identity Center.
 
 ### How does it work with nested Access Lists?
 
-Identity Center does not support nested groups. As such, Teleport flattens out
-the member list when syncing an Access List that has
-[nested Access Lists](../../access-controls/access-lists/nested-access-lists.mdx).
+Identity Center does not support nested groups. As such, Teleport recursively 
+flattens any [nested Access Lists](../../access-controls/access-lists/nested-access-lists.mdx)
+into a single Identity Center group containing all members reachable from the 
+top-level Access List.
+
+The flattened Identity Center group will be kept updated as members are added to
+or removed from nested 
 
 ### How do I uninstall the integration?