Authentication is a fancy word for “logging in”. It describes the process whereby a user gets access into the application and is important for data security for a number of reasons:
- It prevents one authorized user from pretending to be someone else
- It allows various logging and audit trailing data to be retained, typing actions to users
- It prevents casual attacks on the application from people who have access to the URL, but not rights to be in the application
Authentication is a feature that TOPAZ has spent a lot of development time on. Why? Well, it’s one of those things where there are lots of different ways to do it, and our clients each have their favorite methods!
Old School – Local Authentication
The original method of authentication used in the old GRANITE product and still available in Elements is “local authentication”. Under this model, the user names and passwords are stored in the Elements database. When a user enters them on the login page, the Elements application itself checks that everything matches.
This method works very well and is easy to implement, but comes with a cost because someone has to make sure that the user names and passwords are always up to date. For customers with a large number of users and a high turnover (a student population, for example), this can be impractical. Still, for smaller customers (Elements Cloud users, for example) this may still be the method of choice.
External Authentication – LDAP integration
The second strategy for authentication is to rely on an external system (external to Elements, that is) for management of users and passwords. Under this model, Elements does not retain password data at all. When a user enters their user name and password on the login page, Elements calls out to an external “directory system” and makes sure that the entered password and user name are valid.
Typically, this involves a call to an “LDAP” server, such as Microsoft’s Active Directory. I can have the advantage of removing the need for an administrator to manage passwords within Elements (and helps with the “I forgot my password” phone calls, since a user’s password will always match their “main” network password).
One limitation of this approach is that obviously Elements needs to be able to connect to the LDAP server. This is fine if Elements is installed at the customer site, but if TOPAZ is hosting the Elements instance, this is problematic because opening up the LDAP server to the Internet would represent an unacceptable vulnerability for any IT Department.
Single Sign-On
Finally, we come to single sign-on, where things can get a little complicated! Under this approach, a user does not even have to enter a username and password into Elements. If you are authenticated already via a single sign-on page, Elements will recognize this and let you right on in (or not).
This approach is, of course, very easy for the user, but can be tricky to configure. The other complication is that there are several common protocols in use for this and they are constantly evolving.
TOPAZ initially implemented support for CAS—a single sign-on protocol for the web. Its purpose is to permit a user to access multiple applications while providing their credentials (such as user ID and password) only once. It was invented in the early 2000s (thanks, Wikipedia)!
In the last 5 years, we’ve seen more customers using Shibboleth or other SAML-based protocols. SAML is “Security Assertion Markup Language” and is “an open standard for exchanging authentication and authorization data between parties”. (Thanks again, Wikipedia!)
Shibboleth is one particular “flavor” of SAML that we’ve seen often, but there are others. SAML can even be used by institutions to build their own single sign-on environments, and we have at least one customer who has done this. TOPAZ had to do some custom development to integrate with them.
One big advantage of a SAML-based approach is that it remains secure and can be used “across security domains”, meaning if TOPAZ is hosting your Elements instance, we can still use single sign-on!
Two Factor Authentication
Another wrinkle that some of our Federal Government customers have to contend with is the mandate to use “two-factor authentication”. This means that in addition to entering a username and password, the user has to “swipe a smartcard” in order to login. Fortunately, TOPAZ was able to accommodate this relatively easily thanks to those SAML “standards” mentioned above. Just don’t leave your smart card at home!
Users
Using a single-sign-on or external authentication mechanism removes the burden of password management and makes life easier for the user, however, Elements does still need User Management to be performed! Once a user logs in, we still need to know who they are, what roles they have, what screens they can access, and this can only be done within Elements itself.
So, someone still has to manage users and staff data within Elements. How can this be made easier? The answer lies in integration!