Landmark security for Configuration Management

cleverly

I have a pedantic question about the Landmark security for Configuration Management that seemed like it might be a little too in the weeds for our weekly phone call, so I thought I'd be the first customer to post a question here instead.  :-)

First some background—

Page 7 of the draft Infor Configuration Management Reference Guide for Landmark Technology, Financials and Supply Management, and HR Talent (dated July 16, 2024) says:

Each of these security classes are associated with a role (coincidentally) of the same name:

Each of those roles has only the security classes of the same name associated with them:

The BOTagAdminAccess_ST and BOTagUserAccess_ST security classes both grant access to only two Business Classes: BusinessObjectTag and BusinessObjectTagItem.  The BOTagAdminAccess_ST class (and hence role) grants unconditional access for all actions on both.  The BOTagUserAccess_ST class unconditionally grants inquiry access on BusinessObjectTag and all actions on BusinessObjectTagItem.

The business logic LPL for BusinessObjectTagItem has some "extra" security checks:

Observation: While the documentation says that a user needs a role that is associated with the "BOTagUserAccess_ST security class" the LPL is checking to see that the user has the BOTagUserAccess_ST role.  Despite the shared name, those are different.  So the documentation is buggy as things stand.  However, that begs my question—

Question: Landmark Security can (and does) already control who has access to perform certain actions.  Why the extra check for a specific hardcoded role (and forcing it to be that role and only that role)?  Someone thought it was necessary or desirable; I'd like to be able to understand why. 

0911060553270289.pdf

Delmar Dehn

Here's the explanation from Landmark Technology Development's John Sperle:

Tagging is implemented as a mix of LPL and manual UI code.

The LPL

“AccessAllowed                            

     when (actor has role "BOTagUserAccess_ST" and ASBusinessClassRel exists) “

is used , in addition to other checks, for setting a flag in the data view for the UI to know if an item is taggable. We didn’t want to inject additional security checks into every one of these calls. To simplify things, we simply check if the user has a specific role to see if they can tag. This is all internal processing.

This does not circumvent actual security when the UI calls to tag an item. The user must still have security defined access to the tag/tag item to create records.

It is required that the users that should be able to tag have the “BOTagUserAccess_ST” role. It’s suggested that the role have the “BOTagUserAccess_ST “ security class but it could have anything that gives appropriate access. This security class allows tagging items but NOT creating new tags.

The fixed role is a requirement to be able to see the tag option in the UI but the security class is a convenience. They could create their own security class. They could even assign the delivered security class or custom security class to a different role. But in the end, the user must have security access to those actions to tag items. So the user must have the “BOTagUserAccess_ST” role but that role doesn’t have to have any security classes as long as the user has a role with a security class that grants the appropriate access.

The tag administrator can create new tags and manage tag items. We offer the “BOTagAdminAccess_ST” security class and role as a convenience. But they can create their own classes/roles to give access to creating and managing tags.

The docs say that must have the security classes to create tags. What it probably should say is that tag admins need equivalent access as BOTagAdminAccess_ST and user who tag need equivalent access as BOTagUserAccess_ST and must have the BOTagUserAccess roile regardless of how access is granted.