Editing access management files for DITA

downstream/assemblies/platform/assembly-gw-mapping.adoc

@@ -18,9 +18,9 @@ include::platform/con-gw-authenticator-map-examples.adoc[leveloffset=+1]
 
 include::platform/proc-gw-allow-mapping.adoc[leveloffset=+1]
 
-include::platform/ref-controller-organization-mapping.adoc[leveloffset=+1]
+include::platform/proc-controller-organization-mapping.adoc[leveloffset=+1]
 
-include::platform/ref-controller-team-mapping.adoc[leveloffset=+1]
+include::platform/proc-controller-team-mapping.adoc[leveloffset=+1]
 
 include::platform/proc-gw-role-mapping.adoc[leveloffset=+1]
 

downstream/modules/platform/con-gw-authenticator-map-examples.adoc

@@ -6,7 +6,8 @@
 
 Use the following examples to explore the different conditions, like groups and attribute values you can implement to control user access to the platform. 
 
-.Add users to an organization based on an attribute
+*Add users to an organization based on an attribute*
+
 In this example, you will add a user to the *Networking* organization if they have an `Organization` attribute with the value of `Networking`:
 
 image::am-org-mapping-full-annotation.png[Add users to an organization mapping example fully annotated with callout numbers that correlate with the following list that describes the function of each field]
