Prev
Next
Forums Infor / Lawson Platforms S3 Security

LS Security methodology/philosophy question

 2 Replies
 0 Subscribed to this topic
 15 Subscribed to this forum
Sort:
Author
Messages
dcaiani
Veteran Member
Posts: 52
Veteran Member
2/3/2012 2:08 PM

    We are kicking around two different schools of thought as we start the migration from LAUA to Lawson Security. 

     

    The first is to take a functional area such as AP and build a single role that gives access to every token, table, etc that anyone in the company could ever have a need for in AP.  From there each person who gets that role would have security overrides for the tokens, tables, etc. that they don’t need.  So in a sense you would take away AP195, AP155, etc until that user had only what they needed.  So at the end of the day there would be one AP role for the whole company with each user having overrides for the things they don’t need.  Then build the same thing for GL, HR, etc.

     

    The second way would be to create a building block approach and create smaller bite size roles that could be used to create bigger roles.  So for instance, create a role for processing AP invoices, another for creating AP checks, another for closing the periods/year end, etc.  Then those bite sized roles would be used to build bigger roles so that AP Manager would get all AP roles, AP clerk would get maybe 4 roles, and when the GL people are built they might get 3 of the AP roles.

     

    I am curious to hear comments on what you think is the better way to approach LS9.  Comments on both schools of though are appreciated.

    SP
    Veteran Member
    Posts: 122
    Veteran Member
    2/3/2012 3:21 PM
      Let me start off by saying that I have been part of LS implementations/conversions/re-implementations since the earliest releases of LSF when I worked for one of Lawson's largest partners at the time. I was there when Rexing was auditing the earliest LS classes to completely re-write the training material and establish best practices for implementing what was then a brand new security model, so I know a little bit about this stuff.

      If you haven't already, you need to download "Implementing Lawson Security" from support.lawson. (search kbase for "LSIMP-90UWA-04") This will help provide an understanding of the intended security methodology which drove the development and functionality that exists in LS.

      Option-1 should come off the table immediately. There are so many long-term manageability/flexibility issues with this approach that I don't even know where to begin.

      Option-2 is headed down the right path, but slightly misses the mark. Try to get away from the idea of people having many roles. Seldom do people perform multiple roles. They perform multiple TASKS, not roles. Your AP Manager performs the role of "AP Manager" Unless this person is also the Director of HR, then "AP Manager" his/her role within your organization.

      To the extent you can, think of Roles as Job Titles.

      Think of Security Classes as "tasks" people perform as part of their role within the organization.

      In your example you would create bite sized security classes (APInvoiceProcessing, APVendorMaintenance, etc...) You then assign the tasks (security classes) to the Roles performing those tasks.

      There are several practical little things you can do to make things as pain-free as possible (e.g. handle invokables globally, separate out tables by source code, etc...) , but in the end, a thorough analysis of the tasks people perform and a mapping of those tasks to the roles in which the tasks are performed, will pay huge dividends in the long run and make things manageable when the inevitable change in a person's role within the organization happens, or the tasks that a role is responsible for occurs.

      I'm not the best at monitoring and responding to boards, so feel free to contact me directly if you want.

      shane.pennington@gmail.com
      Dave Amen
      Veteran Member
      Posts: 75
      Veteran Member
      2/3/2012 3:22 PM
        Dcaiani,
        I’ve been using a different approach that’s been hugely successful for many companies over the last couple of years. I use proprietary tools to do this, so stop reading here if you want, but the concepts can be used by anyone.

        First, use a “Listener” tool to capture exactly which tokens users are accessing. Run this for several months to get a good set of data. Or, have key users jot down the tokens as they touch them.

        Analyze the results and group users together who have similar patterns, which will naturally line up with their job requirements. This will determine the LS9 Roles to build.

        With the above results in a reporting format that’s easy to view and analyze (such as an Excel pivot table), meet with key users to review what their departments are actually using, and have them advise on what else may be needed (such as year-end tokens).

        Build LS9 SecClasses as granular as possible, grouping tokens within System Codes based on their usage across all users. KEY POINT: be brutal about minimizing the number of times a token appears in different SecClasses (stick to once for full access and once for inquiry, for example). Attach these SecClasses to the Roles as appropriate, attach the Roles to users, and you have it! (I highly recommend using an automated tool which makes the building and attaching easy).

        The enormous benefit of this is that it’s far easier to start with the facts (Listener results or jotted-down lists) and adjust from there than it is to try and recall everything that’s needed and build from scratch, or to use a pre-built pattern and change it to fit your organization’s unique needs.

        By the way, if you wish to pursue your first concept (give access to every token and then take away what they don’t need), you already have a huge start on that. People may not like it, but LAUA already knows what subset of AP (for example) the users must have. It usually includes access to far more than they need, but it provides a starting point that’s much smaller than the entire system code (and it works)!

        Best regards,
        Dave
        (303) 773-3535