Login to xFlow fails without any errors or stuck in an infinite loading state
Article ID: 207304
Updated On:
Products
Issue/Introduction
End user is trying to login to xFlow. During the login attempt, the end user will be deposited back into the login page, without any errors presented at the web browser.
In situations where there is Single Sign On, there may be repeated attempts to login to xFlow, which may look like a screen that is in an infinite loading state
Logging may indicate the following:
incidentMS.log
[c.c.c.a.AuthenticationInterceptor] - Changing role from 10008 to 10005
[c.c.c.a.AuthenticationInterceptor] - Exception changing role in SDM Server.
java.util.concurrent.ExecutionException: com.ca.casm.exception.CasmBaseException: Failed to change role: 'change_role' request failed; role_id=10005 not valid for userid=<userid>, session_id=<sessionID> and session_type=12
at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
at com.ca.casm.authentication.AuthenticationInterceptor$1.delegateController(AuthenticationInterceptor.java:609)
at com.ca.casm.authentication.AuthenticationInterceptor$1.lambda$null$3(AuthenticationInterceptor.java:271)
at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
Caused by: com.ca.casm.exception.CasmBaseException: Failed to change role: 'change_role' request failed; role_id=10005 not valid for userid=<userid>, session_id=<sessionID> and session_type=12
at com.ca.casm.actor.helper.SdmBoplginMethodHelper.lambda$changeRole$4(SdmBoplginMethodHelper.java:333)
at java.base/java.util.function.BiConsumer.lambda$andThen$0(BiConsumer.java:72)
at java.base/java.util.function.BiConsumer.lambda$andThen$0(BiConsumer.java:71)
at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
In the case of a user experiencing an infinite loading state for login, usually due to Single Sign On or SSO (user goes straight into the application without having to keyboard their credentials), the above error repeats every second. As it is not possible for any human to key in their user credentials in such a a short time span, this indicates repeated login attempts via Single Sign On.
Environment
Release : 17.x
Component : SERVICE DESK MANAGER xFlow
Cause
The issue arises because the user's defined access type has a set of roles which do not match any of the roles in the selected Apps.
Breaking down the above error, we see that there are two roles in play:
Querying the usp_role table to locate the roles whose id values are 10008 and 10005, we find:
TABLE usp_role
id code name
{ "10005" ,"Employee" ,"Employee" }
{ "10008" ,"L1Analyst" ,"Level 1 Analyst" }
Examining the Access Type assigned to the "testuser1" userid, the Access Type is "Tier 1". In the "Tier 1" access type, under Roles tab, there is just the one entry in the Attached Role List, "Level 1 Analyst".
If one then goes into the Apps tab in the given Access Type and selects the default App in place, Service Point:
We see the Attached Roles defined for the Service Point Application on the Tier 1 Access Type and that it is tied to the "Employee" Role.
Resolution
What happens is that when the user tries to login to xFlow, the Access Type configuration is trying to leverage a role that is tied to the App selection, but it is a role that the Access Type does not have access to.
There are two options to address the issue. It is not necessary to apply both options as either one essentially syncs the Role listings between the given Access Type and the assigned Apps.
Using the above as the running example
Option 1 (recommended): Change the default role per app. In each of the above Apps (access by going into the Security/Role Management menu, select Access Types, select the "Tier 1" access type, and select the Apps tab), add the "Level 1 Analyst" as the default role for the App.
Option 2: Add the missing role into the "Tier 1" access type. Go through each of the above Apps (access by going into the Security/Role Management menu, select Access Types, select the "Tier 1" access type, and select the Apps tab), take note of each app's default role listings, in this case I found that the "Employee" role was listed in the given apps, and add the given "Employee" role to the Access Type.
Feedback
