republishing leap 9.3.5

9.3.5/cr_import_data_in_view_responses.md

@@ -32,7 +32,7 @@ Validation and enforcement of your applications data types, required elements, a
 **Surveys** and **Select Many** items can contain values that are lists of multiple selected choices.
 
 -   Use commas to separate the selected choices.
--   In cases where one of the selected choices contains a comma, the following sequence can be used as an alternative separator: \_\_\#\_\_
+-   In cases where one of the selected choices contains a comma, the following sequence can be used as an alternative separator: __#__
 
 The data import operation stops when it encounters blank columns or rows in the spreadsheet.
 

9.3.5/helm_configure_ldap.md

@@ -4,14 +4,15 @@ To connect Leap with an LDAP you must use the [configOverrideFiles](helm_open_li
 Below is an example snippet of configuring Leap to use an LDAP server as part of a federated repository. The baseDN, bindDN and bindPassword will need to be replaced with the proper values. The searchBase for the ldap entity types will also need to be updated. The participatingBaseEntry will need to match the baseDN defined in the LDAP server snippet.
 
 Valid values for the "ldapType" are:
-- Custom
-- IBM Lotus Domino
-- IBM SecureWay Directory Server
-- IBM Tivoli Directory Server
-- Microsoft Active Directory
-- Netscape Directory Server
-- Novell eDirectory
-- Sun Java System Directory Server
+
+-   Custom
+-   IBM Lotus Domino
+-   IBM SecureWay Directory Server
+-   IBM Tivoli Directory Server
+-   Microsoft Active Directory
+-   Netscape Directory Server
+-   Novell eDirectory
+-   Sun Java System Directory Server
 
 It is recommended to specify a "realmName" as it makes it easier to reference entries from this LDAP configuration, specifically in the Leap role assignments.
 

9.3.5/helm_oidc_config.md

@@ -26,20 +26,20 @@ As part of the configuration process for your identify provider, you will have c
 
 After copying the `.key` and `.crt` to the kubernetes image, create a secret using the following command:
 
-``` {#codeblock_tjk_knt_b1c}
+```text
 kubectl -n myns create secret tls oidccert --key="/tmp/oidc.key" --cert="/tmp/oidc.crt"
 ```
 
 Next, this secret can be referenced in the yaml file:
 
-``` {#codeblock_dyx_2nt_b1c}
+```yaml
 configuration:
   leap:
     customCertificateSecrets:
       keycloakCert: "keycloakcert"
 ```
 
-For more information, see to [helm\_admin\_customsecret.md](helm_admin_customsecret.md).
+For more information, see to [Provide admin user a custom secret](helm_admin_customsecret.md).
 
 ## Add OIDC definition as a server customization {#section_vxv_fnt_b1c .section}
 
@@ -52,7 +52,7 @@ Before moving on from this step:
 
 The following snippet is an example of an OIDC definition:
 
-``` {#codeblock_b5j_jnt_b1c}
+```yaml
 configOverrideFiles:
       openIdConnect: |
         <server description="leapServer">
@@ -64,6 +64,10 @@ configOverrideFiles:
             mapIdentityToRegistryUser="false"
             httpsRequired="true"
             scope="openid"
+            <!-- Defines a simple name that can be used to refer to this OIDC config -->
+            realmName="LeapOidc"
+            <!-- The property of the token that contains the user's group assignments -->
+	          groupIdentifier="group_membership"
             userIdentityToCreateSubject="preferred_username"
             discoveryEndpointUrl="https://myoidcserver:8443/realms/Leapdev/.well-known/openid-configuration">
           </openidConnectClient>
@@ -78,7 +82,8 @@ configOverrideFiles:
         </server> 
 ```
 
-For more details on defining a server customization, see [helm\_open\_liberty\_custom.md](helm_open_liberty_custom.md).
+For more details on defining a server customization, see [Open Liberty server customizations](helm_open_liberty_custom.md).
+
 
 ## Add config properties related to OIDC config {#section_r3z_knt_b1c .section}
 
@@ -88,18 +93,44 @@ The following properties must be set to complete the OIDC configuration:
 -   userGroups - By setting this to false it will disable group lookups, which is not available when configured with OIDC.
 -   postLogoutRedirectURL - This is the URL to which Leap will redirect the browser after a user chooses to log out. This is necessary to complete the loop with the OIDC IDP.
 
-``` {#codeblock_hbq_pnt_b1c}
+```yaml
 configuration:
    leap:
      leapProperties: |
        ibm.nitro.NitroConfig.userLookup=false
        ibm.nitro.NitroConfig.userGroups=false 
-       ibm.nitro.LogoutServlet.postLogoutRedirectURL=https://myOIDCServer.com/realms/Leap/protocol/openid-
+       ibm.nitro.LogoutServlet.postLogoutRedirectURL=https://myoidcServer.com/realms/Leap/protocol/openid-
                  connect/logout?client_id=hcl-leap-oidc-client&post_logout_redirect_uri=https://myLeapServer.com/apps/secure/org/ide/manager.html
 ```
 
 For more details on setting Leap properties, see [Leap properties](helm_leap_properties.md).
 
+## Referencing Users and Groups in Security Role Mapping 
+To assign a user or group from OIDC to one of the Leap roles (AdministrativeUsers, EditApplicationUsers, UseApplicationUsers) you must use their access id.  The access id is made up of the realmName (defined in the 'openidConnectClient' definition) and the user/group name.  
+
+To assign a user from OIDC to a Leap security role you would use {realmName}/{userName}:
+```yaml
+MappedUsersAccessIDs:
+ - LeapOidc/john.oidc
+```
+
+To assign a group from OIDC to a Leap security role you would use {realmName}/{groupName}:
+```yaml
+MappedGroupsAccessIDs:
+ - LeapOidc//Group1
+```
+Note: there is an extra slash in the group name because that is part of the definition in the IDP used for this example. Other IDPs may differ in how they define the group name, if in doubt leverage the logging trace string to identify the correct value.
+
+## Troubleshooting
+To get more information about how Liberty perceives the logged in user, add the trace string 'com.ibm.ws.security.authentication.*=all'.  This will provide useful information for understanding the user and group values.  An example output in the trace.log, after logging in, looks like:
+
+```text
+    Principal: WSPrincipal:john.oidc
+    Public Credential: com.ibm.ws.security.credentials.wscred.WSCredentialImpl@cb847b2d,realmName=LeapOidc,securityName=john.oidc,realmSecurityName=LeapOidc/john.oidc,uniqueSecurityName=john.oidc,primaryGroupId=null,accessId=user:LeapOidc/john.oidc,groupIds=[group:LeapOidc//Group2]
+    Private Credential: IDToken:{"exp":1710363581,"iat":1710363281,"auth_time":1710363280,"jti":"f343b1fe-6a9a-482f-a85e-1cf46f4eb1b8","iss":"https://myoidcserver:8443/realms/Leapdev","aud":"hcl-leap-oidc-client","sub":"9b8cd571-5d09-4de2-ba2d-22b985424831","typ":"ID","azp":"hcl-leap-oidc-client","session_state":"fff63a5e-8269-4e69-b4c3-9d4135c028da","at_hash":"ePO9yDI6IGdX1iDG17CNWQ","acr":"1","sid":"fff63a5e-8269-4e69-b4c3-9d4135c028da","group_membership":["/Group2"],"email_verified":false,"realmName":"Leapdev","name":"John Oidc","groups":["default-roles-leapdev","offline_access","uma_authorization"],"preferred_username":"john.oidc","given_name":"John","family_name":"Oidc","email":"[email protected]"} 
+```
+Note: If the groupIds array is empty then the 'openidConnectClient' is not configured properly; the group claim may be missing from the token or the 'groupIdentifier' may not be set to the correct value.
+
 ## Restart the pod {#section_zq2_vmt_b1c .section}
 
 After restarting the Leap pod, accessing Leap should redirect you to authenticate using your OIDC IDP.

9.3.5/helm_open_liberty_custom.md

@@ -2,7 +2,7 @@
 
 The configOverrideFiles parameter allows configuration snippets to be passed to the Leap server.
 
-The snippets are merged into the Open Liberty server.xml. After making changes to the .yaml, apply them using the helm upgrade ... command. Changes are picked up by Open Liberty and applied at runtime - this does not require a restart.
+The snippets are merged into the Open Liberty server.xml. After making changes to the .yaml, apply them using the `helm upgrade ...` command. Changes are picked up by Open Liberty and applied at runtime - this does not require a restart.
 
 **Note:** The name of the customization \(myCustomOverride1 in the following snippet\) can be any string, but you may want it to be descriptive of what is being provided.
 

9.3.5/in_basic_architecture.md

@@ -4,7 +4,7 @@ Leap relies on two central components: the application server and the database.
 
 Leap relies on two central components: the application server and the database. The following diagram shows how these components are set up in a typical installation:
 
-![A diagram that shows basic Leaparchitecture.](graphics/basic_overview_v30.gif)
+![A diagram that shows basic Leap architecture.](graphics/basic_overview_v30.gif)
 
 The components perform the following functions:
 

9.3.5/in_upgrading.md

@@ -6,8 +6,8 @@ The following instructions describe how to upgrade Leap by using the WebSphere®
 -   Back up your existing installation prior to installing the update.
 -   Back up your DB2® or Oracle database before you install the update.
 
-1.  To back up your current Leap installation:
-2.  Export the Leap EAR file.
+To back up your current Leap installation:
+1.  Export the Leap EAR file.
 
     1.  Open the WebSphere Application Server Administrative console.
 
@@ -19,23 +19,23 @@ The following instructions describe how to upgrade Leap by using the WebSphere®
 
     5.  Click Leap.ear to download the installation file as a backup.
 
-3.  After the backup is complete, use the following instructions to install the upgrade file.
+2.  After the backup is complete, use the following instructions to install the upgrade file.
 
-4.  Stop the Leap server.
+3.  Stop the Leap server.
 
     1.  Go to **Applications** \> **Application Types** \> **WebSphere enterprise applications**
 
     2.  Select Leap, and click **Stop**.
 
-5.  Check the version of your currently installed Leap.
+4.  Check the version of your currently installed Leap.
 
     You need the version number in step 4c.
 
     1.  Go to **Modules** \> **Display module build Ids**.
 
     2.  Check the version for the HCL Leap WAR. An example module version is  “Leap 9.0.0.0 GA”.
 
-6.  Update the Leap installation.
+5.  Update the Leap installation.
 
     1.  Return to **Applications** \> **Application Types** \> **WebSphere enterprise applications** \> **Leap**, and click **Update**.
 
@@ -59,36 +59,36 @@ The following instructions describe how to upgrade Leap by using the WebSphere®
 
     9.  Click **Finish** to save the update.
 
-7.  If Leap is running on nodes that are managed by Deployment Manager, you must synchronize all nodes where Leap is installed.
+6.  If Leap is running on nodes that are managed by Deployment Manager, you must synchronize all nodes where Leap is installed.
 
-8.  Open the WebSphere Application Server Administrative console.
+7.  Open the WebSphere Application Server Administrative console.
 
-9.  Go to **System Administration** \> **Nodes**.
+8.  Go to **System Administration** \> **Nodes**.
 
-10. Select all nodes where Leap is installed.
+9. Select all nodes where Leap is installed.
 
-11. Click **Synchronize**.
+10. Click **Synchronize**.
 
-12. When the upgrade is complete, restart the Leap server.
+11. When the upgrade is complete, restart the Leap server.
 
-13. Go to **Applications** \> **Application Types** \> **WebSphere enterprise applications**
+12. Go to **Applications** \> **Application Types** \> **WebSphere enterprise applications**
 
-14. Select Leap.
+13. Select Leap.
 
-15. Click **Start**.
+14. Click **Start**.
 
-16. If you use Leap with WebSphere Portal, you must update the Leap Portlet.
-17. Log in to WebSphere Portal as an administrative user.
+15. If you use Leap with WebSphere Portal, you must update the Leap Portlet.
+16. Log in to WebSphere Portal as an administrative user.
 
-18. Go to **Portlet Management** \> **Web Modules** and locate LeapPortlet.war.
+17. Go to **Portlet Management** \> **Web Modules** and locate LeapPortlet.war.
 
-19. Click the **Update Web module** icon.
+18. Click the **Update Web module** icon.
 
     The **Update Web module** icon is located to the right of the **Web module properties** icon.
 
-20. Click **Browse** to select the updated version of the Leap Portlet, and click **Next**.
+19. Click **Browse** to select the updated version of the Leap Portlet, and click **Next**.
 
-21. Review your changes and click **Finish**.
+20. Review your changes and click **Finish**.
 
 
 **Parent topic: **[Upgrading](upgradingleap_sec.md)

9.3.5/migrating_websphere_liberty.md

@@ -8,9 +8,9 @@ The most common parts of a Leap deployment are the following:
 -   LDAP
 -   Mail server
 
-Each of these three parts are external to Leap and will be configured in the deploy-values.yaml file as described in [Customized deployment](openliberty_customized_deploy.md). Since the database contains all the Leap applications, once it is connected to Leap 9.3.2 on Open Liberty they will be accessible.
+Each of these three parts are external to Leap and will be configured in the deploy-values.yaml file as described in [Customized deployment](openliberty_customized_deploy.md). Since the database contains all the Leap applications, once it is connected to Leap on Open Liberty they will be accessible.
 
-**Note:** Once the database has been connected to version 9.3.2, it will no longer work for Leap 9.3.1.
+**Note:** Once the database has been connected to the latest version of Leap, it will no longer work for previous versions.
 
 1.  Leap on Open Liberty works best if the login attribute is set to the 'mail' attribute. If your existing WebSphere deployment is using a different login attribute then some additional steps will need to be taken. All of the Leap users are identified by their login id, if the attribute for that login id changes then when a user authenticates with Leap on Open Liberty for the first time \(using their mail attribute\) they would be seen as a new user and not automatically associated with their previous account. In this case you will need to manually update all the users in the FREEDOM.USERS table \(before allowing them to access the system\), changing their LOGIN\_ID value to the value of their email address.
 
@@ -20,9 +20,9 @@ Each of these three parts are external to Leap and will be configured in the dep
     UPDATE FREEDOM.USERS SET LOGIN_ID = '<email of user>' WHERE LOGIN_ID = '<old login attribute>';
     ```
 
-2.  The new Open Liberty image and associated Helm charts for Leap 9.3.2 are not backward-compatible with Leap 9.3.1. Do not use the same values.yaml file for Helm that you may have used with Leap 9.3.1.
-3.  Customizations applied through the WebSphere Application Server admin console, may need to be reapplied using snippets of XML according to Open Liberty's configuration technique \(see [https://openliberty.io/docs/latest/reference/config/server-configuration-overview.html](https://openliberty.io/docs/latest/reference/config/server-configuration-overview.html).)\). This additional configuration can be supplied as "overrides" in Leap 9.3.2's Helm charts. For more information, see [Customized deployment](openliberty_customized_deploy.md).
-4.  The persistent volumes defined for use with the Leap 9.3.1 container are not the same for Leap 9.3.2. When upgrading to Leap 9.3.2, create new persistent volumes. For more information, see [Prerequisite - Specifying persistant volumes](deploy_container_kubernetes_openliberty.md#section_f4f_24s_gxb).
+2.  The Open Liberty image and associated Helm charts for Leap are not backward-compatible with any previous versions of Leap. Do not use the same values.yaml file for Helm that you may have used with a previous version of Leap.
+3.  Customizations applied through the WebSphere Application Server admin console, may need to be reapplied using snippets of XML according to Open Liberty's configuration technique \(see [Server configuration overview](https://openliberty.io/docs/latest/reference/config/server-configuration-overview.html)). This additional configuration can be supplied as "overrides" in Leap's Helm charts. For more information, see [Customized deployment](openliberty_customized_deploy.md).
+4.  The persistent volumes defined for use with previous Leap containers are not the same for current Leap containers. When upgrading Leap, create new persistent volumes. For more information, see [Prerequisite - Specifying persistant volumes](deploy_container_kubernetes_openliberty.md#section_f4f_24s_gxb).
 
 **Parent topic: **[Kubernetes Helm deployment](kubernetes_helm_deployment.md)