During TRIRIGA install, what SQL GRANT statements are executed for the install to be successful? Are there specific object names that you can grant access to TRIDATA on those objects other than granting to PUBLIC?
Granting PUBLIC access to database objects goes against security policy. The problem is that you don’t know which objects TRIRIGA might need. You need to get specific object names so that you can potentially grant access to TRIDATA on those objects, rather than granting to PUBLIC.
You might have tried to revoke public access to a database object which caused an ERROR on com.tririga.architecture.security.dataaccess.AuthenticationDAO and caused TRIRIGA to freeze while restarting TRIRIGA.
The following SQL GRANT statements are executed during TRIRIGA install…
Is there a size limitation on multi-record smart sections? We have more than 70,000 users. So the group member list could be huge. The Group Member section of the security group doesn’t show all of the users that belong to this group. Is this a known issue?
This is a limitation of the platform and smart sections. The performance of a smart section will slow down when you have that many records in the section. Customers have worked around this limitation by hiding the smart section, and showing a query in its place. You can then have the query section actions perform the add and remove of members from the hidden smart section…
After upgrading to TRIRIGA 3.5.2, customers may see similar queries being fired from report runs, and may get system freezes afterward since the database will be extremely busy executing them…
When applying Geography or Organization security, a group with root level \Organizations and a geography set at a low level like \Geography\North America\USA\Nevada\Las Vegas will no longer apply an Org-level security check on queries. The same goes for security groups unrestricted at the Geo-level, but set at a low level of the Org. The security check will be applied on a Geo and/or Org basis based on the root-level security setup for the Geo and/or Org.
For convenience, here are the some recent CVE IDs.
||The IBM TRIRIGA Report Manager contains a vulnerability that could allow authenticated users to execute actions to which they do not have access.
||The IBM TRIRIGA Application Platform contains a vulnerability that could allow authenticated users to execute application actions to which they do not have access.
[Admin: This post is related to the 05.17.16 post and the 04.04.16 post about vulnerabilities and fixes. To see other related posts, use the Vulnerability tag.]
When using Firefox and creating a new record that requires a popup window, the system will disconnect the user’s session… You will receive the following error:
“Sign In Required: Sorry, your session has either timed out or is no longer active. For security reasons, you have been redirected to this page. Please sign in again to continue.”
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: