From early on in the development cycle of OpenInsight 10, Revelation Software made it known that they intended to revamp user management and security. In fact, this was one of the key features that we highlighted to encourage the community to come to the 2015 conference in Houston. Originally dubbed the OpenInsight Authentication Module (OAM), this new user management tool now provides some impressive security policy features and it introduces an option that many developers have requested: full integration between OpenInsight and O4W users.
Bryan Shumsky explored the current state of OpenInsight security in his User Management in OI X presentation. Regretfully, I could not be in two places at once and I opted to watch Andrew McAuley’s Building a new application with Openinsight 10. Nevertheless, Bryan was kind enough to review some of the technical points I was uncertain about and he filled in the gaps of my knowledge. Thus, what is presented before you is based on my notes from the 2015 OAM presentation, Bryan’s 2016 presentation slides, my own hands-on experience with the product, and a little bit of wisdom from Bryan himself.
User management has been detached from being a menu item under the Database Manager and it is now a first-class citizen under the main IDE’s menu:
Before we look at the User Setup option, it is worthwhile to study the Policy Setup option first. This is the cornerstone of OpenInsight 10’s new authentication management:
The number of changes compared to the classic Database User Management tool is quite significant. However, if you aren’t quite ready to take on this much security management, you can always untick the Policy enabled? checkbox. In essence, this allows OpenInsight to use the more relaxed standards of previous versions of OpenInsight. (Note: Even with the policy disabled, one cannot create a user with no password. This is also true with the policy enabled and with all minimum length requirements set to 0. Bryan confirmed this is by design.)
I did discover that once a user has been created under one policy configuration, it will always be considered a valid user even if the policy configuration is changed and the existing password is no longer in compliance. Hence, the policy can be disabled temporarily for the sake of creating certain users and then re-enabled for general use…assuming one has a good reason for doing this.
Here are a few more observations based on the above screen shot and my own research:
The rest of the options should be self-explanatory. To complement all of the options made available to developers and administrators, Bryan also referred his attendees to Stanford University’s Password Requirements Quick Guide. This very readable guide advises security administrators to rethink conventional password strategies. Instead of password requirements that are so complex that people can’t remember them (but computers can probably brute force crack them), it is recommended to use passphrases. A passphrase of a minimum length of 16 characters becomes significantly more difficult to crack yet much easier for people to remember.
Let’s take a look at the User Setup:
This clean interface makes good use of the property grid control (which, by the way, is a control available in the new Form Designer). Most of the configuration items are easy to figure out. The User Type option is where users can be configured for OpenInsight only, O4W only, or both. The Success Return Value option is meant to give developers control over what is returned by a new function called RTI_Auth_User_Status. This value can also be used to provide more granular control over security, such as unique security levels (ala AREV), which makes it useful for role-based security systems. However, there appears to be a bug in the current user interface that prevents anything other than a 1 from being saved in this field.
Speaking of user credentials, we need to review how these are entered. The Open Application dialog is the same as we reported last year. You can also see example of it being used in Martyn Phillip’s first 5 minutes with OI 10 video posting. Here is another glimpse:
As seen in Martyn’s video, the password prompt makes use of the new PasswordPeekTimeproperty, which allows the password character to be visible for a predefined length of time. A very useful feature to help uncertain users enter their passwords.
The above is an OpenInsight generated form (PS_OPENAPP to be specific). As of this moment, there is no form dedicated for running an app. Bryan has acknowledged this, but believes that one will be developed in the future.
When I asked about opening up the new user management APIs so developers can better integrate them into their applications, Byran noted that the legacy routines should still work. I did some testing and confirmed his comments. The following routines still work as expected: Create_User, Delete_User, IsValidUser, CheckLegalUser, and Get_DB_Users. However, the Create_User subroutine does not provide the additional arguments necessary to populate the additional options which are now available. My hope is that new routines will be documented or the legacy routines will be expanded to support all of the new enhancements to user security.
Our parting words are both a commendation and a request to Revelation Software. The user management and security enforcement tools are very well done. It should give any developer pause who might have been tempted to reinvent the wheel. However, there is still one issue that will be important to developers: the ability to use their own login screens. This is very important to application developers who want to provide users with a unified interface from beginning to end. We’ll update you as we learn more.