HowTo: Auto-Push RSA SecurID as an nFactor Factor on Citrix ADC

Introduction and Background

We were recently working with a customer transitioning their secure access portal from F5 APM to Citrix ADC. In this particular use case, the customer was using RSA SecurID Cloud Authentication Service via RADIUS and the access flow had the following requirements:

• Capture username and password, but auto-push the MFA factor to the user’s phone at login. In their configuration, when logging in via RADIUS, the user would need to enter “1” or “2” into the next prompt to determine if they’d use a push to their mobile phone’s RSA app, or prompt for OTP. The customer required this use case to auto-push to the mobile app (option 1).
• Perform LDAP group extraction on the user post-RSA authentication in order to secure the portal to approved user groups only.

There are a couple of ways of achieving this, and this guide is just one of them (it is possible the ADC variables and assignment option might work, or additional configuration on the RSA side perhaps, or means of combining the MFA action and password and sending it over to RSA which some RADIUS-based MFA platforms support). Our immediate challenge while porting this to ADC was to configure the ADC to send back “1” to the RSA servers to generate the auto-push but needed to capture the network credentials for SSO to the app ADC was fronting (such as Citrix Gateway), and still authenticate to the back-end app and perform group extraction.

The required authentication flow for the use case end to end was: EPA scan > RSA > group extraction & group validation > SSO to app behind ADC. This guide will not go into the full setup details, but rather will focus on the RSA and LDAP authentication requirements.

The solution to the challenges in this particular case was handled by customization of login schemas, no traffic policies required.

Step 1 – RADIUS Factor

The first challenge to overcome was sending back “1” to the RSA server to issue an auto-push MFA prompt to the end-user. We accomplished this using a customized single authentication login schema that was coded with “1” so that it’d always be sent back to the RSA server. If there was a means to send 1+password and RSA could parse it, this would simplify the whole setup, but I nor the customer were aware if we could do this. Sending back just “1” also posed the challenge of RSA trying to authenticate the user (the original intent was to delegate auth to RSA then just do non-auth LDAP group extraction on ADC) but being we’re sending back just “1”, it would choke. So RSA was configured to NOT authenticate the user, and we ensured the login schema was configured not to be used for SSO to the back-end app. We did however capture the username and password the user entered for later use.

With the RADIUS login schema completed, we used it in conjunction with a policy label with the RSA server policy bound. If this was the first factor (no EPA) the RSA policy could be bound directly to the AAA vServer and the login schema associated with the AAA vServer itself.

Step 2 – LDAP Factor

Following the RSA factor and a user successfully processing their MFA push, we needed an LDAP factor. Not just for the group extraction requirement, but now because we had to have an LDAP factor that ADC processed and authenticated the user by. We had available now the credentials from the RSA factor captured and did not want the user to enter them again. Much like a non-authenticating LDAP group extraction factor, we re-used the same logic but with a tweaked noschema login schema configured to perform SSO. In this way, the network credentials captured on the login schema of the RSA factor could be used to SSO to the back-end application successfully provided the user passed the group check factor that followed the LDAP factor.

With this in hand, we created a policy label that used this custom noschema login schema, bound our LDAP policy (with LDAP action configured to authenticate, unlike a regular group extraction factor which often is set to NOT authenticate by unchecking the corresponding box), and set our next factor for the group extraction. If that’s not required, this may be the end of the road for the user, or perhaps you’ll pass them onto some other factor.

Conclusion

With these pieces in place, you should be able to assemble an authentication flow that will auto-push the MFA prompt to the RSA app on the end-user’s phone and replay session credentials captured in the RSA factor onto an authenticating LDAP factor configured to be used for SSO to the app the Citrix ADC is fronting such as Citrix Gateway \ StoreFront or some other non-Citrix app that accepts LDAP credentials.