So, hello. This is where I get an email later from
FOSDEM where should we cut the feed and start a new one.
So this is where we will cut. I'm going to do a talk about making
Ansible playbooks to configure Singlesign on for popular,
popular open source applications. Yeah, I got that right.
So, who am I? My name is Jerome Betten.
Jeroen Barton, if you do it pronomously, correct in Dutch.
Let's see what else there is. Oh yeah, if you're English and you want to know how you
pronounce that, you just read this out loud and it should work.
I do open source stuff. One of my recent projects is Chateau IT,
which has a slide on its own. I wrote 12 books and I got a couple more in
beta. I've got three girls and my wife had two girls so we married and there you go,
five girls. I used to be a volunteer firefighter, did some
scouting stuff. I do training and I hack a lot when I can.
So what do I do? In this case, I do open source consultancy.
One of the things I do is Chateau IT and in Chateau IT, we do training.
One thing is the Bernard Prevention training so that's not so much IT, little, no IT actually,
but it's for a technical crowd. And it's in Dutch but why the Chateau?
Because I'm going to do that in the center of France.
Anybody here from France? Okay.
I have a little longevity in the center of France.
We have a lot of it. Okay.
XOIT, I retrained people to IT. I did that a couple of times before.
I retrained a sailor into a programmer, C++ and I retrained somebody who had been selling
suitcases at a warehouse for training years and he is now very, very, very happy working
in the IT, starting in a help desk position.
But he's happy because he's working with computers and he used to do that for his hobby
and I helped him out on that. And those are, well, training for the really good IT guys
and training for bosses management to explain technical stuff if they need that.
But no commercial. Okay.
Another project I do is LibrePlan which is a web-based project management.
It's in Java. It's extremely cool. Have a look at it.
And it's, I think I can safely say is about the best project planner that's out there in the world.
For one minor detail, I'm about ten years behind in making a package.
Full disclosure. But I'm going to do that next month or the month after that.
So it will happen this time. Apologies.
Is there somebody here from England? UK?
Oh, that's good. Oh, there is.
Apologies in that case because I speak English words but I don't speak English.
Okay. Because I once found this translation guide that says when the British say with all due respect
and what they mean is I think you're wrong but what I think, oh, he respects me.
Oh, that's good. We've got a nice vibe going on.
Because we take in Dutch if it's English and any other language, we take things, everything literally.
Which sometimes lead to awkward situations.
Okay. The project is short.
I was hired to be a general manager at an IT company.
I learned two things. One, I shouldn't be a general manager of an IT company.
That's somebody else's job. Should be.
But it was an IT company without IT landscape.
There was nothing there. Well, almost nothing.
Which is weird, especially for an IT company.
So I started with the Proxmox Virtualization Server.
I installed free by LDOP. I installed some applications.
You know, XWiki for the wiki. If somebody doesn't have a wiki, look at XWiki because I think it's the best.
Zebix Monitoring, Jenkins, SnacksCloud, GitLab, Odo.
Odo is ERP from Belgium. If you haven't heard of it, look at it. It's awesome.
CMD-Build is a completely customizable configuration management database.
So if you haven't heard of it because not a lot of people have, look at that as well.
Because you can really tune the data model of your own business into CMD-Build.
And then put data into it with rest interfaces and connect it to other systems.
Okay. And I got a question. How to upgrade this landscape?
So I did this with LDOP authentication and somebody said, yeah, is there any way we can make this better?
I said, well, you could switch to single sign-on. That would be an improvement over every single time entering your credentials.
Oh, yeah, sure. Go ahead. Make it happen.
So I was sponsored heavily by the owner of this company.
By the way, it was Onstein in Breda in the Netherlands. And they are an Odo consultancy club.
So, showing the Netherlands, thinking about ERP implementation. Have a look at Onstein.
And they will gladly help you out.
So I promote to make everything single sign-on. And that's where our venture starts.
Basic lingo is that you need to know for single sign-on is the application that uses it is SP, the service provider,
because it provides a service.
And the application that does the identification is the identity provider, IDP.
So you have to know SP and you have to know IDP.
If you understand that, we're almost there.
In our case, I used Keycloak, which is a very popular open source project with very nice features.
It's a Red Hat project. And they used to have Red Hat identity server, which was based on Keycloak.
And Keycloak became so popular, so now it's Red Hat's packaged version of Keycloak.
Because Keycloak is more popular, which makes sense.
ACS is Assertion Consumer Service URL. That's the service provider sign-in URL.
So any application has an ACS, if you can single sign on to it.
And you need to know that URL because you need to configure that at the IDP, the identity provider.
Of course, you need Ansible, the. And who doesn't know what Ansible is?
Okay, so Ansible, and I'm always getting slapped in the face.
Oh, you know. Oh, you know. Okay, okay.
Maybe somebody is watching.
Maybe somebody who is watching. Okay, so Ansible.
And I'm being slapped if I say this, but I keep saying it.
It's a sort of a recipe language because I shouldn't use recipes because recipes term is claimed by.
Chef. Thank you.
But for the layman, and I'm a dumb guy, so I use the word recipes.
Because you simply say, oh, now I want this computer to have this package installed.
Now I want this configuration file to have that line added or deleted or changed.
So you have all those very easy to read steps, and you make a recipe that you can send to a server,
and then those steps are being done on that server.
And it uses some JSON stuff, and anybody here who's a fanboy of JavaScript?
Okay, because I think the JavaScript is a bad language, but JSON is very cool.
Oh, that sounds like somebody who differs.
Okay, basic single-cell no-process flow.
The user clicks login on an application, application X.
The browser of the user is then redirected to the identity provider, in our case Keycloak.
The user is presented with a login widget by Keycloak.
User logs in successfully, hopefully, or gets an error in the night message.
If not yet 2FA configured, but set as mandatory,
he gets 2FA setup dialog, all done in Keycloak.
So it's very easy to enable 2FA for users.
So you should, because that's today almost mandatory in a secure environment.
Then the browser of the user is redirected back to the service provider
with some credentials proving he has successfully logged in,
and you get the application and you can do your stuff.
Now, if you then, every other application is also redirected through Keycloak,
but he says, oh, but you already have logged in, and you're immediately transferred back to your application.
So it's single-signal. Any questions so far?
Okay, cool.
That's what I just said.
The setup, user IDs are held in this case in free by LDOP, Keycloak for Web as a zone.
Syncs with free EPA, so the LDOP is synchronized with Keycloak.
Well, Keycloak gets the request and then sends it to LDOP for verification,
gets back the signal, yeah, everything is okay, and then continues with the identity process.
And the Keycloak server has a client definition for every application.
So you can also read here client configuration, sorry, application configuration.
But in Keycloak lingo, it's a client definition.
And so it's not every user that logs in is not a client.
No, the application is the client.
So I started with this.
The first application, X-Wiki, configuring it, writing Ansible, 20 minutes done.
And I thought, what could possibly go wrong, right?
Because, you know, I've only got, what is it, 8, 9, 10 applications to hook up,
20 minutes for the first.
Man, this is a breeze in three days, I'm done.
So about a year later...
It's...
Sorry, what?
Your certificates expire.
Yeah, my certificates, no, no, almost probably, but I'm very bad at certificates.
Internally, in a land, the lifetime, you know, I make it, I don't know,
sometimes 10 years, I don't care.
It's internally, so...
Anyway, this was a walk in the park.
It was based on good documentation.
Do you know that there are developers who don't document their stuff?
No.
No, yeah, they don't, they don't.
Some of them is really awful.
Anyway, I added another application, etc., etc., etc.
So this is what the client list looks like.
And here you have...
I made...
This was my bad sense of humor.
I made the key cloak server internally AD as host name,
because that's what everybody from the outside would expect, right?
And CMDB is here.
Yeah.
Okay, let's have a look at the program flow.
And with program flow, I mean the Ansible playbook, my recipe.
So there are two valuable files.
One is global and the other one is encrypted,
because, of course, to make a client definition on the key cloak server,
you have to know the admin credentials of the key cloak server.
So that's, of course, in an encrypted vault.
And if you don't, you're a bad IT guy.
Playbook works on the application VM.
So I have made for every application a single playbook,
because that's easy.
You only, if you want to change something,
you just look at that one playbook, sometimes two, couldn't be helped,
because everything there is in a logical order,
should be.
And it's directed to the application virtual machine.
And then the application virtual machine will connect to key cloak,
do some magic, and configure its own,
and then at some point, hopefully, it's done.
So the playbook retrieves key cloak endpoints info via the host.
Checks if key cloak client definition exists,
and if it exists, it will delete it, because we have a playbook.
And I can trial and error the hell out of it,
and just delete the former client configuration,
create a new one, and then configure that.
So, yeah, it just deletes it.
It fills a client definition template, that's in JSON,
and that's a JSON file,
uploads that to key cloak,
with some keys that it has created, and some variables,
and then, yeah,
and then the client definition is created on key cloak.
He checks, of course, if the client conversion is created successfully,
if there was no error, and if not, okay, it downloads a shared secret,
if relevant, if you use OpenIDC,
because there are two ways to authenticate single send-on.
One is OpenIDC, and the other one is SAML.
So I have both in the set of recipes.
So it's either OpenIDC or it's SAML.
And Ansible leaves you with a configured application, if you're lucky.
It even installs the application,
and I need to start talking very quickly.
Normally, I do this in an hour, now I have 30 minutes,
so that's a problem, a slight problem.
And at the end of the playbook, it displays remaining tasks,
as in, look, you are the admin guy, this is the user credential,
this is the password for the application I just installed.
Now you need to go to this menu, this sub-menu,
that you have to click this button, or you have to enter this string,
if I couldn't do that remotely.
For instance, if you install Jenkins single sign-on,
you can do that using Ansible,
but then it's a chicken and egg problem,
because vanilla Jenkins doesn't support the REST API.
You have to install a plugin, which I don't in my playbook.
So, anyway, trust me, it should be easy.
This is a very small print, but basically,
these are all the steps that you do in the playbook.
And since I have five-fifty minutes left,
and the slides will be online, and there is a repository,
every application also has a wiki page with extra notes,
there are comments in the playbook,
so, and if it doesn't work out, send me a message.
That's how open source works, right?
There's some tricks that I had to use,
so this is a sort of condensed JSON stuff,
so here you have your application-specific ACS,
so that's where the key clock has to redirect you to,
in this case, Zabix, to get you logged in,
and you have several ID fields in JSON,
and the ID is a random UUID.
So, look up Community General Random String,
and it's 20 to UUID, done.
So, it's just a random string,
and it changes every time you run this.
You have to define the algorithm,
the certificates which are generated,
are placed in this variable,
and then send this JSON file to key clock.
Some of those applications need protocol mappers.
In this case, the Zabix user protocol mapper,
because it's SAML and Zabix expects the return thing to say,
oh, yeah, Zabix user needs to have this email address,
and you have to, that has to match on the email
between Zabix user and key clock LDAP.
Yeah, oh, yeah, and SAML's multi-valued roles false.
It's now about a year ago that I did this talk for the first time,
so don't use key clock 18,
because you can set it to true or false.
It will always be true, which means it doesn't work.
That takes you a couple of days to figure out,
but it was changed and the bug was smashed, whatever,
after 18.
Okay, so once you have a working synchthonal setup,
use...
Yeah, we're doing it again.
This is if you start out for the first time with an application,
and you don't have my playbooks,
and you know a little bit about synchthonal,
and you get it to work,
then you need to have the client configuration of key clock,
and there is a very simple script
that will just give you the whole list of client configurations,
and you copy-paste that one entry out of it,
pipe it through JQ, replace settings with variables.
There's even, I put in here, a very small div
to compare two JSON strings,
because he will order the fields and then do a div,
so it's very easy to use.
And why do I tell you this?
Because I want you to do some work.
Anyway, gotcha.
Everything was better when you used HTTPS,
because synchthonal and HTTP should work,
but often doesn't.
So just default in your head,
make everything's HTTPS.
Don't think it will be easier if I don't,
because it won't.
That's one.
Tomcat expects an SSL keystore to have the password,
change it.
Don't change it, make that the password.
It's, and maybe somebody else knows the other way,
but that's my experience.
Some application developers can't read.
If the standard says optional,
that is not the same as mandatory.
So you look at stuff, you think this should work,
it doesn't, why shouldn't it?
And you start looking at it and debugging it
and trial and error, recipe and delete client,
make a new client, and at some points,
oh, this is mandatory for them.
The standard says optional.
This developer, shit for brains, made it mandatory.
And some applications are very badly documented,
which is probably not a surprise,
because that's basically our day job, right?
Oh, yeah.
And adding the free EPA keycloak user ID sync,
midway was not a smart idea.
I could just start from the beginning.
So if you're thinking about using LDAP and keycloak,
start with that and after that, do the recipes
and don't do, oh, keycloak, oh, yeah, that works.
I probably should sync to LDAP
because you can start all over again.
And to me, Ansible can solve just about any problem.
Well, in IT, right?
So not like world hunger or world peace.
It's a little ambitious.
And do not use keycloak 18 unless you like long searches.
And walks in the park.
Okay, so your job, if you choose to accept it.
Because I have a repository.
Add applications and build this further.
The most, well, what I think are the most popular,
but probably you think what's he talking about.
This application is way more popular.
I forked this, so I forked this from the one-stein repo
that I made for one-stein, of course.
But of this, I'm 100% sure I can always accept pull requests.
Right?
So I don't want to diss them.
I'm very grateful for all the time they invested basically in me
to make this happen.
And yeah, that's simply because it's a very nice open source company.
And if you have an application that you want to hook up using SAML,
start with the ZappX Playbook, copy it, change it,
because you know your application, I hope.
Or you have got something running and configured,
and you know how it works.
Please adjust the Playbook and send a pull request to me
for OpenID Connect.
Start with the X-Wiki Playbook, because it's OpenID Connect-based.
And every application is documented in the wiki on my repository.
So it should be relatively easy if you know a little Ansible.
And Ansible starts with the Playbook that does a ping and says,
Pongbeck, if you have done that, you can do this.
Yeah, sort of.
Yeah, it's not that complicated.
It was complicated for me because I had to do ten applications
and some were severely badly documented.
So Tui can tune to work in config, send me a pull request,
and well, within the time.
Are there any questions?
Yes.
Thank you so much.
In the middle of the presentation, I mentioned that you use variables
to grab those variables from a vault.
I recommend grabbing them from a vault.
We did the same.
And now we have a couple of some applications consuming.
So at the end, they are a volume of some hundreds of variables
that you can't solve all over the directory.
And then suddenly it became very slow and running the Ansible Playbook.
We can really, really slow.
And that's a constant and easy solution to that.
Right?
There are variables, not long-gauge series, but simple variables
that increase the speed incredibly.
OK, so to repeat the question, you have the experience
that you have playbooks with in a vault a lot of variables
and it becomes slow.
And the suggestion by the kind server over there is to don't use large dictionaries.
Or use fact caching.
Or use what?
Fact caching.
Yeah.
Or that.
So, well, I had a very simple vault simply with the credentials of the keycloak server.
That is basically just about it, which is, of course, two variables in a file.
I did the password on my command line, of course, not in a repository.
The.
So my command line was simply look at that file for the password.
And this is my vault file and do this keyboard with this host file.
Yeah, sure.
Welcome.
Yes, kind server.
You seem to be interfacing with a keycloak in a kind of like the wrong way.
Because have you considered using the Antopole Community Keycloak module?
No.
There are actually very extensive keycloak modules.
Yeah.
They can configure keycloak.
Well, the Ansible, there are some things about Ansible that I really love and some things
about Ansible that I don't love.
For one, I understand that because of the popularity, you need to start working with collections
to split stuff and separate.
What's the word for that?
Accountability now?
Separation of concerns.
My goal was to make a set of playbooks that's very easy to read and a single playbook for
a single task.
So I don't use roles and all the subject directory, mumble jumble that comes with it.
Now, a single file with a couple of steps that everybody can read also to understand how
this stuff works and make it and configure it once.
And yes, there are a lot of collections.
There are a lot of excellent Ansible playbooks that are spread around the Internet Universe
that gather information.
You can even do a Kubernetes install.
But that's a repository on its own.
And I wanted to keep things simple, the KISS principle.
Sure, but in Ansible, one of the objectives would be idempotency.
And you start with deleting your client.
So basically, you come to the idempotency tool.
Will you confirm your client every single time?
Yeah, I do.
Yeah.
You know that?
What can I say?
It's a design decision.
And yeah, that's basically it.
Sure, thanks.
What about use cases when you have the IDP and the SP in different network segments?
Think about your key flow needs to be in LAN because your customers need to be protected
because they don't have proper security updates to key flow.
Yeah, right.
But they want their kitlab public or the other way around or their service.
Usually, service is not in the open.
Okay, yeah.
So the service provider server needs to be able to connect to the key flow server during
deployment of this playbook but also in production.
And where they are, I don't know.
I don't care.
I'm just asking from the Ansible side to connect to them.
I mean, like for the workflow, how do you deal with customers that have those requirements?
What requirements would it be then?
Not to run an unpatched key flow in public because your kitlab runs in public.
Oh, yeah, but you can.
No, I wouldn't do that.
So, time's up.
Thanks so much for your attention.
And have a nice day.
Thank you.