Island Enterprise Browser Device Trust Integration Kit

Using Island Device Signals

The Island Enterprise Browser Device Trust IdP Adapter looks for a specific request header to determine where the request originates from.

Requests from verified Island Enterprise browsers

For requests originating from verified Island Enterprise browsers, the adapter initiates its flow as described in Overview of the SSO flow to retrieve device signals.

The adapter completes the flow successfully if the request originates from a managed browser and the adapter is able to retrieve device signals for the browser that are configured to work with the Island Enterprise platform. Depending on the availability of the attribute in the device signals, the adapter fulfills several core contract attributes, such as:

  • browserVersion

  • displayName

  • hostname

  • macAddresses

  • operatingSystem

The deviceTrustEnabled core contract attribute is always set to a value of true after a flow completes successfully.

Requests from non-Island browsers or unverified and unmanaged Island browsers

For requests originating from non-Island browsers or unverified Island browsers that aren’t managed, the adapter immediately returns a SUCCESS status and only one core contract attribute, deviceTrustEnabled, set to a value of false.

Authentication policy configuration

The authentication policy should typically use the deviceTrustEnabled contract attribute to make decisions related to stepping authentication flow with multi-factor authentication (MFA).

The adapter fails the authentication flow for the following cases:

  • When a request originates from an unverified browser, causing the adapter to not retrieve device signals.

  • When a runtime error occurs, such as a network error invoking the Island APIs. This can result in timeouts and other unexpected errors.

The authentication policy should be configured to handle these cases. For example, the following policy configuration describes a typical use case where:

  • A request coming from a trusted device goes through HTML form adapter authentication only.

  • A request coming from an untrustworthy device goes through HTML form adapter authentication as the first factor followed by MFA authentication as the second factor.

(Click the image to enlarge it.)

Screen capture of an example policy configuration.