PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 04/06/2016 10:46 AM by  kim
EMSS, Lawson Security, Search box, SuperUser, Portal – how do you do it?
 2 Replies
Sort:
You are not authorized to post a reply.
Author Messages
kim
Private
Private
Basic Member
(37 points)
Basic Member
Posts:15


Send Message:

--
03/30/2016 12:00 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.

    JimY
    Private
    Private
    Veteran Member
    (1089 points)
    Veteran Member
    Posts:389


    Send Message:

    --
    03/30/2016 12:38 PM
    None of our managers have access to Payroll forms through EMSS other than what is needed for such things as setting up direct deposit for themselves or checking their pay stub. Only Payroll and a few individuals in HR would have access to HR11 and I don't believe we use PA52 as that functionality is in Talent Management. The only screens that our managers would have access to would be the ones that are needed to perform appraisals, job requisitions, etc.
    kim
    Private
    Private
    Basic Member
    (37 points)
    Basic Member
    Posts:15


    Send Message:

    --
    04/06/2016 10:46 AM
    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.
    You are not authorized to post a reply.