As organizations start to utilize Software as a Service (SaaS) the concern on how to authenticate users becomes a critical security issue. Many organizations look to federated authentication mechanisms, such as SAML, to help address this security risk. The benefits of using SAML are that user credentials are not replicated across each vendor cloud instance and that it greatly simplifies user management. However, not all applications will be migrated to the cloud due to limitations or security concerns. So when you start adopting SAML what happens to the applications that are left in your data centers.
Many of the customers I work with adopt SAML as an authentication platform for both internal and cloud base solutions. The road block I typically run into here is that they try to implement SAML on all service – this is a “square peg in a round hole” approach. While many commercial applications and programming frameworks are started to support SAML the need to implement SAML on the backend servers is not always necessary.
In my view, SAML works great as a client-side authentication mechanism for self hosted applications but does not always “fit the bill” on a server-side authentication. When you use the F5 BIG-IP to provide Single Sign-on service to your internal applications you have several server-side authentication options to choose from: HTTP basic, form, NTLM and Kerberos to name a few. In certain situations these authentication options are much easier to maintain and implement across a large number of applications.
When using SAML for authentication the IdP provides an assertion to prove the user’s identity. In this situation the F5 does not have the user’s password so HTTP Basic, HTTP form and NTLM authenticate are not possible – this is ideal in security conscious environments because sensitive credentials are not being passed around. However, the F5 can convert the SAML assertion into a token and use Kerberos Constrained Delegation to authenticate the user to the backend web server. A huge benefit to this model is that it scales very well with a large number of applications because most web servers supports Kerberos authentication and you do not have to create one-off APM SSO profiles for each application.
In conclusion, F5 BIG-IP provides organizations the ability to authenticate users securely to services whether in the cloud or in your data center. The important thing to consider when designing your authentication solution is to examine all authentication option available to you and stop trying to squeeze the square peg into the round hole.
Cody Green 
i know this article is several years old but hoping it’s still being monitored. If F5 is configured to use SAML is there a way to still do an AD query? If so, how do we capture the password to send to AD to authenticate the user since SAML doesn’t use passwords?
Sorry for the late replay, maybe this can help someone else. Yes, you can perform an AD Query with F5 configured as either a SAML SP or SAML IdP. You would have to query AD using the credentials in the APM AD AAA object configured in the GUI, not the credentials of the authenticated user. As you pointed out, SAML doesn’t provide the password 🙂