Understanding how Integrated Authentication through the AirWatch SDK handles user credentials

Understanding how Integrated Authentication through the AirWatch SDK handles user credentials

  • The SDK has a shared keychain that is utilized by applications that have the AirWatch SDK. This shared key chain is only available for devices that are enrolled and have either the AirWatch Agent or Container installed. Devices that were enrolled through the web and that don't have the Agent or Container installed cannot utilize the shared keychain, as access is only granted to other SDK apps via the brokering app (Agent or Container).
  • Apps using the AirWatch SDK can leverage the credentials stored in the shared keychain when presented with an HTTP 401 response.  For example, if a user navigates to a website using the AirWatch Browser and the website requires user authentication, the Browser will attempt to use any credentials stored in the shared keychain.
  • In certain situations, the user credentials may not be in the keychain.  This can occur when using any enrollment process where the user does not directly enter in their password, such as in token enrollment or staging enrollment.  In this event, when first presented with an HTTP 401 response the SDK app will prompt the user to enter their credentials, after which they will be stored in the keychain.
  • Please note that AirWatch does not pull the user's password from LDAP. We rely on the user to input this information onto the device so that the shared keychain or the individual app can have that information as needed.

Example Integrated Authentication workflow

  1. A user navigates to a specified URL using the AirWatch Browser.
  2. The endpoint requires authentication and sends an HTTP 401 response.
  3. The AirWatch Browser receives the HTTP 401. It then confirms that Integrated Authentication is enabled.
  4. The AirWatch Browser checks with the Broker/Anchor app (AirWatch Agent or Container).  If one of them is installed, the AirWatch Browser will ask for the credentials in the shared keychain.
  5. The Broker/Anchor app sends the encrypted credentials to the requesting app; the AirWatch Browser in this case.
  6. The AirWatch Browser decrypts the credentials and passes them to the endpoint.
  7. The endpoint Authenticates the request.
  8. If the Authentication attempt fails, then the Browser will prompt the user for credentials.
  9. The AirWatch Browser will save these new credentials and pass them the next time it is prompted with an HTTP 401 response. The AirWatch Browser will effectively use these as "master credentials," as only a single set of credentials can be stored in the shared keychain.
Have more questions? Submit a request

0 Comments

Article is closed for comments.