WEBVTT

00:00.000 --> 00:19.040
The next poll, the next poll is from Edward about the next cloud integration wave as a

00:19.040 --> 00:28.040
same cloud and then I didn't surprise her. Let's see. Please welcome.

00:32.040 --> 00:36.040
Yeah, so yeah, I think it's also much for coming. Yeah, I'm sure you've read the title by

00:36.040 --> 00:40.040
now when you're probably curious about what this project is all about. Yeah,

00:40.040 --> 00:45.040
approximately thinking what the purpose of this app is or what you can do with it.

00:46.040 --> 00:50.040
Yeah, but first of quick introduction for those of you who don't know me, my name is Edward Lee,

00:50.040 --> 00:54.040
and I make currently a software engineer at the next cloud and I remember of the

00:54.040 --> 01:00.040
integrations and AI team. The project I'll show today is one of many projects under our

01:00.040 --> 01:05.040
team's umbrella that didn't make it easier to communicate and collaborate with external

01:05.040 --> 01:10.040
services rather than have the next cloud just exist as its own isolated environment.

01:10.040 --> 01:14.040
Yeah, so by the end of this talk, you'll know what the app can do and well,

01:14.040 --> 01:19.040
second practice. Yeah, in case you're not familiar with the cloud, I'll give a very

01:19.040 --> 01:24.040
brief introduction. The simplest way I can explain what we do is that we are the biggest

01:24.040 --> 01:30.040
resource we're able to lift big cloud, big cloud offerings, such as Google workspace,

01:30.040 --> 01:36.040
Microsoft 365, Dropbox, Slack Zoom and many others. Especially in recent years,

01:36.040 --> 01:41.040
the cloud is exploding in popularity. I'm not just home users, but also major

01:41.040 --> 01:47.040
organizations in both the public and private sectors with hundreds of thousands of

01:47.040 --> 01:52.040
next cloud server instances online serving millions of users worldwide. And those

01:52.040 --> 01:56.040
numbers only include the ones that we know about. Recently, we've been pushing forward

01:56.040 --> 02:01.040
into AI space as well with what we call our next cloud assistance to keep up with

02:01.040 --> 02:07.040
demand of future parity. But there ought to be very clear that all of these additional apps

02:07.040 --> 02:11.040
are optional by default and you can even pick and choose which specific features you

02:11.040 --> 02:16.040
want to enable or disable for your NFCO server. But the reason we have all these apps in

02:16.040 --> 02:19.040
the first place is that there is a ton of convenience in using an all of one of the cloud

02:19.040 --> 02:25.040
resources. Because it simply cannot stress enough. The value having all these apps and

02:25.040 --> 02:30.040
features integrated into one cohesive ecosystem, which makes our data super convenient and

02:30.040 --> 02:38.040
more productive, all without sacrificing data privacy or security. And the app that I'll

02:38.040 --> 02:44.040
demonstrate today is only one of the examples of this. Yeah, so the first is a little

02:44.040 --> 02:49.040
bit of background. This project first started at about a year ago when we received an

02:49.040 --> 02:53.040
interesting request from open project, which in case you haven't heard is an open source

02:54.040 --> 02:58.040
project manager software that write most proprietary alternatives such as

02:58.040 --> 03:04.040
Jira, Trello or Mende.com. We were to get there with open project for quite a while now and

03:04.040 --> 03:10.040
have developed a few apps that integrate tightly with the killer. But this time they had a new

03:10.040 --> 03:17.040
avenue that they wanted to explore further together. Basically, can we use the user credentials

03:18.040 --> 03:24.040
in the next cloud to log into open project and can we simplify the process of managing

03:24.040 --> 03:29.040
yours their accounts across those services. This makes it easier for users with

03:29.040 --> 03:34.040
any group or organization to not have to juggle multiple passwords. As long as for

03:34.040 --> 03:40.040
administrators to not have to manually create the same set of users across multiple services.

03:40.040 --> 03:44.040
And that is where this can standard comes in. Yes, so it would be very brief in the

