added instructions to docs for adding custom user roles (#6652)

distribution/docs/src/main/resources/content/_architectures/_data/data-intro.adoc

@@ -90,7 +90,7 @@ Consult the documentation of the Catalog Provider in use for more information on
 ====
 
 Often, the `BASIC_METACARD` `MetacardType` does not provide all the functionality or attributes necessary for a specific task.
-For performance or convenience purposes, it may be necessary to create custom attributes even if others are be aware of those attributes.
+For performance or convenience purposes, it may be necessary to create custom attributes even if others are not aware of those attributes.
 One example could be if a user wanted to optimize a search for a date field that did not fit the definition of `CREATED`, `MODIFIED`, `EXPIRATION`, or `EFFECTIVE`.
 The user could create an additional `java.util.Date` attribute in order to query the attribute separately.
 

distribution/docs/src/main/resources/content/_architectures/_plugins/filter-plugin.adoc

@@ -59,7 +59,7 @@ Each type of metacard must have its own `PolicyPlugin` that reads the metadata b
 
 In the above example, the user's claims are represented very simply and are similar to how they would actually appear in a SAML 2 assertion.
 Each of these user (or subject) claims is converted to a `KeyValuePermission` object.
-These permission objects is implied against the permission object generated from the metacard record.
+These permission objects are implied against the permission object generated from the metacard record.
 In this particular case, the metacard might be allowed if the policy is configured appropriately because all of the permissions line up correctly.
 
 == Installing the Filter Plugin

distribution/docs/src/main/resources/content/_managing/_configuring/restricting-app-access.adoc

@@ -0,0 +1,37 @@
+:title: Restricting Access to Features, Apps, Services, and Configurations
+:type: configuration
+:status: published
+:parent: Configuring User Access
+:summary: Restricting User Access to Features, Apps, Services, and Configurations
+:order: 051
+
+== {title}
+((({title})))
+
+* *{hardening-step}*
+
+Limit access to the individual applications, features, or services to those users who need access.
+Organizational requirements should dictate which applications are restricted and the extent to which they are restricted.
+
+. Navigate to the *${admin-console}*.
+. Select the *${ddf-admin}* application.
+. Select the *Configuration* tab.
+. Select the *Admin Configuration Policy*.
+. To add a feature or app permission:
+.. Add a new field to "Feature and App Permissions" in the format of:
++
+`<feature name>/<app name> = "attribute name=attribute value","attribute name2=attribute value2", ...`
++
+.. For example, to restrict access of any user without an admin role to the catalog-app:
++
+`catalog-app = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role=admin", ...`
++
+. To add a configuration permission:
+.. Add a new field to "Configuration Permissions" in the format of:
++
+`configuration id = "attribute name=attribute value","attribute name2=attribute value2", ...`
+.. For example, to restrict access of any user without an admin role to the Web Context Policy Manager:
++
+`org.codice.ddf.security.policy.context.impl.PolicyManager="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role=admin"`
+
+If a permission is specified, any user without the required attributes is unable to see or modify the feature, app, or configuration.

distribution/docs/src/main/resources/content/_managing/_configuring/securing-admin-console.adoc

@@ -2,7 +2,7 @@
 :type: configuration
 :status: published
 :parent: Configuring User Access
-:summary: Introduction to the ${admin-console}.
+:summary: Restricting User Access to ${admin-console}
 :order: 05
 
 == {title}
@@ -23,33 +23,3 @@ To set access restrictions on the ${admin-console}, consult the organization's s
 .. If your infrastructure supports multiple <<{reference-prefix}org.codice.ddf.security.policy.context.impl.PolicyManager,authentication methods>>, you may specify them here.
 .. Role requirements may be enforced by configuring the <<{reference-prefix}org.codice.ddf.security.policy.context.impl.PolicyManager,required attributes>> for a given context.
 .. The <<{reference-prefix}org.codice.ddf.security.policy.context.impl.PolicyManager,white listed contexts>> allows child contexts to be excluded from the authentication constraints of their parents.
-
-=== Restricting Feature, App, Service, and Configuration Access
-
-* *{hardening-step}*
-
-Limit access to the individual applications, features, or services to those users who need access.
-Organizational requirements should dictate which applications are restricted and the extent to which they are restricted.
-
-. Navigate to the *${admin-console}*.
-. Select the *${ddf-admin}* application.
-. Select the *Configuration* tab.
-. Select the *Admin Configuration Policy*.
-. To add a feature or app permission:
-.. Add a new field to "Feature and App Permissions" in the format of:
-+
-`<feature name>/<app name> = "attribute name=attribute value","attribute name2=attribute value2", ...`
-+
-.. For example, to restrict access of any user without an admin role to the catalog-app:
-+
-`catalog-app = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role=admin", ...`
-+
-. To add a configuration permission:
-.. Add a new field to "Configuration Permissions" in the format of:
-+
-`configuration id = "attribute name=attribute value","attribute name2=attribute value2", ...`
-.. For example, to restrict access of any user without an admin role to the Web Context Policy Manager:
-+
-`org.codice.ddf.security.policy.context.impl.PolicyManager="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role=admin"`
-
-If a permission is specified, any user without the required attributes is unable to see or modify the feature, app, or configuration.

distribution/docs/src/main/resources/content/_managing/_securing/hardening-checklist.adoc

@@ -22,7 +22,8 @@ To harden a new system, perform configuration as <<{managing-prefix}configuring,
 * [ ] <<{managing-prefix}configuring_guest_access,Configure Guest User Authentication>>
 * [ ] <<{managing-prefix}hiding_errors_and_warnings_from_users_based_on_role, Create unique user role>>
 * [ ] <<{managing-prefix}restricting_access_to_admin_console, Restricting Access to ${admin-console}>>
-* [ ] <<{managing-prefix}restricting_feature_app_service_and_configuration_access, Restrict Feature, App, Service, and Configuration Access>>
+* [ ] <<{managing-prefix}restricting_access_to_features_apps_services_and_configurations, Restricting Access to Features, Apps, Services, and Configurations
+>>
 * [ ] <<{managing-prefix}removing_default_users,Remove Default Users>>
 * [ ] <<{managing-prefix}hardening_solr,Harden Solr>>
 * [ ] <<{managing-prefix}environment_hardening,Environment Hardening>>

distribution/docs/src/main/resources/content/_quickstart/quickstart-adding-roles.adoc

@@ -0,0 +1,38 @@
+:title: Adding New User Roles
+:type: quickStart
+:level: section
+:section: quickStart
+:parent: Quick Start Tutorial
+:status: published
+:summary: Adding new user roles for limiting access to specific contexts
+:order: 03
+
+== {title}
+((({title})))
+
+Users or user groups can be customized to enable or restrict access to specific certain system functions.
+Define a custom role and assign it to users who need specific access.
+
+For an example, limit the replication admin view to users with a `sr_analyst` role.
+
+.Define a new role
+. Navigate to the ${admin-console}.
+. Navigate to the ${ddf-security} app.
+. Navigate to the *Configuration* tab.
+. Select the *Web Context Policy Manager* Configuration.
+. Select *Required Attributes*.
+. Define the contexts to be restricted.
+.. Enter `<CONTEXT>={http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role=<ROLE_NAME>`
+... For example, enter `/admin/replication={http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role=sr_analyst}`
+... Select the *+* sign to add another required attribute.
+... Enter `/admin/hub/graphql={http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role=sr_analyst}`
+
+.Assign the new role to users
+. Add the new role (`sr_analyst`) to selected users in the `users.properties` file. Add the role to the line of each chosen user.
+.. For example, `user1=password,sr_analyst`
+. Restart Alliance to apply the changes.
+.. `/app/bin/stop`
+.. `/app/bin/start`
+
+In the example given, the `/admin/replication` context is only accessible to users with the `sr_analyst` role.
+Other roles can be designated as needed by substituting the `<CONTEXT>` and the `<ROLE_NAME>` as needed.

distribution/docs/src/main/resources/content/_quickstart/quickstart-installing.adoc

@@ -20,7 +20,7 @@ For security reasons, ${branding} cannot be started from a user's home directory
 (((Quick Install Prerequisites)))
 
 .Hardware Requirements (Quick Install)
-* At least 4096 MB of memory for ${branding}.
+* At least 4096 MB of memory for ${branding}.
 ** This amount can be increased to support memory-intensive applications. See <<{managing-prefix}jvm_memory_configuration, Memory Considerations>>.
 
 .Java Requirements (Quick Install)

distribution/docs/src/main/resources/content/_reference/_tables/ContentDirectoryMonitor.adoc

@@ -47,7 +47,7 @@
 |Attribute Overrides
 |attributeOverrides
 |String
-|Optional: Metacard attribute overrides (Key-Value pairs) that can be set on the content monitor. If an attribute is specified here, it overwrited the metacard's attribute that was created from the content directory. The format should be 'key=value'. The maximum allowed size of an attribute override is 65,535 bytes. All attributes in the <<{metadata-prefix}catalog_taxonomy_definitions, catalog taxonomy tables>> are injected into all metacards by default and can be overridden.
+|Optional: Metacard attribute overrides (Key-Value pairs) that can be set on the content monitor. If an attribute is specified here, it overwrites the metacard's attribute that was created from the content directory. The format should be 'key=value'. The maximum allowed size of an attribute override is 65,535 bytes. All attributes in the <<{metadata-prefix}catalog_taxonomy_definitions, catalog taxonomy tables>> are injected into all metacards by default and can be overridden.
 |null
 |false