tech

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.

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 apologise for the long delay between posts. Life took over for a while and I never got around to writing the rest of it. Sitting down and thinking a bit about the DIT upfront can save you endless hours of furstration later on.

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 Directory Services are fundamentally pretty simple. All information they contain is stored in a hierarchical tree structure, called the DIT. Within the DIT entries can be nested into or beneath each other, creating this tree-like structure.

In this series of posts I want to talk about directory services. The directory allow you to model things like people, computers, groups and their relationships in a central database. This service can then be used for authenticating users, managing group memberships and a whole lot more. In many small environments people avoid the perceived complexity of directory services over manually managing and provisioning groups and users in systems. Though this can work really well, even on a small scale this can get annoying.