Thank you for coming to my talk, so it's about SD and identity providers, how they can work
together, so this is also work and progress, so I will show you later there are some
repository where you can look at the code and get some packages, but it's not committed
to the SD upstream, so if you have ideas, suggestions, we are well-wracked on if you will
share with us and so we can improve the experience with SD and the integration of IDPs.
My name is Sumipos, as I already mentioned, I'm a software engineer at Red Hat, and I'm
presenting for SD, I'm a member of SD team, but I'm also currently the maintainer of
RealmeB and ADCLA utilities to join Active Directory or free IPA, and maybe during the talk,
we will see that even RealmeB might play a role here in the future as well with the integration of the IDPs.
So, I will start telling you why we are doing this and how we are doing this and then
then I will try to use some demo, so this demo will be a life demo, so I will see how
strongly I should myself and to the foot. So, where we are coming from, I will talk about
SD as SD is around since more than a decade, and it's basically about centralized identity
management, so we are using sources like classical LDAP servers, maybe with a cover server,
or the more modern integrated variants like Active Directory and free IPA, where we get the user
and group information and also use mostly the cover protocol but others as well to authenticate the
users against those centralized identity management platforms. And so SD is on one hand
getting the information from those servers, and on the other hand, is sending the information
back to the local system. So, Leonard was already talking about Tom and NSS, and that is H, for example.
So, what is the doing is taking the information from the identity provider, like the user name,
and put it into the NSS record that is in the user name, and when the server provides
a UID and a GID, it will also put it into the NSS record, so that the system knows what the
UID and the primary group ID is corresponding to the name of the user, and then there are
the remaining physics attributes like the home directory and the user shell. But as Leonard also
mentioned before, there are many, many other information about the user, for example, the
SSH keys of the user, and SD also can, with the same mechanism as system D and the
walling interface, present the users SSH keys to the SSH team, and SD can also do this with
the host keys, and then there are other items where we can get information from the
servers, like as UD rules, you can read from the server, and make it available to the
SSH programs, so you can manage your SSH, and we also make this information available for the
user, for example via DBS, as Leonard also mentioned originally system DBS also have a
using DBS, and at the time we started to provide the information via DBS, this was
kind of state of the art, and so we used DBS to provide in which user information, so as
mentioned by Leonard as well, the physics and as interface is quite small, where we do not
can put many information, it's basically the information the systems need to log in, but
nothing else, and so we use the DBS interface to enrich this, and I guess we will also
follow Leonard's suggestions and implement the volume interface sooner or later so that
we nicely work together in this respect itself, but I'm told that not every system is using
system D, so I guess we have to maintain all the interfaces we currently have on our own as well.
With respect to the integration of the local public system, LDAP has this RFC 23 or
7 or RFC 23 or 7D steamer, which defines all the attributes we need for a public
system, and Kerberos is something which is kind of quite old coming from the mid 80s,
is designed platform independent, but has a long tradition of the public units environment,
so that also these platform independence is handled quite well with the public environment,
so both sources we are so far using intensively for decentralized user management are very
well integrated and well known, but the IDPs are kind of new for the public environment,
and I will later show you where we are kind of coming into trouble or what kind of obstacles
we have to walk around. From the system side, I will just pick two of them because they
are their relationship, in my opinion, it's important, there's on one hand time for authentication
to public Google authentication modules, on the other hand, the NSS, the name service switch
by GILIPC, and they are independent by design, so you cannot look up the user, which is not authenticated,
and you in theory can authenticate the user, but at the point of authentication not known to the system,
this contradicts each other, and typically you have to kind of satisfy both, so for example,
when you are login with SSH, SSH does a get PW num call before doing any authentication,
so the user must know to the system before authentication, and this is something which makes this integration
with the IDPs a bit more complicated, because if you might have seen in some of the earlier talks,
when you are doing already see authentication, in the end of the authentication you get user information,
back as part of the authentication, but this is polite for us, we needed before.
So this is some of the boundary conditions we have to consider here, so why we want to do this at all?
Because for example, there is already an integration with free IPI and IDPs, so you can use free IPI to authenticate against an external IDP,
and use all the kind of fancy authentication methods your IDP provides, and using IPI has, in my opinion, also many benefits,
when you have a large environment, so when you have the knowledge and the manpower to handle a bit complex environment where you
not only have your IDP, but also some other services like IPA, but even many small environments nowadays depend on the IDPs,
because everything related to web services and authentication is basically running on or to IDC IDPs.
And so this is, these IDPs are kind of requirement, even for small environments, and so as is the, we are trying to fill the gap for those small environments,
so that you do not have to add extra complexity by adding new services, new protocols,
but mainly have your IDP or run your IDP on your own, and then you can consume all the data you already have, like users, like groups,
the relationships, group memberships, and so on, without any extra services which introduce complexity and maybe some other issues.
So, and this is what we want to provide in future, so that as a D can talk with all the different kind of identity providers, like Android,
like T-Clog, Google, you name it, Opera, Amazon, GitHub, was already an example, also in a previous talk, so this is something,
or this is our goal, which we want to provide in future, and how we want to get there, or we want to follow, of course, the ODAC or IDC or to standards,
for the authentication and authorization, because this is what those IDPs provide, and this is also something we can build upon,
because those are more or less pretty good standardized.
A problem here, or what we have to respect as well, is that everything here is web browser based, so since it's coming from the web services and web service authentication,
there has to be a web server involved, and you will ask yourself, yeah, when I do SSH, whereas my web server, I hope we will show you how it works in a demo later.
As I already mentioned, all IDC provides your user identity tokens, but it is nice to have them, and we can take some information out of them,
but typically they are coming to light, because most of the services used to log in, like SSH, bin log in, or whatever, do these get PWM a try first, if the user is known to the system before authenticating the users.
The only exception I know is TDM, with TDM, we can just type in the name, and then TDM already immediately start spamming without checking if the user exists or not, but yeah, this is so far the only example or counterexample I know.
Then, what is also a bit of a problem is that although authentication is very much a nicely standardized, looking up users and groups without the authentication part, as I mentioned we have to do this, there is currently no standard at all, so basically each provider has its own API for this,
luckily more or less all of them are at least the kind of common ground, and most of them also have kind of similar ideas about how to look up the user groups, so we can basically group this into some kind of requests against the IDP to look up those users groups and the relationships.
Another obstacle is that since IDP is so far we are not used for projects integration or log in into those systems, there are typically no projects attributes claims or whatever we can kind of use to generate a UID or log in shell or a home directory, so we have to kind of find ways to run this as well.
And yeah, finally to get this information from an IDP and which is not part of the authentication of the user itself, we also need dedicated credentials to request a user and the user attributes of the memberships of the user from the IDP.
How we are doing this, to get the information from the IDP we have to create some kind of generic object and in the IDP language this would be a client, so like typically a web application is a client, and so here we also create a client, which is kind of connected to the computer, so we can create credentials typically a password which we can store safely on the computer.
And this the computer can use to connect to the IDP and then ask does the user access to that exist and does this user group memberships for example.
For authentication this client has to allow the device authorization ground because this is kind of the only authentication flow which can be triggered without a web server.
Soon or later we will need a web server as I mentioned before, but the initial trigger can be done without a web server.
And this client must be configured to allow user and group look up as well.
Basically, you can think about creating this client as joining the main in the classical sense.
So here's where we only might come into play and future so that we can simplify this that we do not have to create this client manually and give all the permissions to the client manually, but have some utility to do this automatically for you.
Okay, as I already mentioned, an important step here and also with the free IPA integration to a big similar IDP is the device authorization ground because we have to trigger this when the user is logging in for example with SSH.
Then the server site somehow has to trigger starting or initializing your the authentication because at this point in time we do not have any kind of web server available.
In future graphical interfaces might integrate this so there's a working progress by different Linux vendors.
In this area, so at least on this level when you're initially logged in to your computer was a graphical interface that might be the possibility to have a minimal that browser so that you do not have to kind of get some extra steps.
But the basic trigger will be the device authorization the device authorization ground as well.
So, as is the will do user and group lookups for you.
We have the credentials to connect the IDP with the help of the client ID and the client credentials.
And as I mentioned before, most of them have some similar understanding about how to do this, how to do this so we will have a request to look up a user.
You'll have a request look up the groups and then you will have requests to look up the members of the groups and the memberships of a user.
And since all of the IDPs will are doing this differently and have different APIs, we will kind of try to provide a plugin interface so that it is easily to extend when there's a new IDP coming around and has some additional API.
Currently, what we have in code is interfaces for entry ID and for keyclock and if the demo works, I will show you how it's working with keyclock.
As I mentioned, IDPs typically do not have physics attributes as claims or whatever start.
So we have to make them up on our own.
And this is basically not new to us because SD is connected to or can connect to Active Directory.
And as you might know, when you have a default Active Directory installation, there is also no physics ID, no home directory and so on.
There are a couple of extensions which are added by Microsoft way back in time and currently are kind of only existing in the out-up schema, but there are no physics anymore to manage them.
Nevertheless, we were used to this so they are already as the options to provide a default shell.
So if the user entry does not have a shell, this shell will be provided.
We also have some kind of templates to generate home directory based on the username, so like default slash home slash and then the username.
So those we do not need.
And also for Active Directory, we added some ID mapping so that we have an Active Directory user or a group.
We can generate an ID for this and this is not only just kind of making up a number, but we try to do this algorithmically.
So that when you have two different systems joined to the same Active Directory domain, they generate the same new ID and the same GID or private GID for the user without having interaction between each other.
How we do this is basically we take the sit of an Active Directory object, be it a user or a group, take the domain sit part, which defines us some range, and then take the width part.
So it's the last part, the last number of the sit, which is counted upwards by Active Directory, so we use this as a kind of offset.
For example, we pick a range for ID starting with 1 million and then we add width 2030 to this and this will give us the project ID 1 billion 2030.
And this will work on all the systems connected to Active Directory, so all the client systems will have the same new ID, GID and so on.
I hope that with the stronger use of IDP, sooner or later will also have some kind of ideas how to define some positive standards in the IDP world, so that those attributes will be available or can be easily set in IDP as well.
This would make life easier, but as of now we have to generate them on.
I described how we mapped the positive ideas for Active Directory, and we will pick, or have here for the example, pick the sooner scheme for the IDP.
We take, we do not have to domains it for the IDP, but something which is unique and also available for all IDPs, for example, with the token URL.
Since it has to be accessible in the web, it has to be kind of unique, and since every token has to be requested while this endpoint, it is also always present for the IDP.
For example, one thing we can use as kind of identifier for the IDP and to select the range.
There, of course, depending on the IDP, other ways to select the range.
For example, with Android, you have your tenant ID. This is, of course, the tenant ID is part of the token URL, but you can also restrict on this tenant ID if you're only working with Android, for example.
So this will most probably be configurable over the time for the different providers, but kind of the default might be the token URL.
So this selects the range, for example, they are starting from 1 million to 2 million, or 1 million, and 200,000, which is typically our default size of ranges.
And then, unfortunately, there is no such nice number as the written active directory, which is counted up by an IDP.
At least not generically, typically objects and IDPs have some new ideas, which have no structure at all, so we cannot use this.
So as a first step, we are using another hash, and there's the hash of the username, which is unique for the user as well, and this then defines us a UAD or a number inside of the range we are selected.
There's one kind of severe problem with this, as you know, hash is not revertable.
So it is with this scheme, it is easy to get a UID or a GID, if I know the username or the group name.
And of course, SSD will cache this, and then we can, of course, find for a given ID, the user bag.
But if you do not have the cache and start just with the ID, we kind of kind of trying to use this, so this is a kind of drawback of this scheme,
and depending on the IDP, if there is some upcoming number, it might of course be better to use this.
But this is the hash of the name is kind of generate, will kind of work for all, with a restriction that is not revertable or invertible.
Okay, now coming to the demo.
First, if you want to try this at home, as I mentioned before, there is a copper repository with a couple of packages for reason fedora and relevant and maybe some other platforms, where you can download the packages,
as this repository, there are also kind of configuration instructions, and you also find links to my code, working GIDs trees, if you want to compile it on your own, on some other platforms.
For the testing, if you do not want to kind of mess with your system, I do using the SSD CI test containers.
We are using inside of SD to run our test scripts, so they make it easy to set up a container, as is the client, an IPA server, some of the ID domain controller, as Active Directory server, an LDAP server, a couple of server and so on.
And there's also nowadays key blocks server available, so we have an IDP, we have a client, and so we can use this for testing.
Here, I also put the configuration in the slides. I do not know how familiar all of the SD configuration, but basically there is a new ID provider called IDP, which has options on its own, basically defining the IDP and points and so on.
Okay, now let's switch to my client. Okay, first let me stop, as is the, okay.
So just as a proof, so now, currently, if SD is not running, the system does not deal the user or one at T-clock.
So this is my configuration, it is basically the same as on the slide.
There's some generic blocks for us as D, and here I'm going to see the replays, the shell, the bash, and have the template for the home directory.
Let's start again.
Or maybe we have a look at the keyclook server first.
So as I mentioned, we need a client on the keyclook site, I already have prepared a client of session time.
Okay, and as you see, I allow client authentication, so the client can authenticate with the help of a password.
I allow device key authorization and service count rowing spins. I have assigned some rows to the client, basically to allow them to look up users and groups.
And I have some users here, user or one, user or team.
Going back, so I started SD.
I remove logs, and I remove the cache at all, as well, so to be sure there is no kind of object already stored on the system in the cache.
Okay, so now the user is present on the system.
I prefer a fully qualified name, so the username is user or one at keyclook.
This might become important when you have multiple different IDPs, because SD allows by design to configure multiple domains or sources.
And yeah, when you collect from multiple IDPs, there is a fair chance that you have a collision of user names.
This is typical, for example, active directory environments where all the main, every domain has an administrator user,
and the domain user group, so you have to use for the qualified names and those environments to not confuse you and the system.
And you see, the user has a UID and the primary GID, so we, by default, use the private groups, so the numerical value of the primary group will be the same,
and it has also auto-generate home directory and to shell.
There was a second user of user O2, it is here as well, and you can see the IDs are kind of coming from the same range,
but differs. So yeah, this is of course important that you have different UIDs and GIDs for all the users.
Okay, next step authentication, and so I will, as is H, just onto the local host.
And here you can see what device authorization means, because you are getting a prompt back that you should connect to URL,
and then even type in some authorization code.
But keyclog is so nice, also presenting a URL where you have both in one, so we have the do not have to type the code on your own.
And so I open this URL and say, okay, I'm successful without them.
I'm going back to my shell and press enter, and now I should be able to log in, but it fails. Why does it fail?
It's because of the browser. I've shown you some details of the keyclog configuration, and I'm still logged in as admin, and now there's user O1.
So the browser, since it's caching all this information, is still thinking, I want to look in as user as administrator.
But on the other hand, I want to look in as user O1. So this is already the example that you kind of cannot freak out the system.
So you really have to be logged in as a log out button.
Okay, closing the windows. Okay, now I use the new key.
Okay, now I'm asked to log in because I'm logged in at all.
So I'm asking again, if I want to allow the access, okay, success will look in on the IDP.
And now I'm also successfully logged in to the log system.
Okay, demo worked. That was basically what I wanted to show you.
Thank you very much for your attention. As I mentioned, this is working progress. If you have suggestion, just send me an email or there's also a GitHub issue about this topic, where there's already some discussion happening.
Just suggesting a question about, what about Android, what about kick-load with some details, or if you have insight of some of the other IDPs, yeah, feel free to reach out to me or send some comments to the GitHub.
Thank you very much.
So we don't have time for questions. Can the next speaker, we don't have time for questions, sorry.
Maybe it's better if you don't have time. Okay, time is running out, give me a map, okay.
What about the UIDs of the user's new works? Yeah.
I think systematic, I can do, if you import them in a different way, it doesn't really get access to files, right?
Just, just.
Yep.
Thank you very much.