03:44.040 --> 03:47.040
collection in case you're not aware. It is short for a system for cost-to-may

03:47.040 --> 03:51.040
idea of the management. This standard on a station in Jeff use the identity

03:51.040 --> 03:56.040
information across different external services. This standard has also been

03:56.040 --> 04:01.040
adopted by companies including Microsoft Google and Salesforce. So as there you

04:01.040 --> 04:05.040
might be able to provision that cloud users in not just open project, but also

04:05.040 --> 04:09.040
Google Workspace and Solar Services as well. But let's not get to our

04:09.040 --> 04:14.040
head of ourselves. So we've explained how it works under the hood. First, you

04:14.040 --> 04:19.040
need to designate your service as either a game client or a game server.

04:19.040 --> 04:23.040
This can play us act as the identity provider, which since their user and group

04:23.040 --> 04:28.040
records to service. For instance, in our case, the next cloud would act as the client

04:28.040 --> 04:32.040
and open project would act as the server. And once the client's server is

04:32.040 --> 04:38.040
working figured, that is that the rest is entirely automatic. With being as

04:38.040 --> 04:42.040
client app, it will continuously run back-down jobs that communicate to the

04:42.040 --> 04:47.040
servers using a standardized rest API defined by skin. The first

04:47.040 --> 04:50.040
background job will send on as cloud user and group records to the

04:50.040 --> 04:54.040
open project server and make sure that the information is up to date.

04:54.040 --> 04:58.040
And then the second job on births will only send any changes that have

04:58.040 --> 05:03.040
been shared between the core of background job in the last.

05:03.040 --> 05:07.040
Say whenever a client's identity records are updated or deleted, we send

05:07.040 --> 05:10.040
those changes via an API request to the servers that we want this

05:10.040 --> 05:12.040
income to.

05:12.040 --> 05:18.040
It may sound like a very simple task, but if you have ever managed your own cloud

05:18.040 --> 05:22.040
services with hundreds, thousands, possibly millions of users, you'll

05:22.040 --> 05:27.040
quickly realize how much time you're saving by having to limit

05:27.040 --> 05:32.040
users in one service rather than multiple. Yeah, if you're interested in

05:32.040 --> 05:35.040
worrying more about the standard itself, I left the link in through our

05:35.040 --> 05:40.040
code to the RSEs here, which you can read on your own time.

05:40.040 --> 05:43.040
Although perhaps, you might have noticed that this can standard away

05:43.040 --> 05:47.040
takes care of the identity management part for you. It does not handle

05:47.040 --> 05:50.040
access management, there's some kind of authorization provider.

05:50.040 --> 05:54.040
Yeah, that less users created in this not actually log into

05:54.040 --> 05:58.040
the project. That is handled by other open standards, such as open

05:58.040 --> 06:02.040
ID Connect or a sample. That doesn't mean you'll need a separate

06:02.040 --> 06:05.040
next cloud app. That offers one of those authorization mechanisms.

06:05.040 --> 06:09.040
But really, that is the only dependency we need in order to get a

06:09.040 --> 06:12.040
civic client connection up and running.

06:12.040 --> 06:16.040
Yeah, so let's take a look how it all works together and see an

06:16.040 --> 06:21.040
connection. For this, for this demo, we'll be doing a brief walkthrough,

06:21.040 --> 06:24.040
which is a series of screenshots of how to configure both.

06:24.040 --> 06:27.040
That's probably an open project so that they share the same identity

06:27.040 --> 06:32.040
records. Yeah, here we'll be using open ID Connect via the LIDC app

06:32.040 --> 06:35.040
as there are authorization providers in this app.

06:35.040 --> 06:39.040
And I've already set up the few local Docker containers ahead of

06:39.040 --> 06:43.040
time running this kind of open project with their own local domain names.

06:43.040 --> 06:47.040
Yeah, so the first thing we need to do is install both the

06:47.040 --> 06:50.040
OIDC app and these can plant app in the next cloud.

