EMSS, Lawson Security, Search box, SuperUser, Portal – how do you do it?

Sort:
You are not authorized to post a reply.
Author
Messages
kim
Basic Member
Posts: 15
Basic Member

    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
    Senior Member
    Posts: 3348
    Senior Member
      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.
      Thanks for using the LawsonGuru.com forums!
      John
      Joe O'Toole
      Veteran Member
      Posts: 314
      Veteran Member
        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
        Veteran Member

          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
          Ari
          Veteran Member
          Posts: 49
          Veteran Member
            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
            Veteran Member
              Thanks Greg, I'll compare this to what I have.
              kim
              Basic Member
              Posts: 15
              Basic Member
                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.