more from this author
The Implementation Part 5: Ready Set Go
The Implementation Part 4: If All Else Fails Test
The Implementation Part 3: Building the Beast
The Implementation Part Two: Designing My System
Get to know Andrew Provines ![]()
become a CIBER practical innovator
We are always seeking talented and innovative people. We have IT careers open all around the globe.
Lawson Security Webinar Questions
Andrew Provines, Senior Consultant : 17 March 2009 / 1:37 PM : 0
Question: How / Where do you set company / process level restrictions? Is it on the user and then those restrictions then flow down to the role.
Answer: There are three parts of Lawson Security when you get right down to it. The first is defining application access and what actions a user can perform within an application. This gives them all the access they need to work in an application. The next piece is file or table access. This allows a user to perform selects and drill arounds within applications and also allows table access in Addins queries. Both application and table access are a “most access wins” scenario. If you give someone HR11 with Inquire only in one security class, but HR11 full access in another then they have full access. The same holds for tables. The third part of security is what is called “Data Level Security”. This is where you limit the type of access someone has. This is based off of records and whatever criteria you feel is necessary. A typical Data Level Control is the element ProcLevel. This restricts people based upon Company and Process Level. However, this element group only applies to a subset of applications. To truly hit all areas you would need to apply rules to all tables used in selects and drill arounds and applications that need rules as well. Using these techniques you can limit the records someone has access to. In order to tell the system which records someone should have you can do a number of things; base it off groups, create custom attributes in the RMID, base it off HR setup, etc.
Question: Currently, we use two user ids, one for ESS/MSS and another for Lawson business functions. In the new security, can we have just one user id. Thanks
Answer: Yes. Single Sign On allows you to merge these ID’s into one and still allow the proper level of security.
Question: How do you get new users added to Lawson security to be available as a user in LBI?
Answer: There is an Identity that you need to populate for the user as well as making them a part of an LBI group. This can all be done from their RMID records.
Question: Does process flow integrator complicate a Lawson security implementation?
Answer: Very little as this should just be a matter of populating certain fields in their RMID.
Question: What are custom rules? Can you give us an example?
Answer: There are three types of rules the system allows. The first is All Access, the second is a All Access for a list of actions, and the third is custom rules created via the Expression Builder. An example of this would be to create a rule that only allows people in a certain group access to a specific object.
Question: We heard that while we could use a means (not sure what it is) of 'inheriting' a 'parents' permissions, we shouldn't do it, because while it's easier it kills performance. Can you speak to this issue?
Answer: I have seen where this can be an issue. The problem here is that while Lawson allows you to use inheritance, it is not always the best thing to do. Each time you add an inherited level it creates links to different objects in LDAP. I have seen where inheritance is used to organize security. This is not good practice. Instead a naming scheme should be developed. There are certain times when inheritance is a legitimate choice. An example of this could be Journal Entry processing where a number of people should have the ability to enter invoices and another group would have the ability to process those journal entries.
Question: Would you differentiate Class vs. Role in the new secuirty approach?
Answer: A class is confusing and seems to be a hold over from the previous system. A better approach would have been to call security classes either tasks or processes. Everything that needs to be done in the system could be considered a task. For example, the task of New Employee Entry. This would be a valid security class or task. It has a small number of applications assigned to it that allow someone to enter a new employee. A Role can be thought of as a Job. You could be an HR Generalist that has the ability to do a number of tasks, one of which could be New Employee Entry.
Posted in Lawson on 17 March 2009
More by this author ![]()
Tagged: Security consulting Security Research / Statistics Security Trends Vulnerabilities
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Post a comment
