MDM / Branding / Customization Options

[felix-schwarz]

This issue is a EPIC. It includes sub-issues:

• [MDM] Create a simple MDM/AppConfig/specfile.xml #236 Create a simple MDM/AppConfig/specfile.xml

---

Looking at how the previous client implements OAuth2, I stumbled upon https://github.com/owncloud/ios/blob/3f9580db31287d4306365bb7ab756e7b5457894e/Owncloud%20iOs%20Client/Branding/Customization.h and found a long list of parameters that mostly touch on the App, but also areas covered by the new SDK in a few cases.

Questions:

• Which of the options there should also be covered by the new app?
• Which of these options should also be controllable via MDM solutions?
• Should branding be possible via MDM solutions, or continue to require custom builds?

[jesmrec]

Customization options are currently offered to customers, all of the based in the UI apparency and some necessary set-ups regarding server configuration. We can split them in different sections to check if all of them are going to be available (not forgetting that all of them are including in the branding app, and all changes we perform in that way will carry changes in branding app).

For example, regarding authentication feature, we need (at least):

• Define URL
• Define SAML or not (only in case we will keep this option)
• OAuth2 available. If it is, both endpoints (authorization and token), redirect_url, client_id and client_secret. Currently the last two are hardcoded in branding app.
• Multiaccount available

and all options to customize the look of the view, taking in account the previous options, like (in case of authentication):

• Show or hid the URL
• Show or not the option to add more accounts
• Main icon of the app
• Background colors
• Buttons' colors
• Font colors
• ...

The best scenario here would be adapt the customization options to the existing ones if posiible, so all branding users will use the same options and minimizing changes in branding side.

The customization within an MDM depends on the MDM itself. The "favourite" MDM is Mobile Iron (any other like AirWatch also...). Integrating MI SDK in the SDK is any option to take in account, getting rid of wrapping. What do you think?

[michaelstingl]

appconfig.org seems to be the standard for best support across nearly all MDM vendors.

For deeper integration we should be ready to integrate vendor specific SDK's like the one from MobileIron.

[michaelstingl]

Lessons learned: Avoid transparency of branding colors. Brand managers don't like their colors mixed up with other background colors or graphics.

[felix-schwarz]

More customizations:

• provide static URL
• option to show that URL (non-editable) or not show it at all
• migrations
  • type: update to new server URL (by supplying old and new URLs)
  • type: passcode requirements (by supplying old and new policy)

From @michaelstingl:

• Enforce Passcode
• Branding/MDM Option to add delay
• Option for longer Passcode
• Use Touch/Face instead
• Migrations? No PC ==> enforced PC OR 4-digit PC to 6-digit PC OR enforce PC change from time to time
• Passcode and Files app???

[jesmrec]

option to show that URL (non-editable) or not show it at all

In this case, URL is hardcoded and hidden:

• Which is the first view to show to the user? ask for credentials / OAuth2 WebView?
• Should certificate details be shown in case of secured server by CA? here, the user is able to ckeck the URL, so hiding it as brandable option maybe makes no sense. Showing only in case of non-secure is an option.

[michaelstingl]

@jesmrec MDM / Branding / Customization is low priority. As long it has the technical foundation to add it later. Maybe sketch different options in Figma to get an idea about the flow?

[jesmrec]

@pablocarmu can upload here some examples about we discussed before. In any case, i think that custiomize options or not can affect directly the app design.

[felix-schwarz]

For "hard-coded URLs", this slightly altered approach should work for all authentication methods:

1. First screen just shows

• the bookmark "Name" field
• "Continue" button.

When the user presses "Continue", the app uses the SDK to determine available authentication methods (via prepareForSetupWithOptions:):

• if any issues were found at a level above Informal, present the issues to the user. I'm aware issues at a level higher than informal may occur in legitimate setups, but suppressing these should always be an opt-in option (ideally, via a description of issues that should be ignored, not a blanket "do not show issues"), that we'd need to create as well.

• proceed with step 2 if no issues at a level above Informal were found or the user approved the issues.

2a) For OAuth2:

• call -[OCConnection generateAuthenticationDataWithMethod:..] to show the OAuth2 browser interface.
• on return, inform the user about any returned error. If no error occured, create bookmark when it returns without errors and drop back to the server list

2b) For Basic Auth:

• show a reduced step 2 Add/Edit Server interface consisting just of bookmark "Name", Username/Password and the "Connect" buttton.
• if the "Connect" button is pressed, call -[OCConnection generateAuthenticationDataWithMethod:..] to create the bookmark and check the credentials
• on return, inform the user about any returned error. If no error occured, create bookmark when it returns without errors and drop back to the server list

3. In the server list: we currently show the URL there. If the URL should not be displayed, this should be configurable with another option.

--

For editing, screens would be the same as without hardcoded URL - with just the URL field missing.

--

P.S.: Assuming "hard-coded URLs" are used to limit use of the app to a certain service and typically combined with other branding options, I sense an opportunity here to take advantage of the reduced complexity to offer a different, "more branded" user experience for the server list and add/edit steps in the future.