TLS client certificate support

[SamuAlfageme]

Currently, the only thing keeping me from using SSLVerifyClient require on my private ownCloud instance for "enhanced security" is the limited mobile clients support.

This was a long-requested desktop client feature that got in (not that long ago) our 2.3 version: owncloud/client#69. There's a screenshot of how the dialog prompted on handshake looks on owncloud/client#6128 (comment)

I'm not sure if this could be done in a "sandboxed" iOS application nowadays - i.e. provide access to the certificate living on the device keychain only to the ownCloud app - and additionally request its password. Feel free to close if there are technical limitations for this.

(FR coming from owncloud/ios-legacy#222)

[felix-schwarz]

From the SDK perspective, storing client certificates inside the app's own keychain and using them for authentication should be pretty straightforward to implement.

But how would you import / get the certificate into the app? @SamuAlfageme

[binlab]

TLS client certificate is a powerful feature to improve security and add an additional factor to it!

[b00tsy]

Via mdm it is not possible to distribute certificates, because they end up in the apple-only keychain (accessible via safari, mail).

So client certificate distribution would be required to be implemented by the app using the sdk, eg. via a custom app enrollment process with a custom server...

[michaelstingl]

Via mdm it is not possible to distribute certificates, because they end up in the apple-only keychain (accessible via safari, mail).

Thanks for the detailed feedback!

In case OAuth 2.0 or OpenID Connect (OIDC) is used for login, the app opens a web view (ASWebAuthenticationSession), which should have the MDM-system-certificate to authenticate on the ownCloud server or the IdP. Later, app communication would be done with OAuth or OIDC tokens.

@b00tsy Could you elaborate on the ways, how would you get the certificate in the app? Link? Best practices? (home-user scenarios and/or enterprise scenarios)

[b00tsy]

Ok yes if using the client certificate just for the log in handled via a webview it should be possible to use a certificate that is distributed via MDM (or sent via email or downloaded from a trusted source). Possible both for a root certificate and client certificates. Via MDM / Apple Configurator: Create a configuration profile in Apple Configurator with a client certificate and install it via MDM or apple configurator (or create the profile within the mdm). If the authentication server is configured properly it will request a specific certificate, which the wkwebview probably presents without any required user interaction (never really tested that). Via email / download: Just send the certificate via email or download it from a trusted source on an iOS device. That requires additional manual intervention in the settings app (as of iOS 13, that is definitively true for root certificates, probably also for client certificates): https://support.apple.com/en-us/HT204477 <https://support.apple.com/en-us/HT204477> If the client certificate should be used with every request that would of course be of no help, then a customized enrollment process would be required...

…

On 6. May 2020, at 20:06, Michael Stingl ***@***.***> wrote: Via mdm it is not possible to distribute certificates, because they end up in the apple-only keychain (accessible via safari, mail). Thanks for the detailed feedback! In case OAuth 2.0 or OpenID Connect (OIDC) is used for login, the app opens a web view (ASWebAuthenticationSession <https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession>), which should have the MDM-system-certificate to authenticate on the ownCloud server or the IdP. Later, app communication would be done with OAuth or OIDC tokens. @b00tsy <https://github.com/b00tsy> Could you elaborate on the ways, how would you get the certificate in the app? Link? Best practices? (home-user scenarios and/or enterprise scenarios) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACCYSBE4WWZ7G7YTPLXWJ3RQGRJ3ANCNFSM4EYN2QMQ>.