Can anyone help with SSO with Liberty and Active Directory?

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.]

Why can’t you re-authenticate in app server after session timeout?

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: 

SSO_DISABLE_UNAUTHORIZED_STATUS=Y

This change in functionality was an enhancement made in TRIRIGA 3.5.2.x  The change is not in 3.5.1.2… 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):

SESSION_WARNING_ENABLED=Y

SESSION_WARNING_THRESHOLD=2

Is there a way to implement seamless SSO in TRIRIGA?

Implementing SSO in TRIRIGA, according to the documentation, allows users to sign in with their existing user names and passwords stored in Active Directory or LDAP server. Is there a way, however, to implement seamless SSO, so that when a user logs into a computer, it keeps the certificate to authenticate into TRIRIGA?

[Admin: This post is related to the 04.05.16 post about whether TRIRIGA supports seamless sign-on.]

Why should you consider Liberty over traditional WebSphere?

WebSphere Liberty is a lightweight version of traditional WebSphere. It does not have nearly as much overhead, nor does it require a dedicated team to install, run, and support, like its bigger brother. The beauty of Liberty is that comes with TRIRIGA and is very easy to install! Not to mention it does not take long to install compared to traditional WebSphere. The TRIRIGA installer includes Liberty so when you run the TRIRIGA install, you have the option to install Liberty without any additional files. When you select Liberty in TRIRIGA, it makes the process seamless. There is no console to worry about. Liberty has all that TRIRIGA needs to run. After the install is complete, all you do is start up a batch file and you are up and running.

I bet you might be wondering: I need to use traditional WebSphere because we are using SSO and I may not be able to use Liberty. Not so! You are able to configure TRIRIGA 3.4.2 and greater on Liberty with Microsoft IIS and Active Directory. For details on that, let me direct you to this wiki page: TRIRIGA on WebSphere Liberty — SSO with IIS and AD.

Can Liberty be set up as a service like traditional WebSphere? This is a bit more complicated and I encourage you to check out a colleague’s blog entry on this subject: TRIRIGA and the WAS Liberty Profile that does not want to be a service.

In the end, you need to decide what will best suit your needs. In some rare cases, traditional WebSphere may be the way to go, for example, if your company has a dedicated WebSphere team. But in most cases, Liberty will work best. It’s good to have options and know what the benefits are. To help you understand the benefits, you may want to look at this wiki page: Choose Liberty over Traditional WAS.

[Admin: This post is related to the 04.28.16 post about running Liberty profile as a Windows service, and the 03.15.16 post about the best practice for choosing an application server.]

Is there a way to use a Windows account to connect to the DB?

I’m performing an install of TRIRIGA 3.5.0 using WebSphere 8.5.5.7 and MS SQL Server, and the process is failing to validate the database connection. The client’s policy dictates that SQL should use Active Directory / Windows authentication. We have checked the SQL Server logs and the login is failing because it is trying to authenticate as a SQL Server account rather than a Windows account.

Is it possible for TRIRIGA to use a Windows account to connect to the database? I have searched for some documentation and I cannot find any detail. If it is not possible to use a Windows account to connect to the database, our client is happy to create a SQL Server account. However, some documentation is required for their IT team. Can anybody point me to the relevant documentation?

I suspect that Windows authentication is not supported.  However, I don’t see any documentation anywhere that clearly indicates this requirement. At this point, I would suggest that you open a PMR.  Either they will find out where the documentation is, figure out a way for Windows authentication to work, or update the documentation to spell out this requirement.

Can anyone provide an example of SSO with Liberty and Apache?

We found this link that shows an example of SSO with Liberty and IIS. Can you provide an example with Liberty and Apache?

• TRIRIGA on WebSphere Liberty – SSO with IIS and AD

The high-level steps are the same:

1. Install the WebSphere Application Server web server plugins.  The plugins are available in the Supplements package for WebSphere Application Server on IBM Passport Advantage.
2. Configure the plugin on Apache, and make sure Apache can pass requests over to the Liberty server using the generated plugin.xml file.
3. Configure Apache with your Directory server or other Single Sign-On solution. For LDAP/Active Directory, use the appropriate LDAP module. For example, for AD…
4. Then configure the TRIRIGAWEB.properties with various SSO settings to pickup the username from the correct location in the header, using the requestTest.jsp as your guide. 

[Admin: For convenience, here are the meanings of the acronyms: Single Sign-On (SSO), Internet Information Services (IIS), Active Directory (AD), Lightweight Directory Access Protocol (LDAP).]

[Admin: To see other related posts, use the SSO tag.]

What are some tips for adding users via a TRIRIGA integration?

When adding users via a TRIRIGA integration, these points should be taken into consideration:

• No matter if a user is added via Connector for Business Applications (CBA), Data Integrator, DataConnect, or integration object, the action “Activate” must be used to create the actual user in TRIRIGA.
• The Boolean field “Active TRIRIGA User” must be set to TRUE.
• A default password of “password” is set in the workflow “triPeople – Synchronous – Create TRIRIGA User” under the “Set Default Password” task mapping. For more information, see this TRIRIGA forum post: How to change the default password for a newly created TRIRIGA user.
• When integrating from a directory server (LDAP/AD), it is best to use a data warehouse database to load the users. This way, standard integration object or staging tables with DataConnect can be used without a custom-built connect to the LDAP/AD server.
  • This Microsoft TechNet article describes a way to synchronize AD to an SQL Server instance: Synchronizing Active Directory Objects to SQL Server.
  • Tools like slapcat can generate a LDIF file from an LDAP server. That export file can then be imported into an Oracle or DB2 database via standard database import tools (Oracle: dsadm, DB2: idsldif2db, ldif2db). Then a job can be run to export and import from the LDAP server on a scheduled basis.

[Admin: This post is related to the 02.22.17 post by Watson IoT Support about activating records imported via Data Integrator, and the 01.26.16 post about initializing Active status when using DataConnect. For convenience, here are the meanings of the acronyms: Lightweight Directory Access Protocol (LDAP), Active Directory (AD), LDAP Data Interchange Format (LDIF).]