Welcome to the first product release blog, where we keep you up to date on the latest features designed to make your life as a TruU customer easier.
Q3 2020 was jam packed with major new product capabilities. At the same time, we built out our High Availability (HA) infrastructure to significantly improve performance and reliability. As part of this effort, we moved the TruU platform from multiple availability zones in a single AWS region to multiple regions, for a true multi-region cloud architecture. What does this mean for you? Significantly reduced latency and higher uptime for your TruU service.
At a high-level, the other features released this quarter fell into 3 categories:
- Improved User Experience,
- Compliance Support (e.g. COVID Assessment), and
- Simpler Deployment and Management of TruU
Improved User Experience
New End-User Portal
In speaking with customers and prospective customers, we have found a common desire for an end-user facing part of our service for users to enroll and manage devices. To that end, we’ve added a new ‘User Portal’ that allows for better self-service by your users.
From this landing page, users can take the following actions:
- End-users can “Enroll a Device”, or
- “Log into user portal”, and
- Administrators can Log in to the Management Console.
The ‘User Portal’ home page shows your users a snapshot of their account including their recent activity.
The ‘Manage Devices’ page enables the user to remove lost or stolen devices and enroll new devices.
Improved Invite-Based Enrollment (Group Invite)
In order to streamline onboarding of users, we have expanded our invite-based enrollment to include the ability to invite entire Directory Groups.
With the group invite, TruU will search your directory for users in that particular Group and will send invites to the users in those groups. This feature includes the ability to “Ignore users who are already enrolled in TruU” which allows you to repeat this process regularly without sending emails to your already enrolled users.
Improved SSO Adapters
We have made several improvements to all of our SSO Adapters (PingFederate, ADFS, OpenID Connect and our Java SDK) to make them more user friendly, more intelligent, and easier to manage.
We’ve done a complete redesign of the User Interface to show the available options (phone or FIDO key), explain the steps to do a QR scan, and to make setting the cookie more intuitive.
The adapters are more intelligent, in that they are user-aware and will only show the available authentication options for the user who is trying to login. The table below explains the login flows for three different users trying to access an app that is enabled for TruU authentication via a mobile device and a FIDO key:
|User||Devices Registered||Login Options|
|User 1||Mobile only||Automatically starts mobile login|
|User 2||FIDO key only||Automatically starts FIDO key login|
|User 3||Mobile and FIDO key||User chooses between mobile and FIDO key|
Finally, we’ve simplified the management of the PingFederate Adapter by consolidating the discrete component adapters from 4 to a single adapter that contains the appropriate logic to dynamically present the correct options to the user.
Knock to Unlock (Beta)
For customers using TruU for physical access, we have released a beta feature which we call Knock to Unlock. As the name implies, you can now knock on your mobile device to unlock the doors enabled with TruU.
Perhaps the best part about this feature is that the app does not need to be in the foreground and this feature works with the screen off while the phone is in your pocket. If the door is configured to require biometrics and/or PIN to unlock, the phone will vibrate when you knock and provide a notification that additional authentication is required. By default, the feature is enabled and is configured to buzz back to let you know that a knock was detected.
Improved Desktop Agent
Finally, we’ve made some updates to our Windows Agent to improve the way we determine proximity of iOS devices for proximity unlock. This improves the user experience in that the agent is less likely to prompt the user for PIN to unlock when proximity alone should be sufficient (e.g. device has not moved since last unlocked and policy does not require PIN after the computer has been locked for a period of time).
Finally, the new agent now publishes events to the Management Console for auditing.
Compliance Check (COVID Assessment Sample App)
In talking to customers who are concerned about reopening during / after the COVID pandemic, we realized that our mobile app can help ease those concerns. Specifically, we were asked by customers to create a COVID assessment (survey) that our app would force users to complete before allowing access to resources.
In thinking this through, we realized this is bigger than COVID and really boils down to enforcing compliance in any form. Our new Compliance feature enables our customers to use our app to require end users to complete any type of compliance app / survey before being able to use TruU for access.
TruU does not collect any of the data that is collected for compliance, but rather has created a turnkey solution for you to use to collect the information you need. The feature was built to be able to collect any data and includes a sample app created as a COVID assessment.
Functionally, this feature consists of 3 components:
- A stand-alone application that you host,
- Policy to determine if a Compliance app must be used, and
- Enforcement of policy by the mobile apps.
The stand-alone app is made available through a Git repository with our sample app for a COVID assessment with full instructions on how to use and customize the application. This application runs in Docker and can be run anywhere. Customers can use it as is, or customize it fully.
Once the compliance app is created and registered with TruU, our policy engine enables Admins to specify who needs to fill out the compliance app and the frequency for recertification.
The mobile app will then enforce this whenever the user goes to use the app (e.g. when using TruU to login to a computer or application or to open a door). The mobile app will communicate back to the TruU platform that the user has taken the action so customers can see that the users have completed the app. The answers provided are not shared with TruU, they are stored in the customer’s Compliance app database (which only the customer has access to).
Simpler Deployment and Management of TruU
With the new Entitlements System, Admins can now create groups of users based on any combination of the following:
- Users from Groups from the underlying directory (e.g. AD Security Groups),
- Specific users (e.g. “Joe Smith” and “Jane Doe”), and
- Attribute values (e.g. users from “Department” = “Marketing”).
This enables great flexibility and is still very tightly integrated with the underlying directory, but does not require moving users into specific directory groups for management. Entitlement Groups can be created for:
- Digital entitlements, or
- Physical entitlements
The image below shows a sample entitlement group consisting of:
- Users from the AD Security Group called ‘Product Demonstrations,’ and
- The user ‘email@example.com’, and
- Users with ‘Product Management’ as their ‘department’ in AD.
Entitlement groups are processed automatically every 3 hours. Admins can also select an Entitlement Group(s) to process entitlements on an ad hoc basis. In addition, entitlement groups are processed for users upon enrollment, regardless of when the last system-wide processing has occurred.
From the policy engine, Admins can then set policies for specific AD Groups or to specific Entitlement Groups.
Simplified Physical Access
The Entitlement System described above was instrumental in both simplifying physical access administration and making the physical access solution more robust. Prior to this release, setting up Access Level Policies was a bit complex. With the changes we’ve made to entitlements and policies we’ve made this much simpler to setup and manage. Specifically, we have done the following:
Physical Entitlement Groups can now be created to automatically assign Access Levels to users. When creating a Physical entitlement group, the Admin not only specifies who this applies to but also explicitly defines which Access Levels should be granted to those users.
Physical Policies are no longer applied to both groups of users and Access Levels. Physical policies are now only set for the Access Levels themselves. This allows you to specify the desired user experience for opening a door without having to maintain separate policies for every combination of users and access levels.