I would like to know about the flow of communication for SDI authentication on AnyConnect client and ASA 5520.
My customer wants to use RSA SecurID On-Demand Authenticator (RSA SecurID On-Demand token) between AnyConnect client and ASA 5520 for SSL VPN.
I understand ASA provides the following two modes to allow SDI authentication.
Native SDI - The ASA communicates directly to the SDI server for handling SDI authentication
RADIUS SDI - The ASA communicates to a RADUIS SDI proxy (such as Cisco ACS) and the RADIUS SDI proxy communicates to the SDI server, it means that the ASA does not communicates directly to the SDI server.
I think, In general (not consider ASA), the client (remote user) needs to access web page on SDI server to get a token for SDI authentication when it starts/setup SSL VPN connection. However, I don't understand clearly that how SDI authentication works if I use ASA as secure gateway and configure ASA to allow SDI authentication.
So my question is how SDI authentication works on ASA when I use ASA as secure gateway and configure ASA to allow SDI authentication (in either modes).
The customer does not want the AnyConnect client to communicate to the SDI server directly, but allow to communicate to ASA only because of their security issue. I don't know why the customer say so...
I found the following information out from CCO.
When a remote user using RADIUS SDI authentication connects to the ASA with AnyConnect and attempts to authenticate using an RSA SecurID token, the ASA communicates with the RADIUS server, which in turn, communicates with the SDI server about the authentication.
Does it mean that the AnyConnect client does not have to communicate to the SDI server directly for SDI authentication when it starts/setup SSL VPN connection and the AnyConnect client only needs to communicate to the ASA, because ASA communicates to SDI server (instead of the AnyConnect client) as proxy?
Your information would be appreciated.
I had a quick look at the datasheet
I could only find the SMS authentication code as "on demand", ie. RSA will communicate somehow with Cellular provider network to deliver SMS with token part to user. (Telephone number shoud uniquely identify a user)
Please note that it's a bit suspicious if the device you authenticate to provides you authentication credential :-)
Unless you mean of a scenario where user connect THROUGH ASA to request a token (be it via NAT or maybe via SSL portal?) in anyway, ASA is usually oblivious to the fact that user has their authentication derived from two parts.
Let me know if you meant different on demand token.I'm curious to see what RSA has in store for us.