Single Sign-On (SSO) is a constant talking point. You must have seen articles touting the benefits of SSO. Of course, we are in no way innocent either. SSO enables users to authenticate multiple applications and websites by logging in only once with a single set of login credentials. In other words, SSO provides simplicity in an authentication world that can be unnecessarily confusing. However, where do administrators turn when standard SSO is not an option? The easy answer is to use form-based authentication — a bright successor in a long line of SSO alternatives.
Form-based authentication is technically just a preferential term for the act of using standard web- or internet-based login forms. These 'forms' are generally editable and easy to use, and only require a fair amount of effort from the end-user before authentication is underway.
A standard login form
Form-based authentication allows for single sign-on access to legacy applications that have not adopted SAML.
Instead of making users and organizations ‘bite the bullet,’ form-based authentication provides a workable alternative when partnered with a flexible IdP.
It starts with the user being presented with an editable form that they must fill in and submit to log into a service. Generally, form-based authenticators use HTTP and HTML. However, with the evolution of SSO protocols and standardization of streamlining the authentication process, form-based authentication has taken on another meaning entirely. Form-based authentication is now a modern method for integrating applications into an existing Identity Provider (IdP) for SSO. Specifically, form-based authentication integrates older legacy applications and other web-based applications that do not support standard SSO protocols, such as SAML, Shibboleth, CAS, or Kerberos.
There is a defining characteristic within form-based authentication between the client and server:
PortalGuard on IIS is effectively a very lean .NET application. Part of what makes it “lean” is that it does not utilize .NET view state or session state (which would ordinarily be used once a user has logged in). As such, all of IIS’s session state options (InProc, StateServer, SQL server, custom) can be effectively ignored. This is a key point that ensures different PortalGuard servers can easily handle any part of a larger PortalGuard “action”.
The PortalGuard IIS website is configured to use .NET’s Forms-Based Authentication (FBA). Once a user has logged in, IIS creates and maintains their user identity with a session-based HTTP cookie (default name: “.ASPXAUTH”). PortalGuard uses this cookie alone to determine the authenticated name for the user when performing any “post login” actions such as modifying challenge answers or enrolling a hardware token. By using a load balanced server alias each PortalGuard IIS server in the load balanced cluster should automatically receive this HTTP cookie.
The lone consideration for IIS load balancing is that IIS’s FBA cookies and form viewstate are encrypted and checked using the IIS server’s validation and decryption keys. These can be manually set and must be identical across all PortalGuard IIS servers in a load balanced configuration. This allows an FBA cookie created by one PortalGuard IIS server to be honored by the other PortalGuard IIS server(s). Please see this MSDN article for information about synchronizing these keys across the servers in a web farm.
Integrating Form-based authentication is not particularly secure. In form-based authentication, the user credentials that the client is inputting at the login page is sent as a plain text, and the target server is not authenticated. This form of authentication can expose your usernames and passwords unless all connections are over SSL. Without SSL, then someone who intercepts the transmission can decode the username and password information.
This means form-based authentication can be secure with the right measurements and by incorporating an SSL certificate into the website where the form is hosted. Additionally, implementing a form-based authentication method with multi-factor authentication (MFA) can drastically improve cybersecurity measures, as in the case a threat actor intercepts the form submission, they still need another factor to login, greatly mitigating the risk of a data breach.
Flexibility is a key consideration when adopting an SSO solution or finding an IdP for your environment. Unfortunately, SSO alternatives are often left on the cutting room floor. However, they should never be left out when looking to provide the best solution for your end-users and administrators. SSO is only the first step towards balancing security and usability. Applications that do not fit the mold will weaken the overall benefits of the SSO solution in place. Form-based authentication exists to modify that mold.
Many organizations have embarked on a journey of digital modernization, migrating older applications over to their modern counterparts. However, legacy applications do not often support modern SSO protocols. Furthermore, as seen in many educational institutions, not every modern application is built with SSO in mind. Form-based authentication is the best SSO alternative to retain the same level of convenience and security found in true SSO.
Remember, form-based authentication is a great alternative with the right measures in place through adding security measures with SSL for your forms and prompting users to use SSO at appropriate times. As more users move to an online or hybrid environment, using a large variety of applications will be necessary, and through SSO and SSO alternatives, this process becomes easier for the end-user. However, legacy applications will need time to accept SAML SSO, so until then, a method that can be secure and make the login process easier for users will be necessary.
With PortalGuard, form-based authentication is part and parcel to a thorough SSO solution. Administrators need only configure a template to integrate with the IdP, which stores, hashes, and encrypts authentication data. This data is then used automatically in subsequent authentication attempts without prompting the end-user. The implementation is only as complex as it needs to be, and typically requires no client-side software or implementation.
With form-based authentication in place, there is no reason why security and usability are not within reach.