<img alt="" src="https://secure.hook6vein.com/218483.png" style="display:none;">

Ask Christopher - Why should I use SQL Back-end?

18941Knowing where to store user data is tough.  Many variables must be considered before making a final decision, and the choice itself is never easy. PortalGuard offers two different options for storing user-specific data: the file system and an SQL backend.  While the initial choice may be daunting, it really is a no-brainer when you think about it.

For many administrators, implementing an additional component on top of PortalGuard is nothing more than a nuisance.  When you dig in deeper, however, implementing an SQL backend is incredibly simple, and the benefits to end-users and administrators alike far outweigh the initial ‘cost’.The Question:

“Why should I use the SQL Back-End with my PortalGuard implementation?”

The Answer: 

Utilizing the native support that PortalGuard provides for integrating with a SQL backend improves security and data compliance. Furthermore, many of PortalGuard’s most useful features require SQL integration in order to function.

Security and Compliance – Prime Drivers for a SQL Back-End

Security is the primary concern for every tech admin.  That’s about as close to ‘gospel’ as you can get in the tech industry.  Whether you are looking to maintain PCI Compliance, or just want to keep up to date with the latest NIST security recommendations, user data security is high on your list. It’s not always enough to store enrollment data on a server in a text file, and that’s where the PortalGuard SQL Back-End comes into play.

Text files offer little in the way of security – any application can open them, and anyone can read them.  SQL Databases, on the other hand, come with a host of built in and ready to use security measures to help secure your end-user data from start to finish. Built in access control, server-level security measures, and database-specific procedures make SQL a logical choice for storing end-user data.  You can even use TDE to go the extra mile and encrypt everything at rest!

The simple fact of the matter is this: If you want best practices for data storage in PortalGuard, implement an SQL backend.

Additional Functionality for Administrators and End-users Alike

A key benefit that PortalGuard's SSO solutions offer over other options is based on a simple idea: More. PortalGuard provides more than just the essentials.  The same holds true for implementing an SQL backend.

PortalGuard’s SQL Back-End not only allows for more secure data storage and access, but it also primes an organization for the use of a whole suite of additional features. 

Feature enabled by the SQL Back-End range from enhancing the administrative experience and usage, to benefiting the end-user directly, and just about everything in between. For clarification, I’ve included some of the most popular features available to PortalGuard Customers that move forward with an SQL Back-End – at no additional cost!

SQL-Based PortalGuard Features:

    • CAS Single Sign-On requires the server-to-server exchange of an authentication ‘ticket’. CAS Servers handle this exchange through the use of an internal database outside of the typical authentication flow for added security.  PortalGuard’s CAS implementation utilizes the existing SQL Back-End for this functionality.
  • Announcements
    • Announcements offer a unique method of communication between Administrators and End-Users. Administrators can configure Announcements within PortalGuard via a web-utility, and decide where the announcements appear, which users can see them, and even how long they remain visible. While not limited to education environments, more information can be found here: Benefits of Announcements on the Login Portal for Education
  • Administrative Reporting
    • The ability to report on activity within a solution is crucial to determining its success. PortalGuard includes built-in reporting capabilities, with further allowance for customizable reports based on existing user data.  With the SQL Back-End in place, reporting is easily configured and takes up a small footprint in order to provide huge return.
  • Contextual Two-Factor Authentication
    • PortalGuard’s Contextual Two-Factor Authentication provides administrators with fine-grained control over the authentication requirements placed on users. If you want to be able to block users from a certain geographical location, or implement two-factor authentication when users are accessing the solution over the internet, Contextual Authentication makes it simple, without sacrificing security.
  • Support for Load Balanced Environments
    • Larger environments often find that a single server strains under the load of so many users. Thankfully, PortalGuard fully supports load balancing to keep things running smoothly and efficiently throughout.  While not a requirement, the use of a SQL Back-End in these environments helps ensure that each PortalGuard server has access to the same user data without the need for manual duplication or upkeep.
  • Self-Registration
    • While not always a requirement, PortalGuard also supports the ability for User’s to register their own accounts with an organization. This feature relies heavily on the SQL back-end to ensure that users are not created willy-nilly, and no data leakage is at risk from the primary repository.

So, Where do I Go From Here?

If you are interested in the SQL Back-End for PortalGuard, you have some options. If you are an existing customer, feel free to check out our recent blog article or reach out to our Technical Support team to schedule a meeting to discuss this implementation in more detail.

If you are interested in becoming a PortalGuard customer, please Contact Us, or test out some of our functionality over at the Sandbox

Subscribe to the BIO-key blog!

Tags: Compliance, contextual authentication, information security, PortalGuard, Product Updates, SQL, User Experience, Single Sign-On, #userexperience, Ask Christopher, CAS SSO, end-users, NIST, cost-effective