You have a big question.
I'm very happy to hear that.
I'm very happy.
Okay, so yeah, we're ready for the next talk.
Yeah, please, could you?
Yes, please.
It's all set up.
Yeah, yeah.
Okay.
So yeah, we have a list from the next talk, the next says picker.
Is what's it wrong with?
And he told me the talk about, uh,
very interesting topic and very popular topic.
So we're in high-end, uh, sushi.
Okay.
Thank you.
I'd like to start us.
I'd like to start this with our daily mentor from many of us.
Can you hear me back there?
No, no, no.
More or less.
And there.
Better.
Okay.
This is more.
I will try to keep this dance.
Please raise your hand if you cannot hear me.
I want everybody to hear.
And let's see how this goes now.
Welcome.
This is the sushi ID project description of pre-show case.
We are here to show how sushi has tackled their IAM landscape.
The first thing it's important to show how did we get here.
So let's go through a little bit of the story of sushi.
So sushi was founded in 1992 in Germany.
It was one of the first companies to go market for Linux enterprise.
So sushi was acquired by Nobel in 2003.
Then Nobel was acquired by attachment group in 2011.
Then attachment group was submerged.
Well, was acquired by micro focus in 2014.
And then in 2019 sushi became independent.
You see the pattern here.
After 2003.
Everybody here, long enough in the organization that has gone through mergers,
can definitely spot it.
It never ends well.
But who are you?
You might ask.
Our dear friend here presented me earlier.
But I can elaborate a little bit more.
I'm Jose.
I'm a full stock engineer in sushi.
I've been working in sushi six to seven years.
Five years in the customer center.
And one year in the platform engineering team.
And with all of this baggage in my back.
I can confidently say that I have no idea what I'm doing.
I just sit down and computer.
I type things and they work and sometimes I don't.
So this is what it is.
I want to bring up a small disclaimer in this talk.
We here in this talk are not wanting to sell you anything.
We are going to talk about how we got to our IAM nightmare.
And what steps are we going to take to make it better?
We will mention products.
We will mention things that are necessary for the plot.
But in no way, shape or form, we're selling anything here.
We do work for sushi.
But that doesn't mean that I'm here to market sushi.
With that out of the way, let's go back to original part.
So how do we got here?
A small summary in case you missed it.
So we were found in a 92 chain of acquisitions.
Now we're independent.
This of course brought the classic.
So every time there is a merger, two companies working different ways.
One of the ways will win.
It's always like that.
They can never be fully integrated because that will be two different govern.
And models.
So we have now multiple possible providers.
Because every merge, every movement requires new system, new platforms.
We have multiple L-dapses because we were used to work like this in 1987.
We were used to work like this in 1997.
We were used to work like this in 2007 and so on and so forth.
We also have multiple add-ons and bridges because those old systems.
We're working really nice.
We'll define for the technology at the moment.
But we have new standards like open-outs, open ID and so on.
But we cannot just recycle the old systems.
So we have to bring new pieces of code that actually make the old pieces of software work with new protocols.
That also means maintenance burden.
We also have things like active directory because we cannot get the fact that windows is also used in organizations.
So that is also a piece of maintain.
We have radius of servers because we like to connect things together as well.
The more the merrier, right?
So at the end of the day, everybody is following or is feeling like this.
So you know who you are.
You know where to go to, but it's way too many identities, way too many things.
So why are we doing this?
As I have clearly stated, I think our authentication systems are not fully standardized.
Login into a service may require navigating an nightmare of just services around.
And sometimes manual interaction depending on the case.
At the time of writing or at the time of presenting this,
every employee needs at least two identities.
So we have a sus provider product there where we can authenticate and do a part of our work.
And we have also held up and all the protocols where we have another identity too.
Also work.
I think with this, many people can also feel a bit identified when you work in a bit company
that the unusual happens.
This of course comes with a problem on security and compliance concerns.
We have multiple IIM services around and they bring problems when you try to govern them.
Because everybody has their own system.
There is an inconsistent in my fame implementation because the system does it all the way.
And it's not so easy to steer them into proper ways or into the single way.
And there's not standard ISOF identity because company A used to use active directory.
And that's the source of truth.
Company B uses LDAP in its own way.
And it cannot properly merge with active directory because there is an encoding here that is not available there.
Or it's a specific software feature that is not here but that is there.
That also means on the administration side.
We need multiple tools to just attend a single request.
And there is many integrations to take care for before actually attending one of the requests.
And with this I think I will show a little bit of how a Susan Playee or a Susan partner works in a daily day basis with some of the systems that Susan provides for them.
So let's start with the first login.
So you go to JIRA because you are a partner in Susan.
You want to keep in touch with the properties of your software or your software request.
You're prompted to authentication.
You say, okay, you send him a password or good.
And you're going to go to Confluence and you have to authenticate again.
He's an MN password and you say, okay, it's fine.
Now you go to the build service in case people here work with us or products that build services backbone for this.
It loads, it's all beautiful, nice.
You click on login and authenticate.
Then you say, okay, I will check my boxzilla box.
You open the boxzilla, you realize it's an important box that you have a relationship with us.
You need to have security for this.
So let's authenticate and login again.
You say, okay, fine.
And I am not a Susan partner.
I just bought some products from Susan.
So I'll just go to the Susan Customer Center, try to check my subscriptions and login.
But with a different prompt, doesn't look like the previous ones.
Is it okay?
I'm an employee.
I'll just go to my corporate email and authenticate.
But you get another prompt.
So at the end of the day, this is what everybody experiences.
So we want to go to Susan's products and always authenticate.
But you might ask yourself, why not move into get another SaaS product, cloud service or third party service?
And I can confidently say to you that that would not be very open source of you.
For once, we had to use the ones who complied with many regulations that would mirror relationship as possible.
The first set of regulations he will be going through is first of all GDPR, which is very important in the European Union.
There needs to be regulations as well, which tie us to have less people and to know more about the supply chain of our software and general.
And the daughter certificate, the daughter regulation as well, which also forces us to know and to keep track of our information system systems and I guess there.
But there is always a catch, right?
So with all of this, we've been talking to you, you can, I can get to the hint that the gist, sorry that we cannot use a third party into our authentication system.
But that obviously leads you to self-hosting, but self-hosting is not free, because it comes with these own issues.
So self-hosting for sure will enable you or us in this case to comply with more regulations, because you control the software is running, you take the decisions, you have the data.
But that come with a problem, because there is no such thing as a free lunch, every new solution that you bring to this table comes with new problems.
Self-hosting brings costs in all of these area, you need operations to take care of the service, you get your putty in place.
You need data centers to actually host the things, because if you use the cloud, you're breaking the first premise of self-hosting, it's not in your premises.
You need data handling practices, you need security hardening, you need personal letters taking care of these systems, you need frontline support to actually take care of the requests.
In the past, you just relay all of that to the service provider, and is there a problem? You just pay some money, and that's it.
And now you have to absorb those costs.
In our case, in particular, for Susan, we do have some of this costs already in our normal operations.
So they don't really make a botch, that doesn't mean that they are not fully free.
So for the case of data centers, we have data center personnel, we have data center operations teams, so we can rely on that.
I'm bringing this project into the mix, does not constitute much of an increase in the workload.
The same for departments with support and so on, but it does bring new costs on operations staff, data handling and security and infrastructure.
But enough, let's see some diagrams, and let's go through more or less, how did we want to build this solution and how it will be looking in the future.
So we want to put Susan ideas, the project of the name, in the center of all the products and services as Susan provides.
That way we can have a centralized place where to control all of this, and of course, as both in one of the slides, the an example of digital sovereignty.
So at first, all of our software products will be running as Susan is less as a base, as the Susan looks at the price operating system.
On top of this, we are building with logical security, less running on encrypted disks and volumes of course.
And we are also trying to achieve this fact of using confidential computing in the online computer resource, always as where it's available.
On top of this, we have two main products, as I said, this is not a sales pitch at all, it just so happens that this is what we're running.
We have the rancher prime for controlling all the containerized workloads, and we have the Susan visualization product line where we will be hosting.
This set of online products or online software packages that we will be using for our project.
So for the monitoring side platform, it uses a standout in the cloud.
We have sort manager to do certificate brokering, and on the right side of the organization is we have the databases pretty much.
So postgres, 3-9 years garage, patrolling for orchestrating postgres and hair of an ability.
And on top of all of this infrastructure is where our integrations come.
So we have a set of software products that we will be integrating and building from scratch.
I think they are, well, I don't think I made this slide, so I know all of them are intentionally right from left to right to be the ones that we are creating.
The last slide is the one that we are integrating from us, so we have idea merge.
So small solution where we are merging many identity providers into one.
We have a nature sink tool, which I think people here have been involved in the working with nature systems.
They are never easy. They're never just a single MPI endpoint, there's always a report involved.
We have the idea of my great, which is another tool for us to merge multiple identity systems.
We will learn about that later.
We have held up such a bind, which is a nice tool for interacting many LDAP servers when they don't really match about organizational units and structures.
And at the end of the day, all of this will be fronted by authentic as a front and IDP, where we will provide the UI interfaces for people to talk and interact with this service as well.
All of this is part of a bigger ecosystem that we want to build, where we don't really care much about where is on the line, but rather what we want to provide and what to connect with our community as well.
Not only the corporate side has been talking in the last 40 something slides, but also the community in the open-source community that interacts a lot with the companies.
We have many things that we are sharing across these two entities, and we want to have a foundation of components here where at the end of the day,
Susia ID and the community solution can be the empowering all of these protocols and all of these solutions.
I learned the way we did, we have done a lot.
This is only a small excerpt of everything that has been done so far in the project as this is a continuous project,
but along the way we have created a lot of open source contributions and fixes to project software, including not limited to this list,
there's many other issues and things that you will see if you stock a little bit.
But just to mention a few authentic sold-sack small step, Django Python, Django Python, LDAP, CandyDM, PortMamp UI, and GoLankLtiff.
Along the way we also birthed a couple of projects like stepdands.
This is a client certificates tool made easy.
A lot of subwoof was earlier in the diagram.
The ID emerged, which is an identity aggregator.
It's a bunch of orgs.
You can see what this is.
This project is some of them already alive.
In GitHub you can find them.
Not all of them are by just because we are still developing some parts, but surely nothing there is critical.
I think we will be releasing soon, so keep an eye on that.
With this, I open the QA session.
I think we have enough time.
We have a question there.
Of course.
Okay.
In the architecture diagram, there was a mention to Garage.
And the question is, was it always planned, or was it a side effect of Minayo?
It was the plan.
We were not considering Minayo at the moment, or we started using Minayo on the
The vehicle happened, so the decision was not made in the moment.
Just so happens, Garage was convenient.
But it wasn't the case of we started with Minayo, and then we had to switch.
And what's on your roadmap?
What do you see next?
There's some of the next.
The question is, what is in the roadmap?
What is the next stage for the project?
We're rolling out for public facing services.
Integrations of what a new project.
We know that it will take some reconfiguration for consumers to actually integrate into the new system.
For now, we are testing a couple of operational responsibilities, let's say.
But I would say the next step.
So surely we will be in starting integrating new services into it.
There was another question.
There's a question from the internet.
Yes.
How do you handle secretization?
There's a picture of what I repeated.
The question from the internet is, how do I handle secret rotation from?
It needs from pre.
How do we handle secret rotation from the stack?
It's handled by infrastructure as a code.
So secret rotation is surprisingly easy.
In the event that is needed.
I know the skeptical face.
Some of our infrastructure can be failover quite fast,
so we can rotate the secrets in failover moments.
So just read a new one with a new secret.
New service with a new secret.
Failover real quick.
We update the other one.
The question is, how can we use the authentic UI?
That is going to happen in this month.
You can start doing that.
We can, for sure, have more internal communication with
more details of our tests.
We have another question.
The idea of the merge.
The idea of merge tool?
What that is?
I don't have the slides at hands.
So I will not attempt to go back with it.
But we have many sources of authentication.
Where the user data is obligated.
But not necessarily has the same natural keys.
For example, some people in the community have their,
the keys that also are members of community,
have different user names.
For corporate policy, they have the standardized one.
But for their own life, they have their own one.
So we need a way to know who is who for our compliance requirements as well.
So some of them, we need to track and point from some other tool
because they don't know each other who is to who.
Like if you say UID, full bar, doesn't match UID,
GACOMIS.
It become an open. It's not yet open.
I cannot tell you for sure next week, but in the soonish soonish.
We have another question there.
The question is will the number?
Okay, will the user names in this process be standardized?
Corporate wise, yes, they have to be standardized.
Community wise, we don't really have a requirement for standardization
rather than following practices,
as you should not use bad words or things like that.
Not much that I could really explain about that on that,
because corporate wise, yes.
We are standardizing some of the user names, of course.
I have a question.
Please do.
Yes, that was a better or something there.
Oh, that was a joke.
Your company is founded.
The company is acquired.
The acquired of the acquired.
Right.
Problem with that is that every time you get acquired,
you get an efficient,
a new system, a new environment,
which brings a new system.
And yeah.
Can you not experience this in evidence?
What do you experience with that somewhere?
Thank you.
Any other questions?
Thanks.
Good.