The query engine is calling multiple SQL statements that check permissions for module and form-level access for each row returned.
A sample report runs pairs of duplicated SQL statements with very similar bind variables. It first selects the SERVICE_ID using 3 bind variables, then repeats the process, checking for a Template ID of -1 with otherwise identical binds to the first statement. We see appsec.getValidSecurityServiceIds calls to the APP_OBJECT_PERMISSION that data should be cached.
The query engine was looking up security group tab information for every BO in the report crossed with every group a user is assigned to. Moving forward, we reduced the number of calls to the database for non-admin users when checking security by adding a new cache.
We are encountering an odd issue with TRIRIGA SSO and Active Directory with Personal Identity Verification (PIV) cards for authentication. The issue occurs after a session timeout, when a Windows Authentication dialog box would prompt a user to enter either their pin code or their Active Directory login, in which the Windows security does not accept their credentials, even though the right pin code or username/password is used…
Upon clicking on the Cancel option in the Windows Authentication dialog box, a second window with a “401 – Unauthorized Access” error is displayed to the user with a link that allows the user to regain access to the REMS application. We do not see any significant errors regarding authentication on the TRIRIGA side. At this point, I am not sure if this is a IIS, Active Directory, or a TRIRIGA configuration issue, but any suggestions would be great…
The issue is that the user’s old session on the app server is invalid, and the app is passing a 401 header back through IIS, and onto the browser. The solution is to tell the app server not to send the 401 header. In TRIRIGAWEB.properties, set:
The project context can be set to a project where the user does not have Capital Project security access. A user cannot modify or update data inside the project when they do this. However, the TRIRIGA platform should prevent the setting of this context from ever occurring in the first place.
Users can set the project container through direct URL manipulation. Moving forward, the privilege escalation vulnerability has been resolved.
[Admin: This post is related to the 03.01.17 post about a privilege escalation vulnerability in the Report Manager, and the 02.13.17 post about the relationship between project context and security.]
The IBM TRIRIGA application is vulnerable to a privilege escalation vulnerability. Specifically, IBM TRIRIGA Report Manager contains a vulnerability that could allow an authenticated user to execute actions to which they should not have access.
After importing some amended People Template record data in an OM, we are getting an error when trying to apply those templates to a new People record. The error being reported is:
“One or more Security Group names do not match the User Group names in the Group Details section of the selected people/people template record. Update your Groups before applying the record.”
When I look at the People Template record, I see we have 28 groups in the Group Details section, all of which exist as security groups. However, if I look in the Associations tab, there are 56 associated Group Details records. So it looks like the OM import has created some new associations, but not removed the old ones. Has anyone come across this before? Is anyone aware of any issues when importing People Template record data via an OM?
Is there a trick to getting group overrides in the global menu to refresh?
I’m able to turn on and off the top-level menu items, but the second-level items are not responding. I’m trying to disable all of the Projects second-level menus, except Facilities for a particular user group. I have tried it many times with various users and I still see all second-level menu items. Logging on and off, and waiting extended periods of time has not helped.
I figured out what was going wrong. I have multiple security groups assigned to each user, and the menu group overrides were conflicting with each other. The extra security groups are configured to all users without a primary organization to see those with a primary organization and vice versa. Unfortunately, these groups only had group overrides applied to the top-level menu. When I attempted to enable a few second-level menu items, these extra security groups enable all second-level menu items.
The fix is to disable all menu items for these extra security groups. This way, the primary security group has full control of the menu selection.
TRIRIGA has the notion of project-based security scope, also called project context. At the upper right-hand side of the main TRIRIGA portal, there is a toggle to switch between Company and Project-level security, as well as a query to find and select in which project to operate.
To see and select a project, the user must be given specific security access to a project. This is done by adding the user’s group or the specific user to the Security tab of the project. Once the user or users have been granted access to the project, and they select the project from the project selector on the portal, they are then in the “context of the project.”
Any records created in the project context are then owned by that project, and security is restricted to those records, so the records are only visible and editable to those people that have access to the project, and have also switched their scope to run in that project context.
Items like documents and folders within Document Manager will also operate in a project context. You may notice that files uploaded to the Notes & Documents tab of records in the project context have a different folder path within Document Manager. Because the entire Document Manager tree is also in the project context, it is necessary to have the parent folder created in the project context as well. This folder’s path will be different than the uploads on records at the company level.
[Admin: This post is related to the 04.08.16 post about where your documents go in TRIRIGA, and the 08.25.16 post about an issue with selecting child projects.]