06:50.040 --> 06:54.040
You can find them from the app's page in the NSL server and

06:54.040 --> 06:56.040
download them directly from there under the

06:56.040 --> 06:59.040
integration category. This is what the OIDC app looks like in the

06:59.040 --> 07:01.040
app page.

07:01.040 --> 07:04.040
Anson way for this or this came up.

07:04.040 --> 07:08.040
Oh, by the way. Yeah, like most apps in the NSL ecosystem,

07:08.040 --> 07:12.040
it is licensed under the AGPL V3, which is really the only

07:12.040 --> 07:16.040
option for software such as this. Anyway,

07:16.040 --> 07:19.040
let's do a need to create a new OIDC Connect client.

07:19.040 --> 07:21.040
This will be our authorization provider.

07:21.040 --> 07:24.040
That next I'll use this for use to log into open project.

07:24.040 --> 07:26.040
In the end of the administration settings,

07:26.040 --> 07:29.040
there will be a section called open ID Connect provider,

07:29.040 --> 07:31.040
which takes us to this page.

07:31.040 --> 07:35.040
For a minimal setup, all you really need to do is enter

07:35.040 --> 07:38.040
and nickname for the client and the redirecting your i.

07:39.040 --> 07:41.040
First simplicity, we can just update your i.

07:41.040 --> 07:44.040
The mesh all pages within the open project

07:44.040 --> 07:46.040
that local domain.

07:46.040 --> 07:48.040
Well, once it's created, it will generate

07:48.040 --> 07:50.040
a client ID and any client secret value,

07:50.040 --> 07:53.040
which we will need in the next step.

07:53.040 --> 07:57.040
From here, we can now head over to our open project instance

07:57.040 --> 08:02.040
and connect our OIDC client that we just created to open project.

08:02.040 --> 08:07.040
We'll create a new custom open ID provider here,

08:08.040 --> 08:10.040
which takes us to the set of wizard.

08:10.040 --> 08:14.040
Here, there are really only a few things we need to enter here.

08:14.040 --> 08:20.040
First, a nickname for the provider, which is just as well.

08:20.040 --> 08:24.040
Second, the discovery endpoint URL, which in most cases

08:24.040 --> 08:28.040
should be set to the well-known configuration and points.

08:28.040 --> 08:31.040
And third, the client ID and client secret value,

08:31.040 --> 08:32.040
like I mentioned.

08:32.040 --> 08:36.040
And for this demo, it's fine to leave everything else by default.

08:36.040 --> 08:43.040
Of course, they can be just just depending on your specific needs.

08:43.040 --> 08:47.040
After that, we can now configure a new skin client.

08:47.040 --> 08:50.040
That is authorized to sync to open project.

08:50.040 --> 08:53.040
Here along with giving a nickname for the client,

08:53.040 --> 08:56.040
you can also choose the authentication provider in this step,

08:56.040 --> 08:59.040
which tells open project that any users added to

08:59.040 --> 09:04.040
open project from this skin client has to log in through this,

09:04.040 --> 09:07.040
through this specific authentication provider.

09:07.040 --> 09:09.040
We'll also generate a static baritokin,

09:09.040 --> 09:12.040
that the Nescao skin client will use to authenticate

09:12.040 --> 09:17.040
to open project server, in order to send a prior request.

09:17.040 --> 09:19.040
And what's your click on create?

09:19.040 --> 09:22.040
You'll be able to even copy the baritokin,

09:22.040 --> 09:25.040
which will paste into the Nescao client.

09:25.040 --> 09:28.040
So back into Nescao, we can access the skin client app

09:28.040 --> 09:33.040
from the underdustration settings under the identity measurement section.

09:33.040 --> 09:35.040
If you're a squarely can actually register,

09:35.040 --> 09:38.040
open project as a skin server.

09:38.040 --> 09:41.040
Click on the register button,

09:41.040 --> 09:45.040
opens up a short form, which only requires a few pieces of information.

