Tor Hidden Service Access

More as an experiment than anything else, for the time being this site is available via the following Tor hidden service address:


This will allow allow access for anonymous reading as well as access from known non-U.S. IP addresses that are now temporarily blocked by policy.

Users should find that the mechanism prevents contact form submission as well as the ability to login to the site; however, all posts and pages are available as usual. Note that this secondary access is not designed as a hidden service hardened against known Tor implementation weaknesses; rather, it’s just another way to view the site with general Tor protections. Lessons learned here will likely find their way to the Sanctuary IdP project. In the meantime, I make no guarantee that I’ll keep this particular access open.


Logging into Google Business with SSO? #technote

It’s probably not worth the trouble.

We all get Authentication — Are you who you say you are? — and we all get Authorization — Are you allowed to access this resource? We layer in time constraints, location constraints, notions of groups & roles, and so forth, to specify Policy. Now here’s an important implementation question: What should specify your Policy, your identity management system or your applications?

That depends on a few things, including what you mean by that word ‘your.’

Common sense says that I decide who has accounts for what services in my company, I set the password complexity and reuse policies, I decide if there’s a 2FA requirement for this or that, I decide how long a user session can be before idling out, and I decide how long my applications can go on their merry way before checking in to make sure the user’s access hasn’t been cancelled. So many “I“s… very egocentric, no? Well, no — It’s my frickin’ company! I have security concerns and compliance constraints. Of course I set the policy!

Enter systems engineering: We ensure that the the identity management system is available to the application, we ensure that the application has access to the information it needs, and we require the application to enforce our policies.

So, Google for Business… Google requires that we create an account for our users there first, after which SSO with our own IdP is allowed. That’s not a problem; I’m sure that helps with their licensing and billing. After that, though, things go awry quickly.

  • Google gives strong caution to our users that the company, not Google, is managing their accounts, and that we may have access to the data in their accounts.
  • Logging into Google administrative areas explicitly requires the use of credentials on Google rather than requiring us to specify an admin role in our SAML transmission — that’s a Google policy.
  • Google will occasionally demand from a user that he re-authenticate using Google credentials, bypassing or ignoring the corporate authentication system.
  • Once logged in with the corporate system, Google will keep the user logged in to the Google services, ignoring corporate session policy set on the corporate system.

Those are serious indicators and concerns in my book. We should not have a service we pay for in conflict with our own policies and central management systems. At a minimum, it forces the corporate administrators to maintain users, credentials, and logs, in two different locations.

Now if you’d like Google to be your company’s identity management provider — with your users logging into all of your apps with your Google credentials — well, that’s another story! It seems Google is happy to help there for $5/month per head or so.

As it stands today, I personally use my own IdP service to SSO login to a few legacy Google for Business domains as a convenience, putting up with the quirks, but I would be hesitant about recommending that as a seamless solution with smooth user experience to corporate clients. Google simply violates too much of what we expect from centralized corporate identity management. Be careful before locking in with them.

Feel free to contact us with questions, comments, or your own experiences, or when you’re considering your own identity management architecture.

Note to Self #admin

In the top-right corner, there is a new page link entitled Home Lab Tech. Here we’d like to include tips, technologies, equipment recommendations, and so forth for folks aspiring to stand up their own labs. The goal is to enable a motivated individual or team work through standing-up a network and all of the services they may be called upon to deploy, support, troubleshoot, or protect. It also sets the stage for more specialty work, such as penetration testing, intrusion detection, malware analysis, and so forth–in a controlled, realistic, safe environment.

It’s a work in progress–and probably needs to be more than a WordPress page, or maybe that page will have links to posts here, or… Regardless, we don’t mind you watching the construction. If anything, feel free to ask questions or provide recommendations and feedback via our contact page.