LBI Security setup

 7 Replies
 0 Subscribed to this topic
 22 Subscribed to this forum
Sort:
Author
Messages
Ruma Malhotra
Veteran Member
Posts: 412
Veteran Member
    Just one week to CUE and I am wondering how different users have setup LBI security through the use of report security groups, custom groups, groups defined in LS9 security or through just simple user ids.

    Since I am not very smart, I am struggling to define best practices for setting up security that will be maintained through different LBI version upgrades, migrations to new hardware and LBI security reporting from the reporting tables to provide to business owners . Please don't go harvard on me and share simple ideas of why certain methodology was adopted in setting up security for both framework and reporting services.

    Thanks in advance.
    Ruma Malhotra
    Veteran Member
    Posts: 412
    Veteran Member
      I am going to rephrase my question and ask whether there are ceratin best practices or methodologies to set up users for LBI security ? If so what are the reasons behind adopting this methodology ?
      Roger French
      Veteran Member
      Posts: 549
      Veteran Member
        Yes you are smart. Don't let anyone tell ya differently.

        I have to say, I did like your phrase "don't go Harvard on me". That is too funny. I don't think anyone from Harvard was responsible for designing/architecting Lawson but I could be wrong.

        I'll go Community College on you and say: do what is best and right for your company. Everyone's got a different methodology or best practices, or maybe some have none. Or even too, build your own methodologies or best practices. Whatever the end result is, it just has to secure your reports accurately. 

        If you want my advice I would say take some time to analyze your needs, maybe even on a small group or sample first. Not your entire user population. Then build a working model or proof of concept based on that small group. Then build up from there. Oh, and yes CUE should be invaluable to you networking with other SME's and users about this subject.

        Good luck,
        Roger
        George Graham
        Veteran Member
        Posts: 201
        Veteran Member
          It also depends on how you are using groups is Lawson Security for other purposes and how cluttered that can get. I recommend that you use a standardized naming convention for the LBI groups (maybe prefixed with LBI - see, I went to Oklahoma State!).

          My suggestion is usually not to use the security group setup within LBI soley for the purpose of having a single database of record for security setup. I've seen people get really confused having to define part of the LBI security in one place and part in another. I don't generally see a real arguement for segregating the membership for report access and dashboard access.

          Also a big proponent of steering away from any named user access to anything - and I may draw some debate on that. But take the example of a single report that is delegated to VP of Finance. The notion is really that the report is directed to that position - not the person. If that person were to leave the report will still need to be delivered to that role when filled. In the case of a named user approach the new hire will have to be assigned a group for navigation to dashboard, or at worse case as a named user on the dashboard again. Then the access on the report would also have to be changed. With group/role defined approach all access is managed from with Lawson Security - and in some circumstances where access is being granted by automated scripts or process flow then nothing in LBI needs touched to maintain this access control.

          But I agree with Roger - security is one of those hard items to label with "best practices". A lot of it has to do with demand from internal and external audit, etc...
          mark.cook
          Veteran Member
          Posts: 444
          Veteran Member
            Not to try to get more people signed up for my CUE presentation but I am doing one this year on Debating Rights vs Structure in Reporting Services. I have taken it from a report/speed perspecitve but feel it drives some security discussions.

            I had planned on it being a debate format wtih lots of input from everyone. It might spawn some good exchange on what everyone is doing and how they make it work for their organization.

            I know it is slightly off topic but would love to have that discussion with others at CUE about how they use the system and what works best for them. It seems I get into these conversations every year at CUE.

            While your at it sign up for Ruma's LBI presentations. I plan to try to make it.
            Ruma Malhotra
            Veteran Member
            Posts: 412
            Veteran Member
              Mark - That's great to have your presentation in the form of a discussion. I know that a lot of people will speak up and talk about how they have implemented LBI security in different ways. This is an excellent topic of discussion and I wish LBI elite from lawson will be there as well so they can answer our questions along the way. You are always ahead of the game and so is your topic at CUE.

              Also I do know that Lee kilmer is having a roundtable on LBI on wednesday and I plan to attend that and ask him a few questions about best recommendations from Lawson on setting up LBI security not to mention that a group of us, as per Mark's original idea, can approach Lawson  and other members to talk about some of the challenges that we face with setting up security and I will name some challenges.

              1. On Version LBI 904 and 9041 if you have security setup on the dashboard level and when you hit save on sharing all the roles will automatically cascade to every module defined on the dashboard and link. If we have different modules setup to address different reporting needs for different groups for eg. Module called
                  compensation that includes pay information for every employee in the organization.
                  Terminations for employee relations
                  DOB information on employees for audit.

              All these different reports now belong to different groups and the compensation team should not see reports belonging to employee terminations and vice versa. But with framework services there is no way to restrict the modules when you add new roles every day at the dashboard level ,since security cascades.

              So there is real need to restrict the data based on reporting services. On reporting services the use of report security groups, custom groups or simple user-ids and we talk now of a regular user not management that accesses reports, and how to set that up so that when we migrate to new versions of LBI as well as migrate LBI to new hardware all the security migrates seamlessly.

              In fact Mark I plan to sign up at the Lawson booth to have a discussion on LBI security and will let you know so we all can input all the challenges we face on setting up as well as reporting out of Lawson for security.

              Thanks Mark for publicizing my presentations At CUE. Just remember this is my first time and I will be nervous like hell.
              TracyO
              Veteran Member
              Posts: 97
              Veteran Member
                Ruma & Mark
                could you share the date and time of your seesions?
                Thanks
                Tracy
                mark.cook
                Veteran Member
                Posts: 444
                Veteran Member
                  Tracy,

                  My Session Name: The Great LBI Debate- Structures or Bursting by Content
                  Date: Monday, April 4, 2011
                  Time: 4:00 PM - 5:00 PM
                  Session Code: UPPC03

                  I have info prepared but will allow the flow of the discussion to take us around to help those out who attend. I plan is to get as much feedback and input on how people use the system to debate pros and cons to different approaches.