Tech

On my Linux desktop I have multiple sound devices. Typically it’s the built-in sound card, the graphics card audio output and my GoXLR outputs. I don’t ever want to use the built-in audio or have audio routed to my monitor. But the Linux desktop has this habit of sometimes switching to one of those outputs, especially when coming out of standby because the USB audio devices provided by the GoXLR disappear.

A little annoyance I always run into when configuring a new laptop is getting Gnome Display Manager to use Colemak on the login screen. For some reason, it’s impossible to configure the GDM keyboard layout unless there’s at least 2 users on the system. Otherwise Gnome Settings refuses to show the UI for it. I’m not sure why this weirdly hostile feature towards folks with alternative keyboard layouts on a single-user system exists in Gnome, but here we are.

For a long time, I’ve had a setup with Keycloak as the IDM. But Keycloak is heavy. It’ll OOM with less than 2G of RAM and needs a database too. It also has features I don’t care for, like realms. As I’ve been slowly moving to self-host a few more things, including outside of my home, I want to have a way to centralise authentication for those services too. I want to keep the IDM for the home lab separate from my cloud things.

In a previous post I showed you how to setup Keycloak to provide you with OpenID Connect and SAML capabilities. The problem with Keycloak is is that’s it’s a pretty big beast, whereas most of the time we don’t need all the functionality. It’s also tricky to run in a highly available fashion and is annoyingly slow to start up. In this post we’ll drop Keycloak in favour of Dex, a small OpenID Connect Provider that supports a number of backends including LDAP.

In a previous post I showed you how to set up Gatekeeper as a proxy to enfroce authorization on requests. The problem with Gatekeeper is that it required a lot of additional configuration, an additional proxy hop and is a separate component. What this post will do instead is use the OpenResty build of nginx with the OIDC plugin to avoid all of that. This brings the complexity back down to just running nginx with it acting as a Relaying Party to do authenticaiton and provide authorization information to backends.

NOTE: A much simpler solution is describe in BeyondCorp @ Home: Authentication and authorization proxy with OpenResty In a previous post I showed you how to set up a “Lite” version of a BeyondCorp style access layer for a home or startup environment. The reason I called it lite is because though it does do full authentication, it didn’t have separate controls for authorization. Meaning if you could authenticate you were authorized, I couldn’t specify that for certain endpoints you have to be part of a specific group or be granted a certain role before you get access.

Update 2019-10-06: If you don’t need SAML, consider swapping out Keycloak for Dex instead. You can read all about that in this follow-up post. BeyondCorp is a different approach to securing access to networked applications and services. Unlike the traditional perimeter security model, BeyondCorp dispels the notion of network segmentation as the primary mechanism for protecting sensitive resources. Instead, all applications are deployed to the public Internet, accessible through a user and device-centric authentication and authorization workflow.

This post is part of a series on directory services. Current available installments are: Introduction Terminology Basic concepts Designing the DIT Setting up an LDAP server Securing your LDAP server Writing and testing ACLs Now that we have a directory service up an running it’s important we talk a bit about some security aspects. The configuration that was generated sets up the LDAP server in such a way that anonymous access is not allowed.

This post is part of a series on directory services. Current available installments are: Introduction Terminology Basic concepts Designing the DIT Setting up an LDAP server Securing your LDAP server Writing and testing ACLs I consider setting up a Directory Service a pretty big pain in the ass, especially OpenLDAP. Microsoft fares much better with Active Directory which is also much more easily configured for folks less familiar with directory services in general.

This post is part of a series on directory services. Current available installments are: Introduction Terminology Basic concepts Designing the DIT Setting up an LDAP server Securing your LDAP server Writing and testing ACLs ACLs, access control lists, are an important aspect of running a directory service. ACLs are how you control who can access which parts of the DIT and what things they can do. You can limit certain things like which attributes one can read or write.