As of version 2020.04.011, Pyramid will offer new settings to streamline Windows Authentication SSO implementations. This will offer the benefit of Win Auth and Kerberos delegation where and when needed, while trying to remove the very taxing nature of these frameworks on the web application, the host servers and the related Active Directory.

Typical Use Cases

Using Windows Authentication

Win Auth is often employed by enterprises to deliver single sign on (SSO) for their end users by harnessing the power of Active Directory and the Windows desktop. Unfortunately, it is an old and cumbersome framework, that can retard the equivalent processes running with alternative authentication models by as much as 40-50%. Never-the-less, it is a popular choice. Pyramid FULLY supports Windows Authentication for SSO in this respect.

Using Kerberos Delegation

Although Kerberos is the underlying technology to Win Auth, it is not really needed beyond the user authentication stage. The only need for it is when a destination data source requires the user to authenticate and connect to it using Kerberos. By blindly employing Kerberos delegation across the entire Pyramid cluster for all requests all the time, customers impose a heavy performance burden on the infrastructure as described above. (With a strong network and well-oiled Active Directory, these  effects may remain unnoticeable).

The cost of Kerberos is further compounded by the need to set up complex Active Directory delegation rights between services, "double hopping" (using the dreaded "SPNs") and conforming the implementation to Windows servers only. (Employing Linux in this story is practically impossible).

All-On

The "all-on" model is typically how many Win Auth+Kerberos web applications are designed, since engines like Windows IIS and .Net give you little control on how to manage these processes.

Currently, there are only 2 data sources in Pyramid that support Kerberos delegated authentication: MS SQL Server relational access and SAP BW logon ticket authentication. (Other AD authenticated sources like MS OLAP, SAP BW SNC etc still use the Active Directory infrastructure but do not require Kerberos delegation). Given how seldom the entire pipeline is fully needed intact for just these 2 items, the "all-on" approach is expensive.

Luckily, Pyramid's internal infrastructure and architecture has allowed us to modulate this approach and challenge the way classical Win Auth+Kerberos applications operate.

Pyramid Optimizations

To get the best of all worlds, Pyramid is now offering new configuration options to better handle the above scenarios:

1. Customers can use Win Auth for site and application authentication, but can elect to ignore Kerberos delegation fully if they have no need for it. This can reduce the extra 40-50% overhead described above to almost zero. This is highly recommended and is the DEFAULT setting in the client security settings of the admin console. It also means delegation configurations and SPN's are not required.
2. Customers can elect to use Win Auth and choose to keep the Kerberos delegation in place. However, the Kerberos layer will now be minimally used only when required for connecting to the above mentioned data sources. At all other times, it will be ignored. This will deliver on all functional aspects without much of the burden and performance costs described above for most of the system's operations. (Note that this option will still require Active Directory delegation configurations and SPN setups.) This option must be verbosely enabled in the client security settings of the admin console.

Security Concerns

In spite of the changes, there is no degradation in system security, since Pyramid manages its own tight security infrastructure and communication protocols irrespective of which optimization path is chosen above. These infrastructure elements remained unchanged from previous versions.