On a few occasions we’ve run into issues logging in to our application via CIS2 on INT as the selected_roleid item is missing from the ID token claim.
Our logs show instances of this happening just now, as well as at the following timestamps:
Is this a known issue? It makes it very difficult to troubleshoot issues in production or develop new functionality when this occurs.
Hi Felix,
selected_roleid isn’t always populated in the response - it depends on whether the user selected a role or not, which in turn depends on whether you specify the selectedrole scope.
For details, see https://digital.nhs.uk/services/care-identity-service/applications-and-services/cis2-authentication/integrate/design-and-build/role-selection.
Hi Tony,
We always specify the selectedrole scope, and on these occasions a role was selected in the identity agent.
Hi Felix, I would need the UID of the user to confirm, but there was a successful authentication at 20:44:15 on the 9th which included the selectedroleid claim. Can you DM the id_token you get back from CIS2 Auth when you see this error
Have sent two instances over, thanks
Hi @john.lister3, have you had a chance to look at the logs?
HI Felix, I’m assuming it doesn’t always happen and is specific users? It looks like there is a synchronisation issue between the data in CIS1 (ie the smartcard) and CIS2, this is rare, but can happen for various reasons especially in our test environments . Can you raise a support ticket via service now to re-sync the users involved.
Hi John,
This doesn’t always happen but frequently happens out of hours as shown in the logs, and therefore is disruptive when trying to troubleshoot an issue on prod or develop new functionality.
I will raise tickets as and when this happens in future, but ideally the root cause should be addressed so as to make INT a stable environment to develop and test on, particularly given the upcoming changes to A&G.
The users are either in sync or out of sync (for historical legacy reasons) - we have processes in place to ensure they remain in sync and treat INT as stable. Once the profiles are in sync, you won’t see the issue again and it is unlikely that the profile will become out of sync again - if you are seeing different behaviour for the same profile at different times, then we would definitely need a ticket to investigate as this is not expected behaviour. Bear in mind that INT doesn’t have any SLA in place and whilst we endeavor to ensure it is stable, is a test environment without the usual production controls in place
Hi John,
I have seen the behaviour differ for the same profile at different times - the same accounts that experienced the issue at the timestamps provided are able to log in fine currently. Can you please raise a ticket to investigate?
