Pass Device Context to SAML apps using Limited Access

Limited Access allows you configure Okta to pass device context to certain SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. apps through the SAML assertion during appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. authentication. The app can then use that information to limit access to certain app-specific behaviors, such as user permissions to edit the app or download files from the app.

This feature works with:

Windows, macOS, iOS, and Android devices
Custom and OINAn acronym for the Okta Integration Network. The OIN is comprised of thousands of public, pre-integrated business and consumer applications. As an on-demand service, OIN integrations are continuously validated, always up to date, and constantly growing both in number and capability. Okta performs a single integration with an ISV or SP, providing thousands of end users with point-and-click customization for their orgs. SAML apps able to consume the device context attribute

Prerequisites

In the Okta Admin Console

(Necessary in Production orgs only) If you are passing device context to an OIN app, go to the AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. Console Settings > Features and enable Dynamic SAML attribute statements for OIN apps.
Enable Device Trust in the Okta Admin Console (Security > Device Trust)
Configure a Device Trust sign on policy for the app (Applications > app > Sign On tab)

For details, see the Device Trust document appropriate for your implementation.

In the 3rd-party app

Configure the app to consume the device context received in the SAML assertion and specify the app behaviors you want to control based on the context.

Supported attribute values

When this feature is configured, Okta passes one of the following attribute values to the app in the SAML assertion according to the Attribute Statement and app sign on policy you configure in Okta.

Attribute Value	Definition
TRUSTED	User’s device is trusted as defined by the Okta app sign-on policy
NOT_TRUSTED	User’s device is untrusted as defined by the Okta app sign-on policy
UNKNOWN	The device context is unknown because one or both of the following is true: Device Trust is not enabled for the given device type (Security > Device Trust) Device Trust is not configured in the app’s sign on policy (*Applications > app* > Sign On > Sign On Policy**)

Attribute Value

Definition

TRUSTED

User’s device is trusted as defined by the Okta app sign-on policy

NOT_TRUSTED

User’s device is untrusted as defined by the Okta app sign-on policy

UNKNOWN

The device context is unknown because one or both of the following is true:

Device Trust is not enabled for the given device type (Security > Device Trust)
Device Trust is not configured in the app’s sign on policy (Applications > app > Sign On > Sign On Policy)

Notes

The Attribute Value passed to the app is enforced for the duration of the session.

You can enter Expression Language to map Okta terminology to ISVAn acronym for independent software vendors. Okta partners with various ISVs (usually producing enterprise applications) to integrate on-premises, in the cloud, or native-to-mobile devices with Okta.-specific terminology.

Procedure

Complete the Prerequisites.
If you have not done so already, create a custom app or add an OIN app through the Okta Admin Console.
- For creating custom SAML apps, see Integrate your app with Okta.
- For adding OIN apps, see Add applications. Your app must support SAML.

Add an Attribute Statement to the app (for more details, see Dynamic SAML Attributes):

You can add the statement while creating a new app or as an edit to an existing app.

When creating the app:

In Step 2: Configure SAML, scroll to the section Attribute Statements (Optional).

– or –

To edit an existing app:

The procedure varies depending on whether you are editing a custom app or an OIN app.

If editing a custom app

In the Okta Admin Console, go to Applications > Applications.
Click the custom SAML app.
Go to the General tab, scroll to the section SAML Settings, and then click Edit.
Click Next.
Scroll to the section Attribute Statements (Optional).
Continue to Step 4 below.

If editing an OIN app

In the Okta Admin Console, go to Applications > Applications.
Click the OIN SAML app.
Go to the Sign On tab, scroll to the section Attribute Statements (Optional), and then click Edit.
Continue to Step 4 below.

In Name, enter a name for the attribute you want to add.

The maximum length for this field is 512 characters. The Name attribute must be unique across all of the user and group attribute statements.

In Name format, select Unspecified.
In Value, select device.trusted.

The maximum length for this field is 1024 characters.

You can use the Okta Expression Language to transform the value as needed for your use case.

For example, to map Okta terms for a trusted device context to relevant Salesforce terms, you would enter this statement in the Value field:

device.trusted == "TRUSTED" ? "HIGH ASSURANCE" : "STANDARD"

The above statement transforms terms as follows:

Okta device context attribute	Salesforce term
TRUSTED	HIGH ASSURANCE
NOT_TRUSTED	STANDARD
UNKNOWN	STANDARD

To add an additional statement row, click Add Another. Repeat until all necessary attributes are defined.
Click Next.
Click Finish when done.

Attribute Statement details

Here is an Attribute Statement sent to an app through the SAML Assertion showing the device context of an untrusted device:

<?xml version="1.0"?>

<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">

<saml2:Attribute Name="DeviceTrustSignal" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

<saml2:AttributeValue xmlns:xs="http://www.w3.orgThe Okta container that represents a real-world organization./2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">NOT_TRUSTED </saml2:AttributeValue>

</saml2:Attribute>

</saml2:AttributeStatement>