We are using IdP-initiated SAML, and we access TRIRIGA via a link that looks something like this: http://idpprovider/applications/Tririga. Can we pass this link in FRONT_END_SERVER in TRIRIGAWEB.properties so that users can click on the link that they get in a work task email, and they can be redirected to TRIRIGA?
SAML does not support basic authentication for non-browser clients. This is a SAML limitation. See the following APAR IV88274 link.
[Admin: For convenience, here are the meanings of the acronyms: Identity Provider (IdP), Security Assertion Markup Language (SAML).]
[Admin: This post is related to the 08.18.16 post about lack of support for non-browser clients. To see other related posts, use the SAML tag.]
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.]