Long Weekend Update

Email Integration

Aside from general work to improve the security posture of the public interface, my latest focus is standing up an email service for new registrations.

The working assumptions include that

  1. an individual will be enrolled via keycloak or a similar identity management package;
  2. on enrollment, several service will become immediately available to the user, including email;
  3. email will be accessed through a web interface; and,
  4. it would be pretty silly if we’re using an identity management platform if our web interface for email had yet another login interface, right?

I anticipate that we’ll be starting with an Ubuntu server 18.04 operating system running Postfix for SMTP and Dovecot for IMAP, where Dovecot provides the authentication functions for both SMTP & IMAP. For the web interface, I’m taking an initial stab with RoundCube, which itself rides on a LAMP stack.

There’s some additional discussion of the work in the article “Integrator Challenges, Email Edition” (link), but in summary:

  1. The operational test email stack that I had readily available is riding on Ubuntu 16.04, whose repository supports a Dovecot version that does not yet provide OpenID-Connect support.
  2. RoundCube has a plugin for handling OpenID-Connect, but it appears to add a bit too much complexity for what we’re after. Instead, I’m taking a look through the RoundCube source code (PHP) and examining how they handle Kerberos, which provides somewhat equivalent challenges.

All in all, it’s clear enough to see that it’s possible, but not too clear to see how long it’ll take to work through in my spare time.

Still, it looks promising and RoundCube does indeed look like a nicely designed project.

Fingers crossed!

WordPress Attack Aftermath?

Well, there’s no aftermath, thank goodness.

  1. I continue to block known foreign IP addresses during development as the log shows no sign of constant blind attacks relenting.
  2. Killing DigitalOcean access has made the logs so much quieter. That’s a shame. Since their CIDR blocks are scattered all over the place, I occasionally do spot another one sneaking through like roaches. Each new offender results in nuking the whole block.
  3. I’ve added two constraints on accessing the wp-login.php endpoint: (a) No POSTs, and (b) no GETs without referrals. Obviously the no POST rule is sufficient to quash a password guest, but that may be opened up again later. The second rule helps blunt scanners and helps help thwart some of the password guessers.

And now, since we’re mostly dealing with U.S. visitors, Happy Labor Day!

Registration & Login Now Available #admin

Update, Thursday 1 August 2019:

Logins and new user registration are available only through the Keycloak SSO interface. Clicking a WordPress “login” link will redirect you to the Keycloak interface. New users should find the “register” link beneath the login form. For the time being, a valid email account is required as part of the initial registration and two-factor authentication (via Google Authenticator, Authy, etc.) is required for subsequent logins. As we experiment with adding services, expect those requirements to be reduced.

Previously:

This website is present for information and for a bit of experimentation. Information comes first, of course, and while we were tweaking it a bit, we locked out the ability to register and to login, which in turn blocked the ability to comment and so forth.

Yesterday, I turned on the registration in two ways:

  1. Basic, WordPress-native user registration and subsequent logins are enabled.
  2. Login and registration via a Keycloak single sign on (SSO) package is also enabled.

If you register first with the “Sanctuary IdP” SSO server, the WordPress account will be created from your SSO data. If you register first with WordPress and follow up with the SSO, you’ll be prompted to link the two accounts. At this time, both logins require you to verify your email account. The second login to the SSO account will require you to set-up 2FA TOTP (Google Authenticator or Authy, for example).

In essence, it should give an experience similar to “Sign in with Google / Facebook / Twitter / …”: If you’re good with them (i.e., you’re logged in with them), you’re good with us.

Here is the “experimentation” part, though: Over time, I want that SSO registration to create an internal email account that users can use rather than verifying one of your own. That will be part of rolling out related test services. The WordPress website will consider enrollment in the SSO as sufficient to authenticate you — something less than a “WordPress verified email.”

It’s a start! In the meantime, feel free to create accounts and comment. 🙂