Hacker News new | ask | show | jobs
by lykron 3388 days ago
"A third domain is needed for internal use and back office. This domain would probably be registered anonymously, so it would be a little more difficult to find."

Um, security through obscurity is not security. And I don't get this? Are we talking Active Directory? It can be a subdomain off your root domain that is only accessible internally.
1 comments
inopinatus 3388 days ago
No. Absolutely not I'd say - because the purpose of an infrastructure domain isn't obscurity. That is simply a minor side-effect. The #1 reason is to assist in separation of concerns for the control plane, especially given the human factors in managing trust relationships between devices. The name should a) be instantly and recognisably distinct, b) easy and quick to type, and c) not creating risks of fuzzing a trust boundary due to misunderstood hierarchical naming.

Also, no-one should be using AD for SaaS infrastructure. It is a pretty good product for your enterprise internal services, but cannot handle the rather different needs of a SaaS system directory.

link
lykron 3387 days ago
I'm not saying to use AD for a SaaS product, I'm saying the advice on having an obscure domain is a bad one. The SaaS product is saas.com, the company domain is company.com, and the IPA or AD Domain is domain.company.com. I don't see any good reason to have a 3rd domain floating around for directory services. If anything it is another thing to manage and keep track of.
link
programd 3388 days ago
So what should be used for SaaS directory infrastructure?
link
inopinatus 3388 days ago
That's a damn fine question. There's probably a book in it.

Briefly, though, keep it federated; layering integrity is super important for systematic consistency and quality, so wherever possible, entities should register using the tools provided by the PaaS/IaaS layers that the SaaS is inevitably running on. This includes any home-grown PaaS/IaaS, which are pretty common in SaaS at scale. I like to delegate a DNS subdomain to each subsystem, which is then served either natively from that subsystem (e.g. because its control plane used etcd) or using script-generated zones served by nsd. The only central aspect I want is the meta-directory that contains, ideally, nothing but delegations under the infrastructure domain name.

link