Don Bakke of SRP Computer Solutions discusses OI 10 User Management and Security

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:

  • Like other OpenInsight tools with configuration options, the Policy Configuration window stores its policy information in the SYSENV table under a CFG prefixed record (CFG_POLICY in this case). An examination of the contents of this record, however, reveal that the information is encrypted or encoded. Therefore, those with the ability to open system records will not easily be able to learn (or change) anything.
  • Despite the Policy name edit line control allowing me to change the name, it does not appear to let me save a policy configuration record using my own name. Based on other information Bryan shared with me, I’m inclined to believe that the form has not yet been updated to disable this control.
  • Unlike other SYSENV configuration records, CFG_POLICY does not support applicationspecific configurations. When I made changes to my policy configuration from within a child application, it did not create a CFG_POLICY*AppName record. It appears to only update the master configuration record. When I logged into SYSPROG and opened up the Policy Configuration window, I saw the same changes I had made in my child application. Again, Bryan confirmed this is by design. The idea is that entire systems (not just applications) should be governed by the same security policy, thus avoiding the dilemma of a strong security protecting the front-door while allowing others to slip in through an open window around the back.
  • There is an edit line labelled User defined stored procedure to validate passwords. This is where a custom stored procedure can be called to supplement the existing password policy. Its intent is to only validate passwords as they are assigned to users. It will not be used to validate a password when the user logs in. This routine is called when the user credentials are saved. Returning a 1 indicates the password is acceptable, a 0 indicates it is not acceptable. Whenever a password fails to conform to the policy, an error message is displayed:

  • A little experimentation with this feature indicated that three arguments are passed into the user defined function:

     

    • AppUserName – Formatted as ApplicationName*UserName (e.g., SYSPROG*DON)
    • Password – Plain text version of the user’s password
    • Errors – This will contain errors found by the policy prior to calling the user defined procedure. Developers can add their own @VM delimited array of errors. I have found that if this argument is populated, even if the function returns a value of 1 the “invalid password” error will still be generated.

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.