Box Deployment Guide Skip to main content
https://support.okta.com/help/oktaarticledetailpage?childcateg=&id=ka0f0000000u25wkac&source=documentation&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fdocumentation%2fknowledge_article%2f20827717-box-deployment-guide
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Box Deployment Guide
Published: Feb 3, 2015   -   Updated: Jun 22, 2018

Managing Users
     Creating Personal Shared Folders
     Account Creation
     Account Deactivation and Reactivation
     About Profile Updates
     Account Imports
     Group Management
Recommended Setup
Rollout Recommendations
Contingency Plan
About Box Integrations
Additional Information


Box supports SAML 2.0 for federated single sign-on. Box SAML supports both service provider (SP) initiated and identity provider (IDP) initiated SAML negotiation.

For SP-initiated SAML, a user hits a deep link that is tied to their Box.com org. The link alone does not allow Box to determine which IDP you belong to.  Box presents a sign-in page and if SAML has been enabled, the user is only required to enter a username.  When accessing the sign-in page for the very first time after SAML has been enabled, select the log in using your company credentials link and click the Continue button. Based on your Box account name, Box can now redirect to the IDP for authentication.

For IDP-initiated SAML, an assertion is sent from Okta when a user tries to access Box by clicking on the app icon on the Okta home page.

User-added image

A few important points about Box SAML configuration:

  • Make sure that the right certificate and endpoint information is shared with your Box account rep. Also, make sure you specify that your identity provider is Okta.
  • As highlighted above, the SP-initiated flow is different from the typical SAML service provider. Make sure your end users understand the usage model.
  • It is possible to shut down front-door access to disable sign in using a username and password. This ensures that all sign-ins are performed with SAML. Let Box support know if you want this behavior.
  • Box SAML is supported in other non-browser-based clients including BoxSync on Windows and Mac and Box iPad/iPhone app. An embedded browser is used by these clients to perform SAML authentication. Users are presented with the Okta sign-in page. After authentication occurs, a token is generated for the client and the end user can access the service. For most of these clients, users are not required to sign in every time.  The token is persistent and might expire based on your administration settings.

top

Managing Users

Provisioning integration enables Okta to integrate with Box APIs. The integration uses OAuth for authentication so Box admin credentials are needed during setup to authorize Okta to perform actions in Box on the admin’s behalf. 

Box is switching to a V2 API and this requires the Box admin to re-authenticate for Box provisioning to work. To reauthenticate, go to your Okta Administrator Dashboard and select Applications > Box > Provisioning and click the Authenticate with Box button.

You can authenticate to Box in two ways:

  • One way is to enter the Box admin’s username and password.
  • If you have SAML authentication on Box, and Box is set to SSO required mode, you only have to enter the username and leave the password blank. This causes Box to SAML authenticate with Okta.

 User-added image  

SAML authentication assumes that your Okta admin account is mapped to the Box admin account. If this is not the case, there are three options:

  • If there is no Okta user mapped to the Box admin account, then you can select an Okta admin account, disable user provisioning in your Box provisioning features, perform an individual Box assignment to this user by setting the Box username to the primary Box admin. (You can disable user provisioning by selecting Applications > Box, select the Provisioning tab, deselect Provision new Box accounts from Okta, and click the Save button.)
  • If there is an existing Okta user mapped to the Box admin user, but the Okta user is not an Okta admin, just promote the Okta user to an Okta admin, sign in with this account and re-authenticate by selecting Applications > Box > Provisioning and clicking the Authenticate with Box button.
  • Contact Box Support to switch from SSO Required to SSO Enabled mode. SSO Enabled mode allows you to authenticate by entering your username and password. 
  • If you switch from standard sign-in (SAML not configured) to SSO Enabled (SAML) in Box, all users are affected due to the change in the sign-in prompt. See the image below for how sign-in changes for SSO accounts. Make sure that you inform your users about this change to the sign-in procedure before configuring the SSO Enabled feature.
    User-added image

top

Creating Personal Shared Folders

Your Box provisioning features enable you to automatically create a personal shared folder for your users during user provisioning. For more information on this feature, see Configuring Box to Create a Personal Shared Folder.

top

Account Creation

Account creation allows Okta to create new accounts in Box.

top

Account Deactivation and Reactivation

Okta deactivates a user's Box account when the user is deactivated in Okta. Box does allow deletion of an account. You should sign into Box as an administrator to perform this task which allows content associated with the user to be transferred to another user. Okta does not delete the user. Okta sets the user to the inactive state, allowing administrators to clean things up before deciding on whether a deletion is necessary. When you set users to a deactivated state, they cannot access their Box accounts.

top

About Profile Updates

Any profile changes detected in Okta are pushed to Box. This includes first name, last name, usernames, etc. 

Note: With the Push Okta user profile updates to Box feature enabled in your provisioning settings, Okta overwrites any profile changes that you make using Box or any other app. We recommend that you either do not edit Okta-mastered users in Box or disable this feature.

top

Account Imports

This feature is automatic when you configure provisioning. Import enables Okta to map active Box accounts to Okta users. This is typical for the initial app assignment bootstrap. You can also use a CSV file for account mapping, which is similar to what API import does.

top

Group Management

Managing groups requires special considerations. See Managing Groups for Box for more information.

top

Recommended Setup

User-added image

The recommended setup consists of the following:

  • SAML configured between Okta and Box.com
  • Provisioning with all options enabled
If Active Directory integration is required, the topology appears as follows:

User-added image

With AD integration configured, end users benefit from the following:

  • Seamless Desktop SSO when signing in from behind a firewall
  • SAML into Box.com Okta using AD credentials when outside the firewall or configuring SAML-enabled clients

top

Rollout Recommendations

  • For SSO, SAML should be the goal. This enables centralized access management since all Box authentication (web-based and client-based) goes through Okta as the identity provider.
  • Test SAML with a small group of users first. Box allows SAML to be turned on in two modes. SSO enabled mode enables SAML but still allows end users to use their usernames and passwords through the sign-in page and thick clients. For production, SSO required is the ideal mode in which username and password sign in is not permitted. This forces sign in to always go through the SAML IDP which is Okta in this case.
  • Inform your end users about the SAML usage model. Box.com cannot recognize the domain or IDP that the user belongs to unless the Box username is provided. Both web access and thick clients allow users to specify their usernames.
  • When you enable provisioning, choose the account for the integration carefully. We recommend that you use a system account. If an end-user account is used and then later deactivated, the OAuth token expires and provisioning integration breaks.
  • We recommend that you enable user deactivation and reactivation to ensure automated deactivation happens when a user is deactivated in Okta or in AD which is integrated with Okta.

top

Contingency Plan

If SSO must be disabled between Okta and Box immediately, contact Box Support to resolve the issue.

top

About Box Integrations

If Box is integrated with another application (for example, Salesforce.com), and you attempt to launch Box from within that app, you must sign in with your Box credentials. Okta cannot automatically sign you into Box when it is integrated into another application. The only way to avoid having to do this is to enter your Box credentials before signing into the app that Box is integrated into.

top

Additional Information

Refer to Box Platform API documentation from Box.com.