Edit

Share via

SSO EAP-TLS PIN Caching Behavior

  • Article

This topic provides a step-by-step approach for resolving matters of session resumption and re-authentication of a roaming user in an SSO EAP-TLS environment.

Step-By-Step Approach

The following list represents a step-by-step approach for resolving matters of session resumption and re-authentication of a roaming user in an SSO EAP-TLS environment.

  • After the first successful authentication in an SSO environment with EAP-TLS, the supplicant retains all user credential related information by default.

    Note

    Although subject to the particular supplicant implementation, it's advisable for the supplicant to retain the entire EAP_CONFIG_INPUT_FIELD ARRAY structure that the supplicant last used in the EapHostPeerQueryUserBlobFromCredentialInputFields call to EAPHost.

     

  • As the user first roams and the re-authentication begins, the supplicant calls EapHostPeerQueryUserBlobFromCredentialInputFields again with the same EAP_CONFIG_INPUT_FIELD ARRAY structure; the supplicant must also pass in the same user BLOB retained after the first successful authentication.

  • EAPHost then passes the information in the user BLOB to the EAP method.

  • The EAP method in turn updates the user BLOB with credential fields - the PIN for example - provided in pEapConfigInputFieldArray, and keeps the remaining values - the server certificate for example - as it was in the original user BLOB.

  • After completing these steps, the supplicant can resume authentication in a normal way by calling the EapHostPeerBeginSession run-time function with this user BLOB.

SSO EAPHost Scenarios

SSO and PLAP