Introduction to the Nixu Multifactor Authentication Service

Joosua Santasalo

Joosua Santasalo

Senior Consultant, Digital Identity

May 9, 2018 at 13:00


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 Multifactor 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:

NixuMFA

Is the naming scheme self-explanatory?

I’d dare to say yes. It’s based on the premise that to authenticate into service, the following factors must be satisfied
1.    First factor: Username / Password (Provide something you know to the service)
» In the recent light of events, it’s not completely farfetched to assume, that somebody else also is privy to this information, thus the first factor is not something you should assume sacred
2.    Second factor: Something you only have.
» For example, an approval request from a mobile application, to verify you are performing the first factor, and not somebody else

 

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.

Nixu Multifactor Authentication

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?

Nixu MFA Supported Services


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…

Examples

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
   RDP
   -    Self-explanatory, conveys the use case “remote desktop” in naming scheme for Remote Desktop Protocol

   SAML
   -    Not self-explanatory, assumes background knowledge of web standards, authentication and single-sign on concepts

   VPN
   -    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.

Ending words
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.

References
https://channel9.msdn.com/Events/TechEd/Europe/2014/CDP-B211

(33:00 minutes video)

 

Related blogs