KEYCLOAK-16186-2 modularizes files (#39)

server_admin/topics/roles.adoc

@@ -1,4 +1,14 @@
-== Roles
+== Roles and Groups
 A role typically applies to one type of user. Typical roles in an organization include `Admin`, `user`, `manager`, and `employee`. An application can assign access and permissions to a role and then assign multiple users to that role so the users share the same access and permissions. For example, the Admin Console has roles that give permission to users to access parts of the Admin Console.
 
 There is a global namespace for roles and each client also has its own dedicated namespace where roles can be defined. 
+
+include::roles/proc-creating-realm-roles.adoc[]
+include::roles/con-client-roles.adoc[]
+include::roles/proc-converting-composite-roles.adoc[]
+include::roles/proc-assigning-role-mappings.adoc[]
+include::roles/con-default-roles.adoc[]
+include::roles/con-role-scope-mappings.adoc[]
+include::roles/proc-managing-groups.adoc[]
+include::roles/con-comparing-groups-roles.adoc[]
+include::roles/proc-specifying-default-groups.adoc[]

server_admin/topics/roles/con-client-roles.adoc

@@ -1,3 +1,5 @@
-=== Client Roles
+[id="con-client-roles_{context}"]
 
+=== Client Roles
+[role="_abstract"]
 Client roles are namespaces dedicated to clients. Each client gets its own namespace. Client roles are managed under the `Roles` tab for each client. You interact with this UI the same way you do for realm-level roles.

server_admin/topics/roles/con-comparing-groups-roles.adoc

@@ -1,7 +1,7 @@
+[id="con-comparing-groups-roles_{context}"]
 
-
-=== Groups vs. Roles
-
+==== Groups vs. Roles
+[role="_abstract"]
 Groups and roles have some similarities and differences. In {project_name}, groups are a collection of users to apply roles and attributes. Roles define types of users and applications assign permissions and access control to roles.
 
 <<_composite-roles,Composite Roles>> are similar to Groups as they provide the same functionality. The difference between them is conceptual.

server_admin/topics/roles/con-default-roles.adoc

@@ -1,6 +1,8 @@
+[id="con-default-roles_{context}"]
+
 [[_default_roles]]
 ==== Default Roles
-
+[role="_abstract"]
 Default roles allow you to automatically assign user role mappings when any user is newly created or imported through
 <<_identity_broker, Identity Brokering>>.
 To specify default roles go to the `Roles` left menu item, and click the `Default Roles` tab or alternatively you can 

server_admin/topics/roles/con-role-scope-mappings.adoc

@@ -1,7 +1,9 @@
+[id="con-role-scope-mappings_{context}"]
+
 [[_role_scope_mappings]]
 
 === Role Scope Mappings
-
+[role="_abstract"]
 On creation of an OIDC access token or SAML assertion, the user role mappings become claims within the token or assertion.  Applications use these claims to make access decisions on the resources controlled by the application.  {project_name} digitally signs access tokens and applications re-use them to invoke remotely secured REST services.  However, these tokens have an associated risk. An attacker can obtain these tokens and use their permissions to compromise your networks. To prevent this situation, use _Role Scope Mappings_.
 
 _Role Scope Mappings_ limit the roles declared inside an access token.  When a client requests a user authentication, the access token they receive contains only the role mappings that are explicitly specified for the client's scope.  The result is that you limit the permissions of each individual access token instead of giving the client access to all the users permissions.  

server_admin/topics/roles/proc-assigning-role-mappings.adoc

@@ -1,6 +1,7 @@
+[id="proc-assigning-role-mappings_{context}"]
 
 === User Role Mappings
-
+[role="_abstract"]
 You can assign User role mappings to a user through the `Role Mappings` tab for that user.
 
 .Procedure

server_admin/topics/roles/proc-converting-composite-roles.adoc

@@ -1,7 +1,9 @@
+[id="proc-converting-composite-roles_{context}"]
+
 [[_composite-roles]]
 
 === Composite Roles
-
+[role="_abstract"]
 Any realm or client level role can be a _composite role_. A _composite role_ is a role that has one or more additional roles associated with it. When a composite role is mapped to a user, the user also gains the roles associated with that composite.  This inheritance is recursive so users also inherit any composite of composites. However, we recommend that composite roles are not overused.
 
 To convert a role to a composite role:

server_admin/topics/roles/proc-creating-realm-roles.adoc

@@ -1,5 +1,7 @@
+[id="proc-creating-realm-roles_{context}"]
 
 === Realm Roles
+[role="_abstract"]
 Realm-level roles are a namespace for defining your roles. To see the list of roles, click `Roles` in the left menu.
 
 image:{project_images}/roles.png[]

server_admin/topics/roles/proc-managing-groups.adoc

@@ -1,6 +1,6 @@
-
-== Groups
-
+[id="proc-managing-groups_{context}"]
+=== Groups
+[role="_abstract"]
 Groups in {project_name} manage a common set of attributes and role mappings for each user. Users can be members of any number of groups and inherit the attributes and role mappings assigned to each group.
 
 To manage groups, click `Groups` in the left menu.

server_admin/topics/roles/proc-specifying-default-groups.adoc

@@ -1,6 +1,7 @@
+[id="proc-specifying-default-groups_{context}"]
 
-=== Default Groups
-
+==== Default Groups
+[role="_abstract"]
 To automatically assign group membership to new users, that are created or imported through <<_identity_broker, Identity Brokering>>, you use default groups.
 
 To specify default groups: