The next poll, the next poll is from Edward about the next cloud integration wave as a
same cloud and then I didn't surprise her. Let's see. Please welcome.
Yeah, so yeah, I think it's also much for coming. Yeah, I'm sure you've read the title by
now when you're probably curious about what this project is all about. Yeah,
approximately thinking what the purpose of this app is or what you can do with it.
Yeah, but first of quick introduction for those of you who don't know me, my name is Edward Lee,
and I make currently a software engineer at the next cloud and I remember of the
integrations and AI team. The project I'll show today is one of many projects under our
team's umbrella that didn't make it easier to communicate and collaborate with external
services rather than have the next cloud just exist as its own isolated environment.
Yeah, so by the end of this talk, you'll know what the app can do and well,
second practice. Yeah, in case you're not familiar with the cloud, I'll give a very
brief introduction. The simplest way I can explain what we do is that we are the biggest
resource we're able to lift big cloud, big cloud offerings, such as Google workspace,
Microsoft 365, Dropbox, Slack Zoom and many others. Especially in recent years,
the cloud is exploding in popularity. I'm not just home users, but also major
organizations in both the public and private sectors with hundreds of thousands of
next cloud server instances online serving millions of users worldwide. And those
numbers only include the ones that we know about. Recently, we've been pushing forward
into AI space as well with what we call our next cloud assistance to keep up with
demand of future parity. But there ought to be very clear that all of these additional apps
are optional by default and you can even pick and choose which specific features you
want to enable or disable for your NFCO server. But the reason we have all these apps in
the first place is that there is a ton of convenience in using an all of one of the cloud
resources. Because it simply cannot stress enough. The value having all these apps and
features integrated into one cohesive ecosystem, which makes our data super convenient and
more productive, all without sacrificing data privacy or security. And the app that I'll
demonstrate today is only one of the examples of this. Yeah, so the first is a little
bit of background. This project first started at about a year ago when we received an
interesting request from open project, which in case you haven't heard is an open source
project manager software that write most proprietary alternatives such as
Jira, Trello or Mende.com. We were to get there with open project for quite a while now and
have developed a few apps that integrate tightly with the killer. But this time they had a new
avenue that they wanted to explore further together. Basically, can we use the user credentials
in the next cloud to log into open project and can we simplify the process of managing
yours their accounts across those services. This makes it easier for users with
any group or organization to not have to juggle multiple passwords. As long as for
administrators to not have to manually create the same set of users across multiple services.
And that is where this can standard comes in. Yes, so it would be very brief in the
collection in case you're not aware. It is short for a system for cost-to-may
idea of the management. This standard on a station in Jeff use the identity
information across different external services. This standard has also been
adopted by companies including Microsoft Google and Salesforce. So as there you
might be able to provision that cloud users in not just open project, but also
Google Workspace and Solar Services as well. But let's not get to our
head of ourselves. So we've explained how it works under the hood. First, you
need to designate your service as either a game client or a game server.
This can play us act as the identity provider, which since their user and group
records to service. For instance, in our case, the next cloud would act as the client
and open project would act as the server. And once the client's server is
working figured, that is that the rest is entirely automatic. With being as
client app, it will continuously run back-down jobs that communicate to the
servers using a standardized rest API defined by skin. The first
background job will send on as cloud user and group records to the
open project server and make sure that the information is up to date.
And then the second job on births will only send any changes that have
been shared between the core of background job in the last.
Say whenever a client's identity records are updated or deleted, we send
those changes via an API request to the servers that we want this
income to.
It may sound like a very simple task, but if you have ever managed your own cloud
services with hundreds, thousands, possibly millions of users, you'll
quickly realize how much time you're saving by having to limit
users in one service rather than multiple. Yeah, if you're interested in
worrying more about the standard itself, I left the link in through our
code to the RSEs here, which you can read on your own time.
Although perhaps, you might have noticed that this can standard away
takes care of the identity management part for you. It does not handle
access management, there's some kind of authorization provider.
Yeah, that less users created in this not actually log into
the project. That is handled by other open standards, such as open
ID Connect or a sample. That doesn't mean you'll need a separate
next cloud app. That offers one of those authorization mechanisms.
But really, that is the only dependency we need in order to get a
civic client connection up and running.
Yeah, so let's take a look how it all works together and see an
connection. For this, for this demo, we'll be doing a brief walkthrough,
which is a series of screenshots of how to configure both.
That's probably an open project so that they share the same identity
records. Yeah, here we'll be using open ID Connect via the LIDC app
as there are authorization providers in this app.
And I've already set up the few local Docker containers ahead of
time running this kind of open project with their own local domain names.
Yeah, so the first thing we need to do is install both the
OIDC app and these can plant app in the next cloud.
You can find them from the app's page in the NSL server and
download them directly from there under the
integration category. This is what the OIDC app looks like in the
app page.
Anson way for this or this came up.
Oh, by the way. Yeah, like most apps in the NSL ecosystem,
it is licensed under the AGPL V3, which is really the only
option for software such as this. Anyway,
let's do a need to create a new OIDC Connect client.
This will be our authorization provider.
That next I'll use this for use to log into open project.
In the end of the administration settings,
there will be a section called open ID Connect provider,
which takes us to this page.
For a minimal setup, all you really need to do is enter
and nickname for the client and the redirecting your i.
First simplicity, we can just update your i.
The mesh all pages within the open project
that local domain.
Well, once it's created, it will generate
a client ID and any client secret value,
which we will need in the next step.
From here, we can now head over to our open project instance
and connect our OIDC client that we just created to open project.
We'll create a new custom open ID provider here,
which takes us to the set of wizard.
Here, there are really only a few things we need to enter here.
First, a nickname for the provider, which is just as well.
Second, the discovery endpoint URL, which in most cases
should be set to the well-known configuration and points.
And third, the client ID and client secret value,
like I mentioned.
And for this demo, it's fine to leave everything else by default.
Of course, they can be just just depending on your specific needs.
After that, we can now configure a new skin client.
That is authorized to sync to open project.
Here along with giving a nickname for the client,
you can also choose the authentication provider in this step,
which tells open project that any users added to
open project from this skin client has to log in through this,
through this specific authentication provider.
We'll also generate a static baritokin,
that the Nescao skin client will use to authenticate
to open project server, in order to send a prior request.
And what's your click on create?
You'll be able to even copy the baritokin,
which will paste into the Nescao client.
So back into Nescao, we can access the skin client app
from the underdustration settings under the identity measurement section.
If you're a squarely can actually register,
open project as a skin server.
Click on the register button,
opens up a short form, which only requires a few pieces of information.
In the name of the server, the root URL of the skin server API,
and the baritokin that we've received in the previous step.
At this point, you also have the option to verify that the information is correct,
and the client can actually connect to the server,
but that is entirely optional.
Once everything is well done, send it to form,
and now we have the open project server attached to the Nescao client.
And that pretty much concludes the end of the configuration procedure.
Yeah, that is it in terms of user input.
From there, Nescao will automatically run back on jobs,
every few minutes that will send its identity records to open project,
where users will be provisioned or updated accordingly.
And to verify that our setup actually works,
let's take a look at what actually happens to our users on both services.
So here's a sample of test users that are created in this Nescao development instance.
Some of them have email addresses already assigned.
Some of them have a full-distant name specified this,
distinct from their username.
And some of them may be a number of one of more groups.
Now, if we had over two open projects,
this is what the list of users looks like before the initials name happens.
You can see that we have just the one root user here,
that is needed to manage the instance.
And here's what it looks like after this thing.
Since email addresses are optional in Nescao,
but to be acquired in open projects,
you can see that some of the users also have temporary email addresses assigned to them,
if they didn't have one Nescao.
As for our user groups, similar deal.
Initially, your project doesn't create any groups by default.
That is thinking, as you can see,
these are groups in Nescao have successfully passed right over as well.
Now, the last thing we need to verify is that the users created an open project
can actually log in using their Nescao credentials.
So, that can though log in speaking for open projects.
You can see that there is an option now to sign in via our Nescao local instance.
Click on that to note, we'll take us to our Nescao login page.
So, now, if we log in as gandou, for example,
we will be automatically redirected back to open project,
logged in as gandou.
You can see in their profile page that their first in last names are also pre-filled
in addition to the email address, which is either taken from Nescao or automatically generated.
But regardless, we can see that these users actually work in can immediately get started using both open project
and Nescao in tandem with each other.
That was pretty much the end of the main part of the demo.
But I want to go back to the administrator side, but quickly to touch on a few extra features that we added to the app.
Mainly some things you can do to the servers you have already added.
So, first in eight, it case anything goes wrong with the automatic updates.
And there is the option to invoke a full-risk link manually.
It basically does the same thing as the initial factor on job.
This option allows you to run that operation at any time instead of just once.
And then next you can add it to the connection details.
I'll take the server name or change the variable token for example.
Yeah. So, say if you wanted to migrate from one open project instance to another,
you can keep using Nescao as the source that you've rather than the old project in a whole little bit project instance.
You want to migrate from.
Yeah, just change the domain name from the full server to the new server.
I'll take the access token and you're good to go.
And the last thing you can do is delete the server altogether.
If you ever wanted to pause this thinking operation for any particular server, for example,
the best way to do that would be to just delete the server and then register the server again at a later date.
That way anything just that may have happened during the pause would be able to be applied to this server as well.
Yeah, so that is pretty much it's I apologize if it's a little bit short.
I hope you found this talking cycle as I went over why we made this app as well as I can't potentially accomplish.
If you're interested in learning more, the left URL code will take you to the app store page for the skin client app,
where you can find all the relevant details for the project, including the source code.
And the right to your code will take you to our just page as we are looking to hire more developers and continue going in 2026.
If you'd like to contribute to the next code ecosystem and get paid while doing it, we very much invite you to apply.
Also as part of our commitment to diversity, equity and inclusion.
We are currently offering additional support and mentoring for anyone who identifies as part of an underrepresented minority group.
Yeah, that could include anything from gender identity to sexual orientation, ethnicity, physical or mental ability, neurodiversity, etc.
Yeah, so if you'd like more details, that will be available to chat.
After this talk or at the let's call booth in F1, we can conduct you to one of our mentors.
But yeah, anyway, that's all I have for the presentation.
Thanks so much for listening.
Yeah, thank you.
Yeah, thank you, thank you very much.
So if we have an integration for vault is your question.
If I am not aware of any at the moment, but that is something I could have looking to see if we can developers something similar.
What's the status of skin service support?
Because as your most recommendations already have an ID like people, for example, I have a case any for them to be using skin provision using groups into the next part.
Are you very tuned?
Let's call it as a skin server.
I believe there is a community app that does something similar, but I'm not aware of the making status.
Oh, that app?
Yes.
Okay, so this, yes, so we do offer a skin server app, but it might not be, it hasn't been maintained recently.
So, but that is something that, but that is an option.
Does that sound, does this, I mean does the skin quiet support, cousin, cousin, session durations?
It depends on how I depends on the access token.
You can set the validity on that.
In open project, I believe the default is one year, and I'm sure if it is possible to change that.
But yeah, I believe that's how it would be configured.
Any other questions?
Thank you.