You can configure TRIRIGA to use Tivoli Directory Integrator as its ETL runtime engine to run ETLJobItems from within TRIRIGA.
Before you begin
Install Tivoli Directory Integrator, if not already installed, on all the TRIRIGA systems that could run a TDI ETL Job Item. During the TDI install:
- Make note of the installation directory you enter on the Destination panel. You will enter this value later in TRIRIGAWEB.properties.
- Select either installation type. TRIRIGA requires only the TDI Server component.
- When prompted for the location of the Solution Directory, you can select any option. TRIRIGA specifies its own solution directory at runtime. However selecting the option “Use Install Directory” may simplify troubleshooting.
- Make note of the value you enter in the Server Port field on the Server Port Values Panel. You will enter this value later in TRIRIGAWEB.properties.
- Clear the “Start the Configuration Editor” check box on the Install Complete panel.
- Note: This step is very important for TDI/TRIRIGA integration to work. After you have installed Tivoli Directory Integrator, update it with the recommended fix packs (per TRIRIGA support matrix). TDI must be at least at FP04 (184.108.40.206) or it will not automatically start the TririgiaETLDispatch.xml assembly line which will result in ETL job items failing to run successfully.
- Edit TRIRIGAWEB.properties file to enable TRIRIGA to manage TDI server. Set the following properties…
- Install a JDBC driver library so that Tivoli Directory Integrator can use it to access TRIRIGA database…
- Edit TDI global.properties file to allow TRIRIGA to check and stop the TDI server from localhost without requiring authentication and authorization certificates. Set the api.remote.ssl.on property to false to tell TDI to trust requests from localhost…
- Start Tivoli Directory Integrator Agent from TRIRIGA Admin Console and verify that it starts successfully…
[Admin: This post is related to the 08.03.16 post about installing, upgrading, or uninstalling TRIRIGA TDI, and the 05.01.16 post about documentation on developing TDI with TRIRIGA. To see other related posts, use the TDI tag.]
I am trying to configure SSO with WebSphere Liberty (on RHEL 6.8 and TRIRIGA 10.5.0/3.5.0) with Active Directory. Once configured, I get the Windows authentication popup. It accepts my domain credentials, but instead of taking me inside the application, it takes me to the login page, where I have to input my local TRIRIGA profile login details. Can someone help me with this?
[Admin: To see other related posts, use the Active Directory tag or SSO tag.]
How do you determine what is the best mobile solution for your enterprise that will enable users to get the data and functionality they need? What software will integrate smoothly, assimilate large amounts of data, comply with your security requirements, give the end users an engaged experience, and ultimately make your business more effective and efficient?
Here are the answers to the top questions asked at the FieldFLEX booth during the recent IBM InterConnect 2017 conference.
What is the security level with the FieldFLEX mobile app?
At the device level, all data is encrypted for transport to and from the server over SSL. Any data stored on the mobile device resides in an encrypted mobile database. The FieldFLEX server stores no data. User access is controlled by username and password authentication or through mobile device management platform…
What back-end systems does FieldFLEX integrate with?
Our mobile platform integrates with IBM TRIRIGA, Maximo, and a variety of other products. It is the single mobile solution for corporate real estate, condition assessment, facilities management, operations, lease and capital projects…
How are drawings published?
Mobile drawings can be published directly from your AutoCAD or Revit floor plans. Customers can choose published content which offers layering visibility control. FieldFLEX drawing publisher reduces the CAD file size by up to 90% to improve download speed and performance in the mobile apps…
[Admin: To see other related posts, use the FieldFLEX tag.]
I am having an issue with logging out users through an OSLC consumer application.
I am using the native authentication because the customer requires the Base64 encoded string. So when I shut down my consumer application, I call the /logout command and get a 200 response back, but I can still see the session in the Users Manager of the TRIRIGA Admin Console. I think the problem is that the /logout command does not take any parameter, like the session ID, username, login ID, or even the JSESSIONID.
In addition to this, if I am creating 5 sessions for the “system” user to handle processing for the consumer application, then this /logout command would almost have to accept some parameters to allow you to manually logout each session based on a unique ID, like the session ID found in the TRIRIGA Admin Console or the JSESSIONID…
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.
||The IBM TRIRIGA Document Manager contains a vulnerability that could allow authenticated users to execute 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.]
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:
This change in functionality was an enhancement made in TRIRIGA 3.5.2.x The change is not in 220.127.116.11… So, the options for you right now are to test out 3.5.2. In 3.5.1 and below, enable the session expiration warning setting and extend the session timeout in the web server to something like 8 hours (normal working day):
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.