@@ -21,7 +22,8 @@ image::am-org-mapping-full-annotation.png[Add users to an organization mapping e
 . The name of the *Organization* to which you are adding members is `Networking`.
 . Users are added to the *Networking* organization with the `Organization Member` role.
 
-.Add users to a team based on the users group
+*Add users to a team based on the users group*
+
 In this example, you will add user to the `Apple` team if they have either of the following  groups:
 
 -----
@@ -36,13 +38,13 @@ cn=Operators,ou=AAP,ou=example,co=com
 
 image::am-apple-team-map-example.png[Add user to a team mapping example]
 
-.Do not escalate privileges
+*Do not escalate privileges*
 
 In this example, you never escalate users to a superuser. But note, this rule does not revoke a user’s superuser permission because the revoke option is not set. 
 
 image::am-do-not-escalate-privileges.png[Do not escalate privileges mapping example]
 
-.Escalate privileges based on a user having a group
+*Escalate privileges based on a user having a group*
 
 In this example, you escalate user privileges to superuser if they belong to the following group:
 
@@ -52,7 +54,7 @@ cn=Administrators,ou=AAP
 
 image::am-escalate-privileges.png[Escalate privileges mapping example]
 
-.Using mapping order to create exceptions
+*Using mapping order to create exceptions*
 
 Since maps are executed in order, it is possible to create exceptions. Expanding on the previous example for __Do not escalate privileges__, you can add another rule with a higher order, such as, __Escalate privileges__. 
 

downstream/modules/platform/con-gw-authenticator-map-triggers.adoc

@@ -28,15 +28,15 @@ See the *Operation* field to determine the behavior of the trigger if more than
 Group identifiers must be entered in lowercase. For example, `cn=johnsmith,dc=example,dc=com` instead of `CN=johnsmith,DC=example,DC=com`.
 ====
 +
-Attribute:: The map is true or false based on a users attributes coming from the source system. See link:{URLCentralAuth}/gw-configure-authentication#gw-authenticator-map-examples[Authenticator map examples] for information on using *Attribute* triggers.
+Attribute:: The map is true or false based on a users attributes coming from the source system. See link:{URLCentralAuth}/gw-configure-authentication#gw-authenticator-map-examples[Authenticator map examples] for information about using *Attribute* triggers.
 +
 When defining an attribute trigger, the authentication mapping expands to include the following selections:
 +
 * *Operation:* This field includes conditional settings that trigger the handling of the rule based on the specified *Attribute* criteria. In version {PlatformVers} this field indicates what will happen if the source system returns a list of  attributes instead of a single value. For example, if the source system returns multiple emails for a user and *Operation* was set to *and*, all of the given emails must match the *Comparison* for the trigger to be _True_. If *Operation* was set to *or*, any of the returned emails will set the trigger to _True_ if they match the *Comparison* in the trigger. 
 +
 [NOTE]
 ====
-If you would like to experiment with multiple attribute maps you can do that through the API but the UI form will remove multi-attribute maps if the authenticator is saved through the UI. When adding multiple attributes to a map, the *Operation* will also apply to the attributes.
+If you want to experiment with multiple attribute maps you can do that through the API but the UI form will remove multi-attribute maps if the authenticator is saved through the UI. When adding multiple attributes to a map, the *Operation* will also apply to the attributes.
 ====
 +
 * *Attribute:* The name of the attribute coming from the source system this trigger will be evaluated against. For example, if you wanted the trigger to fire based on the user's last name and the last name field in the source system was called `users_last_name` you would enter the value ‘users_last_name’ in this field.
@@ -46,10 +46,10 @@ If you would like to experiment with multiple attribute maps you can do that thr
 ** *matches*: The *Value* on the trigger is treated as a python regular expression and does an link:https://docs.python.org/3/library/re.html#re.match[Regular expression match (re.match)] (with case ignore on) between the specified *Value* and the value returned from the source system. For example, if the trigger's *Value* was ‘Jo’ the trigger would return _True_ if the value from the source was ‘John‘ or ‘Joanne‘ or any other value which matched the regular expression ‘Jo’. The trigger would return _False_ if the sources value for the attribute was ‘Dan’ because ‘Dan’ does not match the regular expression ‘Jo’. 
 ** *ends with*: The trigger will see if the value provided by the source ends with the specified *Value* of the trigger. For example, if the source provided a value of ‘John’ the trigger would be _True_ if its *Value* was set to ‘n’ or ‘on’. The trigger would be _False_ if its *Value* was set to ‘z’ because the value ‘John’ coming from the source does not end with the value ’z’ specified by the trigger.
 ** *equal*: The trigger will see if the value provided by the source is equal to (in its entirety) the specified *Value* of the trigger. For example, if the source returned the value ‘John’, the trigger would be _True_ if its *Value* was set to ‘John’. Any value other than ‘John’ returned from the source would set this trigger to _False_.
-** *in*: The *in* condition will see if the value matches one of several values. When *in* is specified as the *Comparison*, the *Value* field can be a comma separated list. For example, if a trigger had a *Value* of ‘John,Donna’ the trigger would be _True_ if the attribute coming from the source had either the value ‘John’ or ‘Donna’. Otherwise, the trigger would be _False_.
+** *in*: The *in* condition checks if the value matches one of several values. When *in* is specified as the *Comparison*, the *Value* field can be a comma-separated list. For example, if a trigger had a *Value* of ‘John,Donna’ the trigger would be _True_ if the attribute coming from the source had either the value ‘John’ or ‘Donna’. Otherwise, the trigger would be _False_.
 ** *Value*: The value that a users attribute will be matched against based on the *Comparison* field. See examples in the *Comparison* definition in this section. 
 +
 [NOTE]
 ====
-If the *Comparison* type is *in*, this field can be a comma separated list (without spaces).
+If the *Comparison* type is *in*, this field can be a comma-separated list (without spaces).
 ====

downstream/modules/platform/con-gw-authenticator-map-types.adoc

@@ -6,7 +6,7 @@
 
 {PlatformNameShort} supports the following rule types:
 
-Allow:: Determine if the user is allowed to log into the system.
+Allow:: Determine if the user is allowed to log in to the system.
 Organization:: Determine if a user should be put into an organization.
 Team:: Determine if the user should be a member of a team.
 Role:: Determine if the user is a member of a role (for example, _System Auditor_).

downstream/modules/platform/con-gw-understanding-authenticator-mapping.adoc

@@ -4,7 +4,7 @@
 
 = Understanding authenticator mapping
 
-Authentication:: Validates a user’s identity, typically through a username and password or a trust system.
+Authentication:: Validates a user's identity, typically through a username and password or a trust system.
 Authorization:: Determines what an authenticated user can do once they are authenticated. 
 
 In {PlatformNameShort}, authenticators manage authentication, validating users and returning details such as their username, first name, email, and group memberships (for example, LDAP groups). Authorization comes from the authenticator’s associated maps.

downstream/modules/platform/proc-aap-enable-disable-auth.adoc

@@ -15,13 +15,13 @@ Dependency on enterprise authentication provider:: If the local authenticator is
 * You have at least one other authenticator method configured. 
 * You have at least one administrator account that can authenticate using your alternate authenticator.
 
-.Procedure
-
 [CAUTION]
 ====
 Disabling the local authenticator without an alternative authentication in place can result in a locked environment. 
 ====
 
+.Procedure
+
 . From the navigation panel, select {MenuAMAuthentication}.
 . Ensure that at least one other authenticator type is configured and enabled.
 . Select your *Local Authenticator*.

downstream/modules/platform/proc-controller-apps-create-tokens.adoc

@@ -51,4 +51,4 @@ You can verify that the application now shows the user with the appropriate toke
 Your token should be displayed in the list of tokens associated with the application you chose.
 
 .Additional resources
-If you are a system administrator and have to create or remove tokens for other users, see the revoke and create commands in xref:ref-controller-token-session-management[Token and session management].
+* xref:ref-controller-token-session-management[Token and session management]

downstream/modules/platform/ref-controller-organization-mapping.adoc → downstream/modules/platform/proc-controller-organization-mapping.adoc

@@ -1,6 +1,6 @@
 :_mod-docs-content-type: PROCEDURE
 
-[id="ref-controller-organization-mapping"]
+[id="proc-controller-organization-mapping"]
 
 = Organization mapping
 

downstream/modules/platform/ref-controller-team-mapping.adoc → downstream/modules/platform/proc-controller-team-mapping.adoc

@@ -1,16 +1,16 @@
 :_mod-docs-content-type: PROCEDURE
 
-[id="ref-controller-team-mapping"]
+[id="proc-controller-team-mapping"]
 
 = Team mapping
 
 Team mapping is the mapping of team members (users) from authenticators. 
 
-You can define the options for each team’s membership. For each team, you can specify which users are automatically added as members of the team and also which users can administer the team.
+You can define the options for each team's membership. For each team, you can specify which users are automatically added as members of the team and also which users can administer the team.
 
 Team mappings can be specified separately for each account authentication.
 
-When Team mapping is positively evaluated, a specified team and its organization are created, if they don’t exist if the related authenticator is allowed to create objects.
+When Team mapping is positively evaluated, a specified team and its organization are created, if they don't exist if the related authenticator is allowed to create objects.
 
 
 .Procedure
@@ -19,7 +19,7 @@ When Team mapping is positively evaluated, a specified team and its organization
 . Select *Team* from the *Add authentication mapping* list. 
 . Enter a unique rule *Name* to identify the rule.
 . Select a *Trigger* from the list. See xref:gw-authenticator-map-triggers[Authenticator map triggers] for more information about map triggers.
-. Select *Revoke* to remove the user’s access to the selected organization role and deny user access to the system when the trigger conditions are not matched. 
+. Select *Revoke* to remove the user's access to the selected organization role and deny user access to the system when the trigger conditions are not matched. 
 . Select the *Team* and *Organization* to which matching users are added or blocked.
 . Select a *Role* to be applied or removed for matching users (for example, *Team Admin* or *Team Member*).
 . Click btn:[Next].

downstream/modules/platform/proc-gw-allow-mapping.adoc

@@ -1,4 +1,4 @@
-:_mod-docs-content-type: CONCEPT
+:_mod-docs-content-type: PROCEDURE
 
 [id="gw-allow-mapping"]
 

downstream/modules/platform/proc-gw-role-mapping.adoc

@@ -6,7 +6,7 @@
 
 Role mapping is the mapping of a user either to a global role, such as Platform Auditor, or team or organization role.
 
-When a Team and/or Organization is specified together with the appropriate Role, the behavior is identical with Organization mapping or Team mapping. 
+When a Team or Organization is specified together with the appropriate Role, the behavior is identical with Organization mapping or Team mapping. 
 
 Role mapping can be specified separately for each account authentication.
 

downstream/modules/platform/ref-controller-token-session-management.adoc

@@ -7,9 +7,14 @@
 {PlatformNameShort} supports the following commands for OAuth2 token management:
 
 * xref:ref-controller-create-oauth2-token[`create_oauth2_token`]
+
 * xref:ref-controller-revoke-oauth2-token[`revoke_oauth2_tokens`]
+
 * xref:ref-controller-clear-sessions[`cleartokens`]
+
 //[emcwhinn - Temporarily hiding expire sessions module as it does not yet exist for gateway as per AAP-35735]
 //* xref:ref-controller-expire-sessions[`expire_sessions`]
+
 * xref:ref-controller-clear-sessions[`clearsessions`]
 
+