 I'm Artur Sivon, nickname bliss. I worked also almost since the start of the project together with Frank and many of the others here. And yeah, so one of my tasks, or yeah, in the next cloud is that I also maintain the elder backend. And so I was also asked to do this talk here about the user management in next cloud. We're going to cover a couple of topics here. We're going to start slowly first with the local user and group backend and then about the known LDAP one. It's going to be a bit more exciting maybe with Assemble, which got a new open source implementation. And then comes a very new and very shiny stuff with a two-factor device or passwords and the session invalidation of the users. Yes, the local user and group against. So they probably do not make much sense for organizations who already have an existing user-based directory and just want to plug into their next cloud. However, this is a very original kind of part and built in within next cloud. And it also kind of was the first prototype or template of how users and groups work with next cloud. So yes, back then, years ago, when it was implemented, it had also a very minimal approach. It was basically one example, just a username or user ID. And it was simply hard after the user creation. And only afterwards, we implemented that there can be a so-called display name. So you can change what appears to other users that you share with, for example. And this also was a necessity, for instance, for what we're going to talk about later. Yes, where it might make sense actually in some use cases while we're using the provisioning API. So this lets you allow to write scripts for you that are going to create or manage users automatically or with some other tools that you want to have. Yes, so this is the start. And let's go to the LLab back. And one question first. Who of you is familiar with LLab and LLab in next cloud? OK, so that's already, yes, it's a good share, 50-50, OK. Pardon? Pardon? OK, so LLab is a standard, it stands for lightweight directory access protocol, I think. And yeah, use basically is kind of to have directory for your users and maybe other resources like groups or computers or others. And that you can kind of manage on a central point that you don't have every service to use its own user management or you have different passwords everywhere and that's going to be a hell of management, especially if you want to kind of add users or remove users or modify one. So and LLab is a protocol and there are different implementations, open LLab as a reference one and kind of the most popular open source implementation and Active Directory implemented as well from Microsoft. Also, this is widely used in, yes, especially in enterprise environments. So the LLab back end, as we wrote it, is designed and intended to work agnostic of a server implementation. So we don't do any fingerprinting and try to detect what is actually running there and kind of work after this because it probably also won't work since LLab is also very customizable with your own, yes, structures, object classes. At the end of the course, what is the ability to do that? So performance or staging or something like that? Or does it just matter how you manage and modify it in there at times? Well, for performance-wise, it cannot compete, I think, with the local implementation because it's just wired and usually you have the database very close. So then it depends how much you need to talk to an LLab server and, yeah, where your network is placed and what architecture you have behind there. Yeah, but in fact, I think it's not really feelable. So we do a lot of caching there as much as possible. What always goes live against LLab is they look in because we are going to do the bind to verify that the user is allowed to access this, obviously. And afterwards, we try to cache as much as possible by default for 10 minutes. And only if that runs out, we kind of fetch new information. Typically, what often runs against LLab live is the searches in the user in the shared dialogue because we also have one feature there that you can define the search attributes. So you can look in specifically for the surname and the last name or email address as well and other attributes that just specify there. And this will cache as well. But if there's a new search, usually that would go live. It's usually it works smoothly. There would be one drawback. If you limit the sharing to share within the own groups because then there are several extra checks. And with many groups, this can take them some time. But yes, just for users, it's probably slower than local one, but not really feelable. Back to open LLab in Active Directory. So these are the most popular and most used LLab servers. What comes then probably is also a 389 directory service. And as far as I know, or last time checked, it also works there. And in the code, you also have some other ways or some parts to support other servers. So we accept patches or requests to support in other way or other server implementation because sometimes there is really something vendor-specific. And we're always going to try to find the capabilities of the server and work with that. What is new in Next Cloud 10 is an adapt provider that was contributed by Lucy. So her use case was that she wanted to have an application that can also write to LLab because we only have the original access. But she wanted to be able from the user management page also to create users in the LLab server because we wanted the backend is already pretty big code-wise and we didn't want to add this actually. So to have her own app being able to do this, she was writing an LLab provider that gives you a connection to the LLab server and some other convenience functions so that you can start your own communications and implement this great user interface routines that you would need for such an app. So that the LLab backend also does, of course, it supports users in groups. And yeah, we have some ways where you can configure it. So you can use LLab filters and different bases for users in groups to gather a search base as little as possible to be able to search the LLab tree as fast as possible if necessary. One thing that also does is that it detects a number of support on the server, which in Active Directory is built in, for instance, but in Open LLab, you need to enable it. And they have also more control on where actually it's enabled, so that's a bit tricky there. But compared to the other traditional or more standard ways to announce group memberships in LLab, this is, yes, way faster. So if you run the LLab backend against your LLab server, ideally, you turn on the member of overlay in Open LLab if you use that. And this will give you also some benefit. What Sadlus is also working on is a password reset and a policy feature, basically, also to allow a user to change his password if the LLab server says you need to change it now because of policy restrictions, for instance, or because the password was just forgotten, I believe. Also, everybody new here who has never seen the code configuration interface is basically our wizard kind of. You have this first server tab that is open here. You kind of just give the very basic details there, like the host name and the port. They use the binding on password and the base. And then when this is done, you will get already a green light, I believe, definitely you can continue to the other tabs and configure some specifics for users and the ways how you look in and the groups. The very easiest approach is you just click continue, continue, continue, and then it's already done. Ideally, you do click the test buttons before. But yes, we kind of try to do this as easy as possible. Next part, or any questions so far about LLab? One on the password reset thing, that is a feature request. Please make that optional. In large environments, you usually have some other method that actually handles these kind of things, so you don't have people changing the problem. That's definitely going to be optional, so that's nothing enabled by default or so. That was also one requirement. There's a pull request, also open on GitHub. Yeah, it needs to be further reviewed or so, but this definitely is an opt-in feature. Yes. Yeah. So it's possible to use the built-in in the back end as a user manager and so on? Yes. Yeah, that's possible. Is there a check that one user that is locally is not in LLab? Yes. Yeah. Yeah, OK, good. Well, name and UID. So the UID is the LLab ID mapping tool. Yeah, so what is being done is that it's checked that there is no collision in the UID because that's how the users are identified internally. So that means if you have already an existing local user, Joe, and you have pulled someone in from LLab that also results to Joe, he will get a different UID. So in order not to clash it because what we try to prevent here is to have users with the same UID and then one would be locked out from each other or see different contents. So that's the problem. We have a full problem and the problem is I cannot even know which user has switched out because it's in the same folder. The backup is the same. Joe has the same folder with Joe. OK. One sees Joe's file and the other Joe sees Joe's file. Yeah, this is, of course, a configuration thing because probably you have set the home user folder to be created after that specific attribute. And that's why it's the same in the end. By default, if you just leave it empty, it would have the same folder name as the user ID would be. OK. So yes, next on the SAML, the SAML authentication is usually, as far as I know, mostly by universities, maybe financial institutions as well. I don't know. To kind of isolate the authentication part with the user data silo. And yes, for NextCloud 9, I believe it was already that Lukas did an open source implementation for NextCloud. And this differs to the SAML implementation of OnCloud, for instance, mostly because it's here implemented as an application layer feature. That means it's not working via the Apache ship module or Motsaml module. But it's only working on the PHP level, which allows a far, far bigger flexibility. So for instance, there's kind of no forced lockout time, but typically 50 minutes. But here, we have a full control of what we can do. So on a request, the first check whether a session is existing, if not whether a password is existing within the request. And if not this, then we go further or back to the IDP site to do the authentication. And it's tested with ADFS, Shibboleth, and them held up. And thanks, Lukas, for doing this. Pretty new thing is a two-factor authentication that was implemented by Christoph Worst. Also, I think based on proof of concept of Lukas, I think I'd read it anyway. And this allows you to have, yes, a second factor when you log into your next cloud. What is implemented now is a time-based one-time password, may also known under the term of Google Authenticator, I believe, and then SMS gateway. So basically, if you enable it for your user, you look in and then you're going to be asked for the second token after your normal password. This only works in the web UI for clients like the sync client or your mobile clients, even other third-party clients. Device-specific passwords will be enforced when this feature is enabled because we don't have the control of all the different clients yet or can't have the control of all the different clients. And because of this, we have the device-specific or app-specific passwords in that case. Yes, when you... Do you provide SMS gateway because I found it pretty challenging for me without having physical hardware or SMS gateway? I believe, as far as I looked into that one, it's using one existing gateway. So it's kind of an adapter to it. OK, so you have a library also? Yeah. Yeah. So basically, something to do with that, you know, this one, it's in the middle of the way and you use it externally. OK. So after this app is enabled, an example of the time as passwords, you can go to your personal user settings and then there is going to be this point and you can just enable a TOTP. And then you will have... You cannot just photograph this QR code or use a secret there and, yes, provide it to your TOTP app on your smartphone, for instance. And then after looking in, providing the normal passwords you have this input field where you need to insert this code that is valid for a couple of seconds. Maybe. I think there's no this mechanism that's not... Yeah. No, there's mechanism. As far as I know, this is not bound to Google. So that's just... I mean, Google Authenticator, I think that's just an example. Correct me if I'm wrong, Lukas, but it's an open standard, yes. Yeah, all the source apps, but that's basically the one that 90% of the people use. So in the user interface it shows Google Authenticator because if you say I'm using RFC, whatever, probably to define, everybody will be bought, right? If you say something like use, probably to define, to be an educator, to work out. But also, if you recommend one, which is open source, there's one or better, but you can ask it strictly, but as I'm used to it, probably. Another question is, what kind of app do you use, what's the latest one? There are... Gustav is... I think on the report you've written two apps. Which were they? I think the one that's named OTP Authenticator is the one that's used to define right, available on Android. Yeah. And yes, I have a Google-free phone and there's also an OTP app connected for this, so you're really not bound to Google. And in this field, we also have some more improvements. And in Scout 11, I think mostly they are even done on something user-experience-based and the other things. First, the generation of backup codes. In case you lose your smartphone, you still kind of want to be able to get back into your account, then you need to have these backup codes. And the other nice thing is you have universal two-factor support, which allows also logging in with hybrid tokens. Like, for instance, this Ubiqui. It's a USB dongle, you plug it in and press a button on it and it just copies a token to your clipboard and you just can verify by having this token that, yes, you're the person who's allowed to log in. Device passwords are already mentioned and this is also new. It's also user-specific. You also find it on the personal user settings. And basically you can define a token for every other application you use that connects to the next cloud or for every device that you use that connects to the next cloud. So you can feed your desktop clients, your mobile clients and any other calendars, et cetera, with such passwords that you can create on the personal user settings. The administrator can enable that they are being enforced. Otherwise, optionally, you can use normal password or even the token that's generated here. The advantage is that if you lose your mobile phone or tablet or whatever, you can just delete the password and it's not able to connect anymore. Similar to this, well, similar, but there's a session invalidation. So you, as a user, you will also, you are able to see a list of active sessions and your personal settings and then you see which browser's logged in, what is the current session, and you also have the chance to delete the session that, for instance, this browser here is not allowed to access your account anymore on what you need to re-lock in. And also, this is helpful with devices, or lost or in mistrust or so. With this, you cannot exclude any user agents, per se, but I think this is possible on the server side if you just kind of use... Yeah, okay. Either if you have something like Bento Fail or you use the File Firewall, which is a different functionality that you can prevent different specific browsers or user agents to access your next cloud. Yeah, and what I would like also to know from you whether you have what expectations or wishes are for you, what you would like to see in the future next cloud. So you are using the built-in... Okay. May I ask you why? Is there a way for you, or is it a possibility to migrate your users to an adopt directory? Okay. Is there an identity provider, perhaps, like a repo or is that something you plan or is it already not in line? Did you look at it? Well, we looked into it, but at the moment there aren't any links. Obviously, it's already... Okay, always. Great. The question was whether the next cloud could get the ability to act as an identity provider, like OAuth, for instance, and the answer of Lukas was that there are kind of no big plans. Someone looked into it, maybe, but currently there's no one working, but yes, full requests are welcome. The problem with OAuth is that it's designed with a central server, a pre-defined server website with this endpoint is the next cloud with the Google or the Twitter. And when it disappears, it's like the next cloud is really working nicely with the system. It's more open ID, it's closer, but open ID is no longer used to the function. In the sense you're going to install an instant visual central server. Yes, but if an app provider needs to like specify which open ID, OAuth endpoint you can use, so Google and Twitter is easy because you just have Google and Twitter, but for the next cloud, what URL is it? It's possible. It's possible, but it's not designed for the next cloud. So you want to use a next cloud as an LDAP server? Cool, then thank you very much. I'm the whole time of the event if you have any other questions earlier later. Thank you.