![]() Disabling Two-Factor Auth for Specific UsersĪs soon as a 2FA provider is found, users are required to solve the challenge before getting access to their account. It registers a dead simple provider that is enabled for all users and whose challenge can be passed with the hard-coded password “passme”. OCA\TwoFactor_SMS\Provider\TwoFactorSMSProviderĪdditionally, it is necessary to tag the app as prelogin and authentication app, so it is loaded in an early stage: Ī very simple proof of concept provider was created as “TwoFactor Email”, which may be used as reference. This class is the main communication component between your app and the ownCloud core.Īs a second step, you register the 2FA provider in the app’s info.xml in the two-factor-providers section: First, you have to create a class that implements the OCP\Authentication\TwoFactorAuth\IProvider interface. Hence, you won’t find any second factor if you just download and install a recent development version of ownCloud.Ĭreating your own 2FA provider requires two important components. If there is at least one, access to the account will be blocked until one of the 2FA challenges was solved. After a successful login, ownCloud will check if there are apps providing 2FA support. Architecture OverviewĪs mentioned above, developers can create their own specific second factor providers. Admins are able to create and install 2FA providers they want without needing to modify the ownCloud core. By decoupling core interfaces and specific 2FA providers we keep the ownCloud core easier to maintain. Specifically, core will take care of the communication and management of second factor providers that are plugged into the system as apps. Based on Lukas Reschke’s proof of concept pull request I added internal 2FA support to ownCloud. Token-based authentication is the foundation for Two-Factor Authentication (2FA). In this case the ownCloud server will then deny authenticated requests if the password is the login password and not a device token. In case admins want to enforce token-based auth and disallow login via password (with the exception of the login page of course), we added a config option that admins can set. The ownCloud core will detect that the password is actually a token and will use it to authenticate. device-specific password) and use that as password. However, the preferred way to configure clients will now be to create a device token (a.k.a. ![]() The great news is that we are not breaking compatibility with old and third-party clients, as we still allow authentication via username and password. This means if you lose your smart phone, you no longer have to change your password to disconnect all connected browsers and devices, you can now invalidate that specific device token with a single click. This allows tracking and killing browser sessions via the personal settings page of an ownCloud user remotely. Token-based authentication finally makes it possible to connect client applications and devices without giving those your login password.Īdditionally, session tokens are created for browsers. Starting with refactoring and cleaning up of the existing auth system titled “Pluggable auth”, I added token-based authentication to the ownCloud server. Starting with ownCloud 9.1 (which will be released in July 2016) it will be possible to plug custom two-factor auth providers into the ownCloud core for enhanced account security. I have spent a couple of weeks working on a fundamental component of the ownCloud core, its authentication system.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |