lnu71 (lnu71) asked a question.
Box and Okta and Push Groups
We recently setup an integration with Box and followed the documentation for provisioning in:https://saml-doc.okta.com/Provisioning_Docs/Box_Provisioning.html When we first setup the integration, we decided to use the "Managing Box Groups with Group Push" method as described in that document. In that section is a paragraph that talks about how to deal with pre-existing groups in Box and effectively says that IF you want to manage these groups via Okta then you must import them into Okta and re-push to Box. The way that paragraph is phrased, makes it sound optional, as in IF you DO NOT want to manage them via Okta, then do nothing. In other words giving the implication that Okta will only manage groups setup via Group Push (in the Box app on Okta's site), and any groups that might exist only in Box will NOT be managed by Okta. This is further re-inforced by the last sentence of that same paragraph that states "This migration is required because Okta cannot modify and control preexisting groups that were imported from Box." Which is fine. We want to have some groups controlled by Okta, and some groups controlled by Box. This appeared to work just fine until Okta randomly decided to push some user profile updates to Box. When it did this, it removed the users from any Box managed group to which they belonged. This DIRECTLY contradicts the last statement of that paragraph "Okta cannot modify"... CLEARLY it can... So it sounds like we instead should be using the next method from that document "Managing Groups in Box Using Push Groups via SAML". We originally did not go for this method because of the issue with having to manually remove a deactivated users last group membership from Box. However, this section is not very clear on how exactly it works. Specifically in step 5. It says that you need to specify a filter for the groups you want managed by Push Groups via SAML. This filter will apply to groups that exist in Okta? Groups that exist in Box? Both? It also says that this method can add users to pre-existing groups, AND you can manage groups in Box. How does this work exactly? To add members to a pre-existing group, do we just need to create a group of the same name in Okta? Do we need to import the pre-existing groups from Box into Okta first? Do we need to be running a scheduled import to pick up on changes made in Box? With this method is it possible to have groups that are ONLY managed in Okta and groups that are ONLY manged in Box?(this is our ultimate goal) And then we have the added complexity of having started with one method and now need to switch to the other. What does that mean for the existing Push Groups? If we enable Push Groups via SAML, and use the same filter that we are currently using for normal Push Groups, will it effectively just take over? Or do we need to remove all the normal Push Groups first before enabling them via SAML? Any clarifications on this would be greatly appreciated.
Ok, we figured out where it went wrong. We had enabled "Update User Attributes" as part of the provisioning options. We did this out of habit, because we typically want any Name, Email, Phone etc. changes to flow into our apps. This effectively meant that we had unknowingly setup the 3rd option in that document "Assigning Group Membership as a User Attribute".
Since we were not selecting groups as part of user assignment (actually we are assigning users via groups, but those group assignments do not have any groups selected either), that meant they were all blank. So when a profile update happened, it was pushing an update that said the user was not in any of the groups. We looked at trying to remove "Groups" as a user attribute mapping for the Boxnet profile, but it looks like it's a default attribute that can not be removed. But, we discovered that by performing imports from Box (and setting it on a schedule), it will pull in group membership updates and they will be reflected when looking at the user attributes. This effectively allows us to manage group membership from either side. The only potential problem is if a user is assigned to a group in Box, and then a profile update happens in Okta before an import occurs. However, we don't see this as happening very often. As an added bonus, if a group is defined in the "Push Groups" section, it seems that overrides any groups selected in the user attributes. So we can effectively have groups that are ONLY controlled in Okta, and groups that are ONLY controlled in Box (with a little bit of internal policy definition and training).Hi Louis,
That is correct, when you perform the import you have granularity on what you want to link/push back to Box to take control from Okta point of view. If you are still having issues with the deployment of Box and settings, please feel free to open a support ticket to be able to view the configuration that you have setup.
Best regards,
Vlad Huma