Establish Identity Securely for an Intelligent Advisor Interview

To establish the identity of the user, giving context to the Intelligent Advisor interview, the application which starts the interview will need to pass some identifying information about the logged on user or the user’s session via URL parameters.

The information which is passed on the URL parameters should be:

  • meaningful only to a web service connector
  • made as secure as possible by using encryption, and
  • obscure to anyone attempting to intercept the request.

The amount of information provided should also remain minimal, but since Intelligent Advisor is separate from the services which call it, some information about the owner of the interview session must be passed so that context can be given to subsequent Load and Save requests.

The encryption of identifying information is the responsibility of the web application.

The encrypted information is appended to the start session URL as parameters (for more information, see Data Integration). Any parameters will be passed to a web service connector within Load and Save requests. The connector receives the encrypted key via the URL parameter and decrypts it. The connector then uses the decrypted key to securely retrieve and store data. For more information, see Understand Security for Web Service Connectors.

Note: For maximum security, an interview session with any user-identifying URL parameters should always be started using HTTP POST instead of GET.

It is recommended that the start session URL does not carry the value of the user’s credentials at all, but instead passes information about a particular session to the connector, such as the session ID or a generated key which relates only to that session.

This key or session ID needs to:

  • have a limited lifetime
  • be encrypted in such a way that only the connector knows how to decrypt the parameter into useful information and
  • be obscurely named to prevent an interceptor from interpreting the purpose of the parameter.

For example, https://[mysite]/web-determinations/startsession/[myDeployment]?con=8d8v09s98xc90w9ds.

This practice is recommended because:

  • If the URL start session parameters include the user name and password in plain text, an interceptor will immediately know the user credentials, and because the credentials come from a particular IP address an interceptor can also determine where to use that information.
  • Applying encryption to these parameters as a single level of security would only place one hurdle in the path of a potential interceptor. In other words, if the URL contains an indication of what those values represent (for example, strings like 'user' and 'password'), once an interceptor discovers the encryption method for the values it will be easy to link each credential to its decrypted value. Renaming ‘user’ and ‘password’ to ‘a’ and ‘b’ brings a better level of obscurity but the fact is that user credentials are being passed and may be discovered by an interceptor, compromising all of the user’s data.
Related Topics