09:45.040 --> 09:49.040
In the name of the server, the root URL of the skin server API,

09:49.040 --> 09:54.040
and the baritokin that we've received in the previous step.

09:54.040 --> 09:58.040
At this point, you also have the option to verify that the information is correct,

09:58.040 --> 10:00.040
and the client can actually connect to the server,

10:00.040 --> 10:04.040
but that is entirely optional.

10:04.040 --> 10:07.040
Once everything is well done, send it to form,

10:07.040 --> 10:11.040
and now we have the open project server attached to the Nescao client.

10:11.040 --> 10:15.040
And that pretty much concludes the end of the configuration procedure.

10:15.040 --> 10:18.040
Yeah, that is it in terms of user input.

10:18.040 --> 10:21.040
From there, Nescao will automatically run back on jobs,

10:21.040 --> 10:25.040
every few minutes that will send its identity records to open project,

10:25.040 --> 10:29.040
where users will be provisioned or updated accordingly.

10:29.040 --> 10:36.040
And to verify that our setup actually works,

10:36.040 --> 10:41.040
let's take a look at what actually happens to our users on both services.

10:41.040 --> 10:47.040
So here's a sample of test users that are created in this Nescao development instance.

10:47.040 --> 10:50.040
Some of them have email addresses already assigned.

10:50.040 --> 10:53.040
Some of them have a full-distant name specified this,

10:53.040 --> 10:54.040
distinct from their username.

10:54.040 --> 10:57.040
And some of them may be a number of one of more groups.

11:00.040 --> 11:02.040
Now, if we had over two open projects,

11:02.040 --> 11:07.040
this is what the list of users looks like before the initials name happens.

11:07.040 --> 11:10.040
You can see that we have just the one root user here,

11:10.040 --> 11:13.040
that is needed to manage the instance.

11:13.040 --> 11:17.040
And here's what it looks like after this thing.

11:17.040 --> 11:19.040
Since email addresses are optional in Nescao,

11:19.040 --> 11:21.040
but to be acquired in open projects,

11:21.040 --> 11:26.040
you can see that some of the users also have temporary email addresses assigned to them,

11:26.040 --> 11:28.040
if they didn't have one Nescao.

11:29.040 --> 11:32.040
As for our user groups, similar deal.

11:32.040 --> 11:37.040
Initially, your project doesn't create any groups by default.

11:37.040 --> 11:40.040
That is thinking, as you can see,

11:40.040 --> 11:45.040
these are groups in Nescao have successfully passed right over as well.

11:47.040 --> 11:53.040
Now, the last thing we need to verify is that the users created an open project

11:53.040 --> 11:57.040
can actually log in using their Nescao credentials.

11:57.040 --> 12:01.040
So, that can though log in speaking for open projects.

12:01.040 --> 12:07.040
You can see that there is an option now to sign in via our Nescao local instance.

12:09.040 --> 12:13.040
Click on that to note, we'll take us to our Nescao login page.

12:13.040 --> 12:17.040
So, now, if we log in as gandou, for example,

12:17.040 --> 12:21.040
we will be automatically redirected back to open project,

12:21.040 --> 12:23.040
logged in as gandou.

12:24.040 --> 12:29.040
You can see in their profile page that their first in last names are also pre-filled

12:29.040 --> 12:34.040
in addition to the email address, which is either taken from Nescao or automatically generated.

12:34.040 --> 12:42.040
But regardless, we can see that these users actually work in can immediately get started using both open project

12:42.040 --> 12:45.040
and Nescao in tandem with each other.

12:48.040 --> 12:51.040
That was pretty much the end of the main part of the demo.

12:51.040 --> 12:58.040
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.

12:58.040 --> 13:02.040
Mainly some things you can do to the servers you have already added.

13:02.040 --> 13:06.040
So, first in eight, it case anything goes wrong with the automatic updates.

13:06.040 --> 13:10.040
And there is the option to invoke a full-risk link manually.

13:10.040 --> 13:14.040
It basically does the same thing as the initial factor on job.

