E9.2 Multiple Active Sessions Allowed for Same User Account

[indibda]

Multiple active sessions for the same user account could result in several security risks as mentioned below:
► Multiple users can share a single user account within the application. In this case, it would be more difficult to determine the responsible entity in case of any violation.
► If an attacker attempted to login with stolen credentials, the legitimate users may not be able to detect it.
► Unexpected behavior could be caused as a consequence of using multiple sessions for the same user account.
Would like to know if there is any available functionality within JDE Architecture to prevent this from happening?

 

[Tom_Davidson]

We allowed a user to do multiple sessions, but it required two different browsers. Otherwise the session cookies conflict. We also had a generic id for warehouse moves and people that did not have a network ID

 

[indibda]

We allowed a user to do multiple sessions, but it required two different browsers. Otherwise the session cookies conflict. We also had a generic id for warehouse moves and people that did not have a network ID

Yes that is correct and Oracle says its working as designed.

But the scenario here is that there are 2 users using the same login id to sign into JDE from different machine.

So to prevent this from happening means to allow only one connection at a single point in time for each account in the application.

One of the following approaches may be taken if a second login is attempted while another session is active for the account:
a) Reject the second successful login, explaining that a session with the requesting user is already active
b) Accept the second login and invalidate all previous sessions opened for the same account
c) Display clear instructions in the application on the methods of reporting to the application managers if the user suspects that their credentials are used by an attacker.

If anyone has successfully implemented these mitigation steps to avoid duplicate login, kindly provide your input.

 

[Tom_Davidson]

I know of no way of doing this out of the box. There may be a thirdparty tool to do so.

Or you could scrape server manager and roll your own, but it woudn't be quite real time, and woudn't send a message to the users as you require.

Tom

 

[Neal Scarr]

You could look at setting the user account to "02" (disabled) in the F98OWSEC table after they log on and then setting the account back to "01" (active) after they log off.

I'm not sure if there would be issues with the account if it's at "02" when the user is actually logged on but that would need to be tested.

Finally this would probably have to be done at the database level using a stored procedure for example.

 

[markdcci]

indibda,
One way I've done this in the past is with a single sign on tool that ties into the user's LDAP account. I know you can limit multiple logins in Active Directory, for example. If their JDE account is linked to AD, you effectively have limited their logins to one. Of course, it requires you to implement some form of LDAP integration which may not be in your plans.

 

[Tom_Davidson]

>>You could look at setting the user account to "02" (disabled) in the F98OWSEC table after they log on and then setting the account back to "01" (active) after they log off.

If you do this the user won't be able to run UBEs while logged on.

Tom

 

[Luke Phillips]

It isn't possible to stop multiple users from signing in with the same credentials at the same time within JDE. My recommendation is to always avoid shared IDs for the reasons you have listed among others. If you wanted to put a detective control in place to determine if someone was using the same ID to open multiple sessions and you are tracking login and logoff activity, you could develop reporting over the F9312. The reporting can be created over the audit log to view when and using which machines profiles have been used.

On a side note, It is a good idea to minimize password theft by applying best practice password policies using standard jd Edwards capability. Secondly, I would force the use of the security of all assigned roles when users sign in rather than allowing them to choose roles. This is not the same as allowing users to customise their menu view by applying individual roles but it forces every user profile to apply their role security in a consistent way.