This week’s release contains a few minor, albeit useful, enhancements, mostly regarding authentication.
Before this release, in order to login to Ready Room, Okta users would have to visit our login page, choose Okta from the SSO drop-down, and enter their email address in order to kick off the so-called “Service Provider-initiated Single Sign-On Flow.” This works well enough, but it’s cumbersome and foreign to users who are used to starting applications from their dashboard (aka launcher).
With the latest release, Ready Room now supports IdP-initiated Single Sign-On. This allows Okta administrators to add a Ready Room tile to assigned users’ dashboards, and for users to login with a single click of the tile.
We have also submitted Ready Room to Okta for listing in the Okta Integration Network (OIN). However, the OIN approval process may take a month or more to complete. Until then, if you want to leverage IdP-initiated SSO, contact firstname.lastname@example.org and we will assist you in updating your existing Ready Room Okta application. And if you just can’t wait, all an Okta admin needs to do is the following:
A few weeks ago we added the ability to bulk add users to Ready Room and/or an inspection. To do so, all that was needed was a list of email addresses separated by commas, spaces, or newlines. It appears that our customers love this feature! Unfortunately, it also appears that our customers love semicolons (curse you, Outlook!).
The upshot of this is that using semicolons as a separator ended up creating a bunch of users with invalid email addresses that ended in a semicolon, e.g., “email@example.com;”. It also created a lot of confusion.
With this release we have made the one-character change needed to support semicolons as separators when bulk adding users, in addition to those already supported. We have also taken the liberty to purge all invalid users from the system.
A common security practice when building Internet accessible systems is not to give away any details when users fail to login. Instead, programmers are advised to display something generic like, “Invalid username or password.” Otherwise, there’s a risk of leaking useful information to a bad actor or competitor. For example, if the system displayed, “Hi, Alice, your password is incorrect,” then the bad guy now knows that (a) Alice’s employer leverages the system, (b) Alice is a user of the system, and (c) he’s guessed Alice’s username correctly.
The downside of this practice is that valid users who are failing to login are not presented with any information to help them move forward, even though the system knows why they can’t login.
For Ready Room users whose accounts are managed by Ready Room this remains the case. However, with single sign-on users who have successfully authenticated with their identity provider but still can’t access Ready Room, we have the opportunity to inform the user why this might be.
With this week’s release, SSO users that have authenticated to Ready Room will be shown actionable error messages if (a) they have not been invited into the system by an administrator or (b) they have not accepted their invitation (the two most common reasons for failure). Any other failure will instruct the user to contact Ready Room support.