13:14.040 --> 13:19.040
This option allows you to run that operation at any time instead of just once.

13:20.040 --> 13:23.040
And then next you can add it to the connection details.

13:23.040 --> 13:27.040
I'll take the server name or change the variable token for example.

13:27.040 --> 13:33.040
Yeah. So, say if you wanted to migrate from one open project instance to another,

13:33.040 --> 13:41.040
you can keep using Nescao as the source that you've rather than the old project in a whole little bit project instance.

13:41.040 --> 13:43.040
You want to migrate from.

13:43.040 --> 13:49.040
Yeah, just change the domain name from the full server to the new server.

13:49.040 --> 13:52.040
I'll take the access token and you're good to go.

13:52.040 --> 13:56.040
And the last thing you can do is delete the server altogether.

13:56.040 --> 14:02.040
If you ever wanted to pause this thinking operation for any particular server, for example,

14:02.040 --> 14:09.040
the best way to do that would be to just delete the server and then register the server again at a later date.

14:09.040 --> 14:17.040
That way anything just that may have happened during the pause would be able to be applied to this server as well.

14:17.040 --> 14:23.040
Yeah, so that is pretty much it's I apologize if it's a little bit short.

14:23.040 --> 14:31.040
I hope you found this talking cycle as I went over why we made this app as well as I can't potentially accomplish.

14:31.040 --> 14:37.040
If you're interested in learning more, the left URL code will take you to the app store page for the skin client app,

14:37.040 --> 14:42.040
where you can find all the relevant details for the project, including the source code.

14:42.040 --> 14:52.040
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.

14:52.040 --> 15:00.040
If you'd like to contribute to the next code ecosystem and get paid while doing it, we very much invite you to apply.

15:00.040 --> 15:05.040
Also as part of our commitment to diversity, equity and inclusion.

15:05.040 --> 15:15.040
We are currently offering additional support and mentoring for anyone who identifies as part of an underrepresented minority group.

15:15.040 --> 15:28.040
Yeah, that could include anything from gender identity to sexual orientation, ethnicity, physical or mental ability, neurodiversity, etc.

15:28.040 --> 15:32.040
Yeah, so if you'd like more details, that will be available to chat.

15:32.040 --> 15:39.040
After this talk or at the let's call booth in F1, we can conduct you to one of our mentors.

15:39.040 --> 15:43.040
But yeah, anyway, that's all I have for the presentation.

15:43.040 --> 15:44.040
Thanks so much for listening.

15:44.040 --> 15:51.040
Yeah, thank you.

15:51.040 --> 15:54.040
Yeah, thank you, thank you very much.

16:14.040 --> 16:27.040
So if we have an integration for vault is your question.

16:27.040 --> 16:41.040
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.

16:41.040 --> 16:44.040
What's the status of skin service support?

16:44.040 --> 16:56.040
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.

16:56.040 --> 16:57.040
Are you very tuned?

16:57.040 --> 17:02.040
Let's call it as a skin server.

17:02.040 --> 17:12.040
I believe there is a community app that does something similar, but I'm not aware of the making status.

17:12.040 --> 17:14.040
Oh, that app?

17:14.040 --> 17:15.040
Yes.

17:15.040 --> 17:31.040
Okay, so this, yes, so we do offer a skin server app, but it might not be, it hasn't been maintained recently.

17:31.040 --> 17:38.040
So, but that is something that, but that is an option.

17:38.040 --> 18:00.040
Does that sound, does this, I mean does the skin quiet support, cousin, cousin, session durations?

18:00.040 --> 18:05.040
It depends on how I depends on the access token.

18:05.040 --> 18:10.040
You can set the validity on that.

18:10.040 --> 18:23.040
In open project, I believe the default is one year, and I'm sure if it is possible to change that.

18:23.040 --> 18:27.040
But yeah, I believe that's how it would be configured.

18:27.040 --> 18:32.040
Any other questions?

18:32.040 --> 18:37.040
Thank you.

