Trelica collects data about the individuals that are accessing apps and how frequently they log in to them so that you can optimize app licenses. You can also use this information to determine whether to renew licenses or consolidate on a particular provider or product.
It's important to understand the factors that can affect the consistency and quality of user login and engagement data, and why this can vary between apps.
The impact of session duration
Some apps let users log in and remain logged in for a very long time. This is known as a long "session duration".
Long session durations are generally seen as a security weakness and are discouraged, but some apps trade off security best practice against user convenience.
Slack is a good example where, once installed, users are rarely asked to log in again. Where possible, Trelica will request a "last accessed" date, rather than a "last login" date, and display this information in the "Last login" column. This is what we do with Slack.
A different example would be Monday.com. By default, Monday.com has a long session duration, and the API only returns last login dates. This means that the last login date displayed in Trelica may not accurately reflect the last time the user accessed the app. Fortunately, the session duration in the Enterprise edition of Monday.com is configurable.
Where possible, we generally recommend reducing session durations to a maximum of 24 hours. This is both better practice from a security perspective, and provides more accurate usage data to Trelica.
"Big Bang" SAML2 SSO Apps
"Big Bang" refers to an app where users can only log in using SAML2 Single Sign-On (SSO); there is no way to log in to the app directly.
The benefit of apps where users are forced to log in via SAML2 is that Trelica can be sure that all logins to the app can be retrieved from the Identity Provider used for SSO (such as Okta, Google Workspace or Microsoft Entra ID).
It is up to each app whether to implement a mechanism to disable password access, and force users to use SSO. For example Box.com has an "SSO required" checkbox.
Non-"Big Bang" SAML2 SSO apps
If there is no direct app integration from Trelica, and if users can log in to the app with both passwords and with SSO, then while we can get some SSO data from the Identity Provider, we can't be sure to have captured all access.
The potential impact of this is that some users may be logging in, but we have no record of this in Trelica. In this case, the user engagement data only reflects the usage by users that have logged in to the app using SAML2 SSO.
OpenID Connect or "social" login access
"Sign in with Google" and "Sign in with Microsoft" buttons are both examples of the OpenID Connect protocol (the foundation for the OAuth2 protocol, also known as "social" login).
Although Google and Microsoft Entra ID track "social" logins, this data does not provide an accurate representation of user engagement. The OpenID Connect protocol grants users an access token that can be valid for a long time (several months). This means that users might be accessing an app without actually having to log in again until the token has expired.
As OAuth2 / OpenID Connect data cannot be viewed as a reliable indication of access frequency, Trelica does not display user engagement data for apps discovered only via an OAuth2 integration. In this situation, Trelica displays the "Last authenticated" date for each user on the "Users" tab for each app; this indicates the last time the access token was granted.
However, if you have enabled the Trelica Browser Extension, Trelica records each time a user visits business apps and combines this with the user's last authenticated data to determine their last login date. Once enough data has been collected, Trelica also calculates the user's engagement level.
Related to
Comments
0 comments
Please sign in to leave a comment.