Why use Okta with…Box? Skip to main content
https://support.okta.com/help/blogdetail?id=a67f0000000l1sxia0&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fblogdetail
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.

Why use Okta with…Box?

May 04, 2016 | by Edward Holliday in Okta Application Network
Welcome to the first in a new series of blogs – ‘Why use Okta with…’ – in which I’ll be running through the advantages of implementing Okta solutions with various applications that you may be using within your business.

First up is Box who were a sponsor at Okta's Identity & Mobility Forum. As companies continue to adopt Box throughout the enterprise, secure identity and access management becomes increasingly important.


Okta vs ADFS: It’s about more than just SSO!


Active Directory Federation Services (ADFS) is a well-known and popular solution for implementing SSO with Box. It has the advantage of being free to obtain, but it’s not free to set up and get working in terms of troubleshooting and configuring. Sure, ADFS certainly has its advantages and benefits when using it for Box, for example:
  • Set up SAML for SSO between a customer’s Active Directory environment and their Box tenant in the cloud
  • It can also provide basic Just-in-Time Provisioning when a new employee without a Box account accesses their Box tenant for the first time. A new account can be created for them using the Box “on the fly user registration” flag/ feature. This relies on the user signing in to create the account for the first time.
But what happens to the Box account when the employee leaves? How do we clean up Box accounts from a licensing or security perspective? Could former employees access company material from outside the network? Even if SSO with ADFS is enabled can they still get access with their Box username/password or does SAML-only mode need enabling?
 

So is that it for SSO with Box? What can an Identity Provider like Okta do?


While Okta does SAML for SSO to Box, it has the added benefit of taking advantage of the Box API to provide full provisioning and Box user management support.
  • Okta provides birthright or departmental Active Directory group based provisioning of new employees which will create Box personal folders and associate the new employee with relevant Box groups - all via the Okta-Box API. Not only does it do this for new employees being on boarded to the business each day or week but this feature scales to enable thousands of new Box accounts for organisations rolling out larger Box deployments!
  • Okta offers a flexible MFA solution to secure sensitive Box tenants or secure access by remote employees with a MFA policy. Customers with Okta can make use of Okta verify with push to do so.
Okta Verify with Push
  • Okta also integrates with Netskope to offer DLP control of sensitive Box documents
  • Okta Mobility Management has a mass deploy option for native Box app deployment for large groups of employees using BYOD
  • Okta Mobility Management can then be used to securely wipe Box data from one of these registered devices
  • And Okta provides real-time suspension (of Box accounts) for users deactivated in the employee AD (terminated or suspended AD account.)


How does Okta help address the security concern of former employees accessing company content in Box?


There’s a simple answer to this: combine Box best practice with Okta de-provisioning.
Box best practice: Here’s a bit of Box best practice for when you set up your SAML partnership with Box Consider enabling the “SSO required” flag in the Box admin console to guard against insider attacks from former or disgruntled employees! This way you’ll prevent someone who normally uses SAML from setting a backdoor password and help them access the same content after they’ve left the company!

Here’s the scenario:
a) Whilst they can still access their work email they complete a password reset:
User-added image

b) A password is then set to allow log on from home when their SAML access is no longer available which they can then use to log in manually from home:
 User-added image

Okta Offboarding: Secondly, Box is the first to support the new Okta Offboarding feature. This means that when a user is deactivated or suspended in AD, not only will the Okta account do the same but access to the employee’s Box account can either be revoked into an "inactive" state or "deleted" with data transfered to a service account. Offboarding helps prevent former employees from accessing company material.
 
offboarding
 

What other benefits are there to using Box with Okta?

 
  • Okta can be set up for a new Box customer in a couple of hours, and uses a small footprint AD Agent to authenticate and then provision employees to Okta’s cloud service, before creating Box accounts for them to sign on to
  • Okta automates the complex ADFS signing / certificate administration – certificates won’t expire suddenly with Okta and it’s far easier to set up a partnership with Box in Okta’s user-centric UI than the ADFS Snap-in console
  • Box customers who use Okta for their deployment find that Box is far quicker to deploy and roll out to their business. Far less time is wasted troubleshooting issues with ADFS Federation or employee SSO access!
For more information on Okta/ Box deployments, head to https://support.okta.com/help/articles/Knowledge_Article/20827717-Box-Deployment-Guide and Box for EMM https://support.okta.com/help/articles/Knowledge_Article/Box-for-EMM stay tuned for more 'Why use Okta with...' blogs coming up in the future.
 

Comments