My partner and I have been together for around 5 years. Since we’ve been together, I have gone from a Junior Systems Administrator to Cloud Engineer, to SDLC Engineer, to DevOps Engineer, and now to Security Engineer.

Each step of my career naturally brought new struggles and demands into the homelab. One of these was access to the applications.

It’s all good and well running amazing apps like Mealie and Lube Logger - but if you have to connect to a VPN first, then navigate to http://mealie and all your DNS goes over the VPN, and you’re on a sketchy Cellular connection… things get funky

This is where I’ve had to do user research in to how the average person consumes applications.

My solution was to use Cloudflare Zero Trust, their Identity-Aware Proxy, which allows authentication through systems such as OIDC, SAML, and Okta.

User research

One thing that technical users forget when developing and deploying applications is that users who’ve never used this system, let alone administered it - are going to be using it.

For this very reason, it’s important to understand your customers’ needs.

As I am based in the UK, our Government does an amazing job at publishing their own internal manuals on how they’re building a better online governmental service.

www.gov.uk | Learning about users and their needs

After speaking to my partner and observing how they logged into things, I noticed a few patterns:

  • Authentication is just a barrier
  • Any pop-ups they are met with, they click the positive outcome (eg: Accept cookies or Decline cookies, they will press Accept)
  • Hosted services should act and behave the same as SaaS services

After realising these needs, I’m able to improve my understanding of what it is they’re doing (intent) and what is causing issues (blockers)

What the current flow looks like

The first design was made before doing the above research. Remember, technical users do not see authentication (including authorization) as a barrier, we just understand it to be part of the process

Consider the below flow

  1. User intends to open mealie
  2. Navigates to mealie.domain.tld
  3. Cloudflare login page
  4. Click Signin with breadAUTH
  5. Redirected to OIDC provider
  6. Click Sign in
  7. oauth flow completes and bypasses Cloudflare
  8. Mealie Loads
  9. Click sign in with breadAUTH
  10. Go through OIDC flow again
  11. Page refreshes a few times
  12. Mealie loads!

This flow would take upwards of 30 seconds.

I, as the technical user had no issue with this - however my partner had such issue with this and would outright refuse to use Mealie, in fact they would argue with any service I had deployed to make our lives easier

Use Cloudflare as Mealie’s OIDC source

The design was simple here, once a user is authenticated with cloudflare, their authorization details are now captured and can be reused in subsequent sessions.

This design was good to start with, but it meant seeing the same cloudflare login page twice.

Considering this is not a technical user, seeing a similar login page twice just angers them. The usual gripes I got was “this stupid thing is asking me to login again!? I just logged in”

This is the point where I had to go back to the drawing board and work out what our options are

Working out our options

It’s clear based on their very vocal feedback that anything less that being asked once for their credentials was too much.

Mealie supports either native usernames and passwords, LDAP or OIDC.

I am already running an OIDC based identity provider on the cluster, so it would have to integrate with OIDC.

We’ve still got the issue of two front doors

  1. Cloudflare Identity aware proxy
  2. Mealie’s own RBAC/ Login page

We need to somehow break down the flow of being asked who are you twice.

The final solution

Bearing in mind the below user research results

  • Authentication is a blocker to original intent
  • User clicks positive outcomes

We are able to get clever with our design, using pre-exisitng technology

Cloudflare WARP agent

Cloudflare has an agent called warp that can do some nifty things like device based auth and policies.

Installing the app on their device and just leaving it in the background acting purely in auth mode means we can skip the Cloudflare login page

Cloudflare mealie policy

By setting the requirements to be oidc groups as well as Gateway they are able to bypass the Cloudflare login page which looks like the below

NOTE

Something I realised whilst writing this, is the policy is or meaning the user needs to be part of the group or use WARP meaning they don’t have to be part of the groups if they are using WARP.

I need to fix this

Mealie login page

Mealie specific configuration

Mealie allows us to skip the login button by setting the below environment Variable

OIDC_AUTO_REDIRECT: "true"

Which means the flow now looks like

  1. User intends to open mealie
  2. Navigates to mealie.domain.tld
  3. Mealie Loads
  4. Mealie sends user to OIDC login
  5. Auto-logs in using cached creds
  6. Mealie loads!

End result

Note, for some reason the gif is really slow. This takes around 10 seconds end to end

Closing notes

My partner has no editorial control over this publication beyond criticising my grammar. I am, and always will remain an independent blogger.

The views expressed about the success of this approach are my own and most likely do not reflect those of my partner. I have concluded that this solution works based on the lack of complaints.