Tyler Identity TID-Okta and Time and Attendance

Seeking more information on Okta and Time & Attendance

• ExecuTime
• Time and Attendance
• Okta
• TID-W
• Tyler Identity

Informational

1. TID-W/Okta tenant must be defined, federated, and working for the client.
2. Once TID is enabled – ALL users will be required to use TID/Okta to authenticate – no exceptions. This can present the client with a challenge for part-time staff whereby they may not be part of a domain/federated solution. Non-domain email accts can be managed via TCP Admin Center (Tyler Community - Admin Center + Identity)
3. Re-deployment of the application is required to enable this feature. Previous release levels have proven to be problematic and current release is recommended.
4. The Login ID (SystemAdmin\Masterfile\{user}\Security) must be populated with an email address value. Okta is case sensitive because it supports Unix/Linux based systems. Tyler’s interface attempts to deal with this, but UpperCase and CamelCase presents negative behavior with the application. The nightly Employee Build Mapping table will need to be adjusted to correct the nightly import (e.g., primaryEmail would be used for Munis EERP) - Unable to login to Time and Attendance with Okta enabled after upgrade
5. The Login Configuration (SystemAdmin\Masterfile\{user}\Security) drop down must be defined as ExecuTime/Time & Attendance (depends on release level, may be one of those two values). It should be set to Tyler Identity. This is poorly worded and was only present for TID-Local, does not work for TID-W
   1. NOTE: As of version 2024.1.1, when TID is enabled - on users Master File Management record, the Login Configuration type will default to Tyler Identity and will grey out the other authentication types from being selected
6. The following T-SQL query can be used to examine the data readiness:
   TID-W User Dump Expand source

   --Note: uncomment the AND statement in the WERE clause to get list of non-domain.
   --Will need to alter 'domainhere' with client's domain value
   SELECT e.login, e.first_name, e.last_name, e.email_address, l.login_type_name
   FROM employee AS e JOIN login_type AS l ON e.login_config_id = l.login_type_id
   WHERE (e.login NOT LIKE '##%') --AND (e.email_address NOT LIKE '%domainhere' OR e.email_address = '')
   ORDER BY e.last_name, e.first_name;

7. Enabling TID-W with T&A is simply done by hitting an ‘Show advanced’ check box, selecting the TID Enterprise check box, and re-deploying the application. There is a secondary check box for ‘hosted’ deployment. What this actually does is alter the URL re-write for the Okta tenant. The application is typically deployed with specific HTTP/HTTPS port numbers. Selecting the ‘hosted’ check box omits the port number from the URL re-write, as is the case for all of our hosted URLs which are behind load balancers. There is another possible scenario for this switch – a client who has insisted on deploying the app with 443 on the HTTPS port. If left unchecked, Tyler Deploy will setup the re-write with https://FQDN:443/ExecuTime and this will fail with the Okta tenant as browsers will natively trim the port number from the URL which alters the URL and thereby security with the Okta tenant.
8. There is a backdoor for the Admin account. It is ~/ExecuTime/Login_admin.action  - Append that to the application URL, bypass the tenant, and login with the Admin account.
   1. for example: https://myfqdn/ExecuTime/Login_admin.action
9. Finally – should this be enabled and the client decides they aren’t ready – DO NOT uncheck TD switches and redeploy. TID can simply be turned on/off via a switch in the application under SystemConfig\Admin page – and does not require an app restart