Lately, the method of declaring your identity with more or less random, and static characters has come under fire in the public discussion. Here I am of course referring to the infamous Password, which is the subject in my blog.
While a good authentication related jargon still gives me a pleasant feeling, I’ve come to appreciate tangible demystifying explanations in recent years. Unfortunately, it’s more than often you see quite simple concepts dressed up with complex or technically unrelated vocabulary. For this reason we named our just released service simply Nixu Multi-Factor Authentication (Nixu MFA) – just what it is!
Something I feel proud about is that we’ve managed to convey the incredible amount of complexity into easily consumable and understandable service with the Nixu MFA.
I will analyze the modern cloud jargon in more detail at the end of this blog for those interested in mystic naming schemes of modern cloud services. But first I’ll introduce you our new service.
Let’s see how easy the Nixu MFA is to explain, use and deploy, while reviewing the service through a set of questions that require simple answers:
How does the user enrollment work?
The user can login self-service-portal after logging into Office 365 and scan the QR-Code, that’s it.
Does deployment require any inbound firewall changes to internal network?
No, only outbound connectivity is required from your network, neither any VPN tunnels are needed between the services
Does deployment require any on-premises servers?
No* you only install connectors that perform second factor request via secure connection to Nixu MFA.
* If the service doesn’t support the installation of the connector, or it’s not desired to install connector on the same server where service resides, then the connector can be deployed to another server
What services are supported?
Hitchhiker's Guide to Modern Cloud Jargon
Now, let’s return to the subject modern cloud jargon. As stated at the beginning of my blog, it’s more than often you see quite simple concepts dressed up with complex or technically unrelated vocabulary.
And can you blame anyone for it? Just think how cool it is to describe service issuing tickets with references to Greek Mythology. Or to call a database management product… wait for it… APACHE CASSANDRA … (And yes, it’s another reference to Greek Mythology and bygone warrior tribe in single server product name)
The point being made is that, sometimes conveying these concepts in such mystic naming schemes might have an adverse effect, especially if you’re aiming to transfer knowledge to a party not sharing your field of expertise. On the other hand, I bet some concepts stick better due to these exotic naming schemes, nonetheless in my opinion the balance tips a bit too much on the exotic side.
This subject, or similar subject isn’t entirely new. It was best approached by David Chappel already in 2014 (Microsoft’s last TechEd ever) as he took a stab at how Cloud Services are being named. I am taking a freedom to take something out of its context here, but the way David summarized it just nailed it “All the good names are taken, All the bad names are taken” ergo the AWS “Elastic Beanstalk”, yeah that’s the naming scheme for orchestration service they offer…
Elastic Beanstalk, Apache Cassandra aside, let’s compile example list of naming schemes/acronyms/protocols and comment how well they relate to the assumed actual use scenario
- Self-explanatory, conveys the use case “remote desktop” in naming scheme for Remote Desktop Protocol
- Not self-explanatory, assumes background knowledge of web standards, authentication and single-sign on concepts
- Not self-explanatory, but at least include one direct reference to the actual use case (Network, as what N stands in VPN)
It’s obvious that all naming schemes can’t be self-explanatory, but sometimes I feel there is active lack of even attempting to make them comprehensible.
Let’s take it step further, and introduce some more old & new acronyms
1. CASB (Cloud Access Security Broker)
» A system to monitor and enforce policies on traffic towards external services that might be considered as cloud services, but not limited to.
Alternative name suggestion: Active proxy
Vendors: Symantec, Oracle, Microsoft and Bitglass
2. BPOS (Business Productivity Online Suite) / Not security related, but good acronym for the sake of example…
» This was the Pre-Office 365 (or prehistoric) name for Office 365… I won’t even delve into details of it, let’s just summarize that nobody ever understood why it was chosen or used at all - Finally when it was named to Office 365 (which is a huge concept itself today) many confused it with some mysterious service running your whole set of Office desktop programs in a remote location
Alternative name: As said in the previous paragraph, BPOS turned into Office 365, which ended up being a good bet if you consider how successful Office 365 is as a service offering.
And Last, but not least
3. EMS (Enterprise Mobility + Security)
» A true “Avantgarde soup” of MDM, MAM, DLP, Antivirus, IDM, Azure AD, IAM, Reverse-Proxy, SSO, Monitoring of logins and admin actions, MFA, SSO and PC Management
» This the ultimate concentration of combined acronyms into single acronym (EMS) Some of the services itself are mind-blowingly great, but I guess the message might be hard to convey in an understandable manner
Alternative name: I don’t even dare to try, props to Microsoft for the attempt. Given the record number of acronyms and concepts combined into single purchasable service, I guess something worst could’ve come of it.
Given the context of this blog, I hope we succeed conveying a clear picture of Nixu MFA service with a bit of pre-context into exotic naming schemes.
(33:00 minutes video)