Hi guys.
So now we have Francisco Tivino who will speak about the Ipatura project, which is a FIJK
connector for people.
That is awesome.
Yes, thank you Ikea.
Thank you.
Thank you very much.
Yes, my name is Francisco Tivino.
I'm a principal software engineer at Red Hat, specializing in identity management systems.
And I'm part of the Free API team.
And I'm very excited to introduce you to Ipatura, a collaboration between Free API team and SSSD teams.
And basically what you are allowed to see is a redesign of the system integration between identity
management between key clock and Free API.
And then the Alexander talk, the one before this one, it was perfect because he was explaining
all the concepts, all the, he was giving a very good overview of key clock, what are all the
features that are supported and specifically how to integrate key clock with other identity
management systems through the user federation and identity federation and all the brokering
and stuff like that.
And he was missing one integration, actually.
That's nice because he didn't spoil my presentation.
He was missing the integration with Free API, all right, through the user federation.
So, yeah, this is all about, yeah, well, this is very basic stuff that I would like to scope
well the project, right?
I just want to spend a few minutes talking about some of the background and some of the key
aspects of this project that we have been keeping in mind as we have been undergoing this work.
So as far as the background, IAM is an umbrella term.
It defines processes to assess the right assets at the right time for the right reasons, right?
Well, keeping an author right access and the control.
So some of the common products are Microsoft Active Directory.
This is for environments where Windows is dominating.
So we have also identity management, which is Free API.
So if you are familiar with it, it could be, yes, you can understand Free API like the open source version
of Active Directory, but for post-example environment.
This is Linux, right?
And, yeah, because basically it relies on the same building blocks like Microsoft Active Directory,
like LDAP, Kerberos, PKI, CA, DNS, right?
And, yeah, another one is Key Clock, okay?
It doesn't need an introduction.
It's a more scope for modern applications and services to the users in general, right?
And there are more of the solutions such as Octa and TrID where they are more oriented to cloud-based environments, right?
So when comparing these solutions, we soon discovered that one of the main differences is like number of assumptions
regarding how users and groups are controlled, okay?
So, for instance, Free API is tied to user and groups like this.
They are necessary for the applications running in a post-example environment, right?
On the other hand, Key Clock offers authentication services to modern applications
where these applications are deployed usually in the cloud environment and the identities,
they completely differ from the system level ones.
Meanwhile, AD, for instance, Active Directory relies on other identifiers like security identifiers or organizational units.
I'm not going to talk about post-example environments because the very last talk of today is all about that.
So I recommend you to watch that one.
And, yeah, the key point is that sometimes you are happy with a standalone solution with all your conflicts in place,
or that is not a useful case.
I mean, many times you will need to integrate multiple identity management solutions
so that the same user can access different operating systems as well as different cloud applications with the same set of credentials, right?
So, luckily, IIM, this umbrella term I was talking about in the first slide, defines some processes like single sign-on
and also identity and user federation where a user basically will be authenticated directly once, okay?
And then the fact of authentication is consumed by other services for a certain amount of time,
regardless how and where the application are operating, right?
So that's basically it.
And then when talking about this, this one, and this one, federation that Alessandro was talking about that,
Yaki Clock is very well known for providing these functionalities, okay?
So, yeah, the way it works is like when a user logs in,
Key Clock will look into its own internal database, right?
And if the user is not there, it will fetch or iterate over every user storage provider that is connected until it finds a match, okay?
This is basically how it works, right?
And guess what?
Key Clock already supports the integration with API, yeah?
As a backend to look up for authenticated identities and so on, right?
This is already supported. You can do that.
So, yeah, by default, well, I'm not going to spend a lot of time here because this was explained by Alessandro.
So the one on the left, the one on the left, it was the one from the previous presentation.
Yeah, includes LDAP and AD provider so you can federate with multiple LDAP servers in one Key Clock.
And, yeah, at the same time, and the one on the right is the one that I'm going to focus on,
is that Key Clock also includes SSSD plugin, right?
And it provides access to multiple identities and authentication providers from free API, right?
And also very nice features like failover and offline support as well.
So then what is the problem then?
If we support everything and we can integrate with anything?
All right, let's have a look.
So what are the problems that we are trying to solve?
So one of the main issues is, and the most important is that we are missing feature parity between those integrations.
I mean, they are really different ones.
I mean, you can integrate from a Key Clock to the user federation with LDAP,
with Rehabilitation Server with AD in a different manner because we support a lot of features there.
And at the same time, you can integrate with ADM with free API, but there is a huge limitation there.
It's that it's only a read-only interface.
So Key Clock, yes, can fetch information from SSSD, that's all.
It can write there.
So that means that if you do changes in your user database in Key Clock,
you will need to drop by the free API and do the changes as well.
So this is kind of a very limiting factor, right?
So yeah, another one is that if you want to integrate with SSSD,
you need to deploy SSSD in the same host or container where you are running Key Clock.
This is also a limiting factor, especially when talking about cloud environments and open sieve,
where you usually deploy the bots in different hosts and different machines, right?
So that's another limiting factor.
So then, yeah, we are thinking about already designed then.
We need already designed to already design this, okay?
And then in this slide I have, yeah, well, this is where the IPaTura service comes into play, okay?
And then these are kind of a list of requirements when redesigning something, yeah.
We are thinking about to support all these things at the same time.
So we need a common API for managing identities.
So the requirements are to be able to read and write.
This is the most important one also to authenticate users from any integration domain.
At the same time, now that we are redesigning everything, we are going to try to simplify the integration.
And one idea is to replace all the existing plugins by just one plugin for all of them.
So you can easily configure and then you can connect with anything.
Another one is the cloud-friendly, maintainable solution.
Yeah, we need to get rid of this limitation about deployment.
We need to get a key clock and this is in the same container.
This is kind of difficult without performance impact.
That's always there.
And ideally we shouldn't reinvent the wheel.
So we need to ideally rely on existing open source projects, okay?
So then, now this is a question for you.
How many of you know about the scheme?
You can raise your hand.
That's that kind of the whole part of the room.
That's nice.
So it stands for system for cross-domain identity management.
Okay, this is a protocol.
This protocol finds or helps with this chain of user identity data between different identity management systems.
It simplifies the provisioning, the updating of attributes,
also the provisioning of users, of accounts, and it helps with interoperability.
Okay, so it sounds like this is what we need, right?
Yeah, so the idea there is to implement a scheme server for free PA as a backend
to process all the requests coming from key clock, right?
So, yeah, the idea is to don't start something from scratch.
So based on this protocol, I think there are kind of 10 or 10 to 15 projects already implementing this protocol.
And we were paying attention to one in particular, which is Django scheme 2.
And this is why it's written in Python.
And the reason is because free PA is also using Python, especially the API.
So it's very similar.
I mean, the interconnection between this, the scheme server and free PA will be some sort of straightforward.
So, okay, let's start building it.
Let's start building a new service.
Okay, we mentioned that it must be a cloud-finally solution.
So we are targeting a container.
This is a container.
Okay, on the left we have key clock.
On the right we have free PA.
So the first thing to do to add into the container is the Django framework because there is where we have the implementation of the scheme based on an open source project.
Okay, this project in the container is already exposing some sort of endpoints.
Okay.
What is the next requirement?
It must be secure enough, you know, the Django framework implements an HTTP server, but this server is kind of for developers.
It's not, I mean, it's not protected at all.
So, okay, so we can include Apache.
It's a well-known server.
And we can enable HTTPS for production-driving environments.
So, all right, we add Apache.
We connect Apache through the WBSGI connector to Python, and this is from Django.
Okay, now we have a secure API.
Okay, what is the next thing?
Yeah, it must provide a generic API.
So, let's rely, yeah, the breach can, at the same time, I mean, the idea is to, this is a breach, right?
And then we have connected to Key Clock already, so through the user federation storage and other identity providers, brokers,
we can connect to the container.
This scheme protocol will help us to translate, and so we can make another call to free API through the API.
And this is how, basically, how we connect everything.
And it's generic because it's based on the scheme.
All right.
And then, yeah, we need, I was mentioning that, we need to read and write.
Okay, so we implement two interfaces to connect to free API.
And then, about the performance, well, deploying a container with a start service,
talking to free API, making API calls is kind of expensive.
Okay, but no problem because we can rely on SSSD because SSSD is implementing a catch.
Okay.
And then, okay, let's include SSSD in the container, right?
Let's connect through the Django, through the divorce info pipe.
And this is how we can access to the user materials, identity materials, right?
All right.
So, looks like we are almost done, but we mentioned that it must be generic enough.
So, these interfaces, the right and the right one, we can easily configure them to talk,
not only to free API, but also to any Active Directory, and through LDAP and also any
RojHDS Directory server, right?
Okay, so this is basically the idea to unify.
Okay.
And what about key clock?
Yes, that is support the scheme calls because, well, we have implemented a scheme server.
It's pushing a generic API, but key clock, well, doesn't support the scheme calls as a client, right?
So, okay, as Alessandro mentioned, there is another, well, I mentioned that there are two ways
to integrate user federation with an identity management system.
Elavanidian, the other one is SSD, but there is a third one.
The third one is that you can implement your own user data connector key clock.
So, then this is what we did, basically.
We implemented, and this is another project you have in GitHub, and it's basically a custom user federation
that is capable of acting as a scheme client, all right?
And this is what we need in key clock to connect with the server.
All right, and this is how it looks like.
You go to key clock, and then you will see all these options.
You will see parameters for connecting to the bridge.
It's basically the server URL and the username and password,
but, well, we have other authentication mechanisms, probably, but this is basically,
you specify the details about the integration domain.
You can choose between the type IPA, is free IPA, you can choose AD, but also a lab.
So, this is just for summing up, and then if we combine both projects, then we have it.
And let's say that this one, which is the server running in a container,
is basically supposing a lot of endpoints.
For instance, there is one, which is called domains, is kind of an administrative endpoint.
It's basically when key clock tries to enroll with a scheme, is sending some details,
and then a scheme is implemented on the automation to make an enrollment
with any other identity mind-saving system, right?
And then once this is done, key clock plug-in can simply make user calls
to the user federation storage to fetch for users or write and read whatever.
So, yeah, it's important to note that key clock plug-in now,
it doesn't communicate directly with the databases or with the other identity management,
it's kind of only talking to the scheme, which is a container.
So, let's go for a quick demo.
Yeah, this is, in the demo, this is what is going to happen.
Okay, basically, you will see key clock, you will see free APA,
and a container running in another host,
and we will make an HTTP post-request to the domain's application in the bridge,
and the bridge will be capable of doing all this automation,
because those are steps that they were done by the administrator in the past.
I mean, if an administrator today wants to enroll user federation to free APA,
it's going to do a lot of automation, a lot of steps there,
like file a service, the proper role with the proper privileges,
and generate key tabs, and blah, blah, blah, right?
So, this is fully automated now.
And once the other process is done, now key clock every time is looking for a user or something,
it will make a generic call to a scheme server.
So, what this whole looks like is a post to the scheme server,
which is in JSON format through the recipe,
and this service will translate that into an APA API call,
and it will make it to the domain.
Okay, so, yeah, I love the live demos,
but I have to admit that today a little bit cold,
I have a recording, and yes, I think I want to do the real demo
because I have all the infrastructure deployed in Red Hat,
and then this is everything recorded,
and I don't want to expose DNS names or internal IP addresses,
so I have a video anyway.
And so, yeah, if this works...
So, no.
Okay, let me see what is going on here.
So, very quickly, I have a quick one,
so how many minutes do we have?
Okay, then I have a three-minute video.
So, yeah, there we go.
So, yeah, the three consoles you see on the bottom,
the one on the left is key clock,
the one on the middle is the bridge,
and this one is free API.
So, this screen is key clock, we are authenticating there,
and the same in free API, all right?
Then we go to the user federation
so that now we see it was quick, that was super quick.
It's quicker than the speed of the light.
So, yeah, I wanted to show you
that there is a new user federation storage there.
Yeah, you see?
Wait.
Let's see if I can...
Yeah.
So, these are the ones that Alexander was talking about
in the previous presentation, and this is the new one, okay?
So, you will see that.
All right, let's continue.
So, yeah, key clock, free API.
So, these are the services,
because you know that the machine will configure things here automatically, okay?
So, now I'm going to show you where the container is running.
This is a different host, by the way.
It's not tight to key clock anymore.
So, that's the...
If you do podman.ps, this is the container, right?
For the demo.
It does the proper lead network mapping.
You see, it's not running HTTP.
Apache is not running the host,
so if you log into a container,
Apache is running inside the container.
There we go.
Yes, I'm piping the error log just to see that there is movement here,
but I'm not cutting the content,
because otherwise we will see a lot of IP addresses and internal stuff.
So, I'm too lazy.
I don't want to go to the key clock and type all the parameters,
so that I do a cool call, okay?
Or, well, this is with the KAdmin.
You can see all the parameters that we are configuring
for integrating with free API.
And once we execute that command,
the container is capable, you see the activity.
And now we have the user federation enrolled, okay?
And you will see a new service here,
which is this one, the bridge, okay?
It was done automatically,
so you don't need to worry about that anymore.
So, now everything is set up,
everything is configured,
so now you can manipulate users.
When we create one user, for instance,
I'm trying to file a user in key clock,
so right away after we click on create,
the user is added to the key clock database,
but it's making a call to the scheme service,
and the scheme service is redirecting the user to,
directing the user in the IP as well.
So, it appears here, okay?
Yeah, that's the user,
and yeah, you know, we can do all the administrative stuff,
like changing for instance the email,
everything is fully replicated to the free API
and the Dimachment system,
based on all these cool calls that are happening to the bridge,
so the user is there,
you can see it from the click command as well.
Yeah, the modification was currently provided.
So, I guess I'm trying to delete the user now,
and yeah, basically, it does a group of operations,
I mean create, modify, list, and delete,
yeah, the user is not there anymore,
and also when you delete the scheme federation,
it is unenrolling, okay?
So, it goes to free API and then remove the service
because it's no longer needed, okay?
So, this is also fully automated.
Okay, so, what you just saw here in this video,
is the user provisioning, okay?
We are not done yet.
Let me see, because I have a bonus.
If I can close the video now.
So, the bonus is...
Oh, now it's working.
Now it's working, okay, when I don't need it.
Okay, now, okay, this is a bonus.
This is a working progress, all right?
This is the other piece, the identity federation.
You just saw in the video, the user federation,
but this is the identity federation,
and it is all about to expose another endpoint in the bridge,
so that key clock can also make calls to the bridge,
but now, not for user provisioning,
or modifications, it's for authenticating,
and this one is for Kerberos, okay?
So, this is kind of controlling Kerberos,
and then the scheme, I mean the bridge, Ipantura,
is capable of translating that into an operation
that we've modelled, yes, this API, using a proper kit up,
and then free API will answer with the session cookie,
or it will fetch from the SSD,
or well, from the cache, and then it will respond back
the session cookie, so that the cloud application
that is running here, trying to log in into key clock,
is actually authenticating in IPA, nothing key clock, okay?
So, yes, and then, yeah, this final slide is about
potential usage, so this can be used for synchronization
of identities across different providers, as you can see.
Also, we can use it to migrate all the users,
because the beauty of the scheme is that you can do
mapping of the attributes, so you can translate anything
you have in any cloud application into something
that is more powerful, like free API,
and then with UIDs and UIDs that are generated automatically,
I mean, it's amazing, and the good point as well
about potential usage is that key clock,
if we merge this in key clock, there will be a user federation
that will be capable of connecting to any scheme server,
it doesn't need to be this one.
So now key clock can talk to a scheme as a client, right?
And this service, as a scheme server that we implemented
in IPA as a container, can be also used to connect
with other clients, it doesn't need to be necessarily key clock,
we can connect to Azure or Azure AD or any other,
for instance, I don't know, anyone that is supporting the protocol.
So, yeah.
So, yeah, that was it.
I think we have time for questions, right?
More or less?
One, two minutes?
Okay.
Yes, please.
You spoke about intervention with AD,
I want some idea of the client side, you would have windbind,
would you be able to replace SSD with windbind
and still use this solution?
So the question is if we can replace windbind...
Yeah, from SSD with this solution with...
So, not yet, the answer is not yet,
but yeah, I think we can look into it and potentially,
potentially, yeah, it could be done.
If we decide to prioritize that use case over the others,
why not?
Yeah, but not yet.
What's the not yet part of it?
Say again, please.
Will it happen?
Will it happen?
Will it happen?
That's a good question because we haven't done any release.
This is an upstream project.
We have two upstream projects.
So, yeah, our intention is to make this to happen.
This will help simplify a lot the key clock user
integration with identity management systems
and also it's very convenient now to get a deployment
independent from the host so that you can get
a container, this is kind of on the towards the cloud,
cloud-based applications.
So, yeah.
So, about our plans, our plan, I mean,
the key clock plugin is more or less completed.
Now we are thinking about sending to key clock
so that it will be emerging upstream first
and then it will appear scheme client there.
And the service, as soon as we finalize the
Kerberos authentication redirection,
then I guess we will be in good shape to make a first release
in upstream, okay, and later on,
if once we prioritize a lot of aspects,
then, yeah, potentially yes, it will replace or,
especially will replace the SSD connector
we have in key clock, that for sure, okay.
Okay.
Thank you.