F5 APM – In-Line SAML SSO Architecture

Federation services along with Single Sign-On (SSO) is increasingly configured by many companies. I think SAML is the most used standard which can be configured in many cloud service providers. For instance, we can configure Application Access with Azure AD easily with F5 APM thanks to the SAML standard. However, we can also configure a little bit more complex architecture such as the In-Line SAML SSO architecture where there are two SAML flows: one from F5 APM to the application with the aim of providing in-line SSO for service providers (SP) not directly reachable by the client, and another flow from clients to F5 APM, which is configured as a service provider (SP), against an external Identity Provider (IdP).

Traffic Flow

The traffic flow for an In-Line SAML SSO architecture has mainly 3 steps. Firstly, the user is redirect to the external SAML IdP and once the user is authenticated at the IdP, the user is redirected back to the F5 APM. Secondly, session variables are assigned and an iRule Event is triggered to establish a sideband connection to another virtual server. Finally, this virtual server gets variable values through execution of another iRule to allow SAML SSO access for clients.

BIG-IP as SAML IdP and SAML SP

The SAML configuration for the In-Line SAML SSO architecture is easy to configure. On one hand, we have to configure the SAML SP Service and the SAML IdP Connector. Binding the SAML SP Service to the IdP Connector. On the other hand, we have to configure the SAML IdP Service and the SAML SP Connector. Binding the SAML IdP Service to the SP Connector. In addition, the SAML IdP Service configuration will be used as SSO configuration for the second SAML traffic flow.

IdP Service

The iRule event triggered is mandatory to establish the TCP based sideband connection to the second virtual server. This iRule converts the APM session variable to a TCL variable and sends a HTTP request over the sideband with the username in a query string. What’s more, this iRule is really important because it is useful to start the second SAML traffic flow from the F5 APM to the internal service provider.

send-sideband iRule

There is another iRule attached to the second virtual server which parses the query string and splits the first parameter name from the value. This value is next stored as the username variable. Finally, the TCL username variable is saved as a session variable which is used in the SSO configuration. For instance, it can be used for Kerberos SSO, NTLM SSO, Form based SSO, etc. This iRule is always triggered when there are requests to the second virtual server.

receive-sideband iRule

To sum up, the In-Line SAML SSO architecture with two SAML traffic flows is a little bit more complex configuration than those configurations which only have one SAML traffic flow. However, this architecture is useful for lots of companies and it is also supported by F5 APM.

Thanks my friends!! Have you ever configured an architecture like this?