chris21 accounts left open at AHG
Hoping you can direct this to the right person.
One of the administrators of Chris21 pointed something out to me yesterday. It seems that the Unify application is connecting to Chris21 and leaving behind open logins.
It appears to be the scheduled process that picks up any changes in Chris21: one login per Connector every 2 hours. So every 2 hours there are another 6 open logins created.
I'm not sure what the potential implications are - I'm trying to find out what I can from this end - but could I please ask you to check with your people as to why these logins are left open? As you can imagine the number of open logins builds up very rapidly and need to be cleared manually.
Senior Applications Developer
Automotive Holdings Group Limited
21 Old Aberdeen Place, West Perth WA 6005
P: +61 8 9422 7758
F: +61 8 9422 7686
M: 0457 524 306
Customer support service by UserEcho
AHG supplied screen shot of logged on users.
I did foresee this issue arising and raised my concerns with Frontier at time of development. The default setting for this type of login will timeout after about 3 minutes, and hence was never considered an issue.
AHG appear to be using a different setting, to possibly never timeout the logged in user, leaving them logged in indefinitely.
I will check to see if there is a way to log out the current user after each call, although I can foresee that this will also cause issues also, so I need to ensure that this mechanism works for both AHG (the indefinite logged in user), and the current method of letting the user timeout. This may require a setting in the configuration.
My last concern is priority of this issue. Have AHG actually purchased this connector yet?
I will also update the estimated time for the issue.
Assigning to Anton, priority needs to be defined.
AHG has purchased and deployed Identity Broker for chris21 v3.0.5.
E-mail from Deanna March firstname.lastname@example.org:
I'm not sure if Doug has passed this on to you yet but I thought I'd throw it your way just in case.
We have noticed that the scheduled Unify process seems to be leaving behind open logins in Chris21 and were wondering whether you might know why this is?
By the way, thanks for your help so far, I feel like we have some momentum again!
Sent to AHG in response:
I’m sorry that a response had not been sent your way, as looking at our issue tracking system the question was raised and answered by the Identity Broker for Frontier chris21 lead developer/architect.
His response was:
Do you know if any configuration change has been made for this? If not, I will see if Rodney has any further comment and whether this should be raised with Frontier.
Thank you for bringing this to my attention, and you’re welcome with regards to finding a resolution to the current issues.
Response from Deanna March email@example.com:
Thanks for your prompt response!
I'll follow up with the Chris21 experts here and see what our current settings are on that front.
I'll be in touch shortly....
I have found the required GTR request required to log-off a user:
This will require a new version. There will be an extra configuration item skipLogout="False" needed for this action to take place. The default will be skipLogout="False", to mimic current behaviour use skipLogout="True".
Once the development change is complete, I will give you an installer for acceptance testing.
In the mean time, I suggest the client sets the chris21 user to time-out, or periodically clear the redundant logged-in users.
Received from Deanna March firstname.lastname@example.org:
James and Joel have just been going through the doco and checking the various Chris21 settings and apparently there is a scheduled process that runs every day in production which clears any logins left behind. Usually the act of closing the client properly clears this, but, obviously, we don't have a client in this situation.
It turns out that process isn't running in our test environment which is why they have been building up. So, in short, it will not be a problem for production so we can close this one!
Response to Deanna:
I’m glad to hear that is the case and I have fed this back to Rodney.
Thank you for letting me know the outcome.
I have already done the change, so it will exist in the next release anyway.
This fix is included in UNIFY Identity Broker for Frontier chris21 v18.104.22.168.
A new configuration item is available call skipLogout. The skipLogout attribute defaults to False, which means that by default the logout routine will be called, which differs from earlier behaviour. Set skipLogout="True" to mimic earlier behaviour, where the user timed out instead of logging out.
Please confirm this issue is fixed by performing user acceptance testing.
Could you please help to clarify for me please.
The new configuration for chris21 to fix the logoff issue is to add the skipLogout attribute as True or False to the communicator element, eg
I assume that the initially proposed attribute, gtrLogOff is not use.
In any case, I installed Identity Broker for chris21 v22.214.171.124 and have tried configuration using both attributes above and the Identity Broker service can start up fine.
However, when I perform the following I encountered the following errors:
Reverting the configuration to a known working version still result in the same error.
Performing "Full Import" also resulting in the same error above.
Please see log file attached for additional information. IdB configuration files also attached.
IdB configuration files for chris21 and the log file that contains the errors.
Assign to Rodney for help.
I can't replicate this error. Please list the steps to recreate, and more importnantly the steps to recreate it failing on a full import.
This is fixed, new UNIFY Identity Broker for Frontier chris21 v126.96.36.199 installer at:
The configuration item used is skipLogout="True|False". It will default to skipLogout="False", which means the logout routine will be called by default. To mimic earlier behaviour (pre v188.8.131.52) then set skipLogout="True" and then logout routine will not be called.
Also, if an error occurs in the logout routine, then it will now appear as a warning in the log file, and normal operation will continue.
I performed upgrade from IdB for chris21 v3.0.5 to IdB for chris21 v184.108.40.206 (uninstall old version and install new version).
Restart IdB Service without making any configuration change at all.
Run "Synchronise Import" on chris21 Termination connector (I know there is outstanding delta change on chris21 system for termination details).
I got the following warning message that "command is not valid" in the log file.
I am not sure what this mean. I assume that the logout command is not successfully.
Reopened and assign for assessing the information provided.
This is now available for testing.
Test with the latest Identity Broker for chris21 v220.127.116.11 download
Verified that the skipLogout="True" and skipLogout="False" configuration as part of <communicator> chris21 as per updated documentation Frontier+chris21+connector
The following verification is performed:
Issue resolved and verified. Closed.