EMSS, Lawson Security, Search box, SuperUser, Portal

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3291
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1372
Roger French	1315
mark.cook	1244

kim

Basic Member

Posts: 15

3/30/2016 4:01 PM

We are in the process of implementing Lawson Security for our super user community. EMSS users are already using Lawson Security. EMSS has custom rules and validation built and is the “preferred” method for performing updates. EMSS has a set of required programs that the EMSS role(s) have been granted access.

As we all know, with Lawson Security the user has a single login, which means those super users not only have access to EMSS but also the Infor application. Based on their security roles we know the super user can only access tokens that they have security rights to access.

Example of a super user:
Super user who is a manager with direct reports.

Since the search box is available, since EMSS requires HR11 access to allow updates, how are any of you restricting the super user from accessing HR11, via the search box, for their own record and/or their direct reports record to perform updates directly within HR11 rather than the “preferred” EMSS bookmark? HR11 is just a single example, as we all know EMSS has other Infor forms that require update functionality, therefore the security role(s) has been granted access. Other examples are, but not limited to, Individual Action (PA52), Direct Deposit (PR12), or Employee Taxes (PR13). I will not even go into the fact that if a transaction is completed directly in some of those forms during payroll processing it can/will cause Payroll processing to error. Again, I will not go there ;)

If you are not restricting are you auditing the transactions?

If you are auditing, how many of those transactions should have been completed via EMSS rather than the Infor form directly? How are you ensuring it does not happen again?

If this is not a concern of yours, why is it not a concern?

Our user account base:
~87k EMSS accounts. Of those, approximately 12k are super users.

Cross posting to get each sides perspective: S3 Security and S3 HR/Payroll/Benefits.

TYIA for your feedback.

John Henley

Posts: 3353

3/30/2016 4:48 PM

Feel your pain...

There are four classes of users.
ESS only - they don't have search box
MSS (what you call a superuser but they don't use Lawson for day-to-day job except for EMSS / RQC) -- they don't have search box
"Core HR / Payroll Users" - users who use Lawson for day-to-day that require full access to HR / Payroll
"Core NON-HR / Payroll Users" - users who use Lawson for day-to-day that require full access but only ESS/MSS access HR / Payroll

ESS/MSS (and RQC, etc.) users who not "core users" don't have access to search box.

Still it can be a security exploit even if hidden.

All users are assigned roles that include rules written for each specific form restricting access to either employee, employee + direct reports, and/or employee's chain of command, depending on which form. For core users who require HR / Payroll as part of their job, they have open access.

Joe O'Toole

Veteran Member

Posts: 314

3/30/2016 5:25 PM

We are just starting with LS security in preparation for our V10 upgrade next year and have an issue with the EMSS delivered bookmarks disappearing when we turn on CheckLS. Most of our EMSS user base does not use the S3 apps but our corporate employees have both. I have installed the Lawson delivered rules (install-rnr.pl) and assigned the Employee as well as a Logan role however we cannot get the EMSS Bookmarks to stay. We have the search box showing as controlled by their portalrole. Unfortunately, even the APSuper role is not providing the correct inquiry and drill capabilities to the simplest of AP forms such as AP92.1. Back on EMSS, does it's security have to be completely built from scratch like the other classes for AP, HR, etc? This was a poorly executed deliverable from Lawson IMHO unless you plan on buying the fast track or hiring someone to give you their pre built definitions. I can understand not delivering conditional rules which clients would need to develop using the scripting language but for the basics not to work is disappointing.

Greg Moeller

Veteran Member

Posts: 1498

3/30/2016 5:39 PM

Joe: Yes, I seriously feel your pain...

Here is what we have set up for our PortalBookmarks security class under the LGN Profile... Hope it helps you.

Mostly, I think the LO tables, and the LOGAN data source are your main players here.

Attachments

PortalBookmarks.docx

Ari

Veteran Member

Posts: 49

3/30/2016 5:41 PM

We ran into the same issue when we implemented Lawson a few years ago. We were surprised to learn that you if you made self service programs available to users you had to also allow access to various Tokens in LSF9 security. This is just the way Lawson works. The self service programs are HTML\Java script that make AGS calls to the the underlying COBOL business logic programs. If users have the search box then they can run the Tokens. Our users love the search box because it makes running their regular Lawson Online and Batch programs much quicker. We would not take it away from Portal except for the users who are ESS only. We just live with the fact that the regular Lawson users can run Tokens even if they shouldn't. We basically don't tell them about the underlying Tokens.

Joe O'Toole

Veteran Member

Posts: 314

3/30/2016 8:42 PM

Thanks Greg, I'll compare this to what I have.

kim

Basic Member

Posts: 15

4/6/2016 2:46 PM

Thank you all for your feedback. If you are curious, here is our solution.

Create clones of those tokens that are called with EMSS. Restrict clone access to those in EMSS only. Further restrict token transfer to cloned token by adding the $NOTKNXFR within the .scr. Restrict access to Infor base token to the super users. By not allowing transfer into the clone, the search box will NOT include the clone token in a search listing.

There was also a discussion about taking super user token security a step further, for those tokens used in EMSS, by restricting access to their own records and those of their direct reports, if applicable. This would force them to use EMSS for any maintenance on themselves or their direct reports. This is implemented to some degree based on the criticality of the token.

Bad news, it is more customs. Good news, the business is happy that there are no security holes that would allow direct access and bypass the ‘required’ EMSS rules that are in place.

Example:
EMSS Personal Action (PA52) is now SSPA.
Update SSPA to not allow direct transfer ($NOTKNXFR).
Update the EMSS code to refer to the new clone, SSPA.
Update EMSS security access to SSPA and restrict access to PA52.
Update super user security access to PA52 and restrict access to SSPA.