Respect my security – A primer on Datazen user authentication

Almost every customer conversation I’ve had around Microsoft Business Intelligence the past few years has had part of it devoted to a conversation around security.  This isn’t my favorite topic to cover off on.  It’s a little like going to the dentist – that isn’t my favorite thing to do either (even though I truly like my dentist). 

But security (and visiting the dentist) are still very important, so I want to use today’s post to spend some time explaining what Datazen can (and can’t) do when it comes to each of the authentication options it supports  –

Datazen Authentication (default) – ah, good ol’ Datazen Authentication.  The preferred authentication option for demo server builds everywhere.  This is the easiest option to setup, and easiest for everyone to understand.  You create a user on the server, they get a link to reset their password, and all the credentials are assigned (and stored) on the Datazen server.

When should you use this – if you read the Security Best Practices in the Datazen documentation, your answer would be never.  But there are some legitimate reasons where it probably makes sense for you to use this authentication scheme –

– It’s a test/development server or a quick proof of concept.
– You’re looking for the simplest setup possible to start using Datazen.  You can invite users just by using their e-mail address.
– You have a scenario where you are servicing external users who wouldn’t be in a domain to leverage Active Directory.
– You’re a long haired hippie who likes to let their hair down and live on the wild side, not worried that the Datazen server could be used as an attack vector.

Far out man – classic authentication!

Okay, forget that last point.

Windows Authentication –

This option is the one that most people will probably end up leveraging when it comes to Datazen.  It’s also the one that generates the most confusion – let’s see if I can’t clear that up a bit.

Generally, people assume when they setup users in this scenario, the Datazen server is communicating with the domain controller during that process to validate them.  It doesn’t – you could create bozotheclown@microsoft.com as the username, and Datazen will show a success message when you finish user creation. 

Wait a minute . . .

Datazen doesn’t check the users in the domain until someone actually attempts to login as that user – it does a check against the users in the domain and makes sure it matches.  If it can’t find the user in both the Datazen server AND the domain, it’ll fail.  This is why you can’t leverage Active Directory user groups – Datazen wants to find a 1:1 match.

So the time saving benefit around user setup that you’re expecting to get using a Windows authentication vs. Datazen authentication doesn’t exist from an admin perspective.  (Saying this was an oft-requested feature enhancement people are looking for is an understatement.)  It also doesn’t change the way the users have to authenticate when they are hitting the service from an app – the first time they connect to a Datazen server, they still have to enter a username/password.  It’ll be their network password, sure, but it’s the same experience as Datazen authentication for them.

The only place a single sign-on experience can be enabled for them is in a web browser.  This is true for both WinAD AND for ADFS – the app experience will ALWAYS require entering a username and password the first time you connect to a Datazen server (at least for now, anyways).

So why use Windows Authentication?
– No passwords stored on the Datazen server
– Looking to enable Analysis Services row-level security
– You’re integrating Datazen into a SharePoint site or custom app, and want an improved user experience when they use the dashboards in that context (no additional login page).
– You don’t want IT to yell at you, or you are IT and Windows Authentication is the standard security option for this type of application.

ADFS (Active Directory Federation Service)

This is where the dentist drill is at full-bore for me. Setting up ADFS is not for the faint of heart, and I’m not going into the weeds on that or in any other post on this blog (ever). If you want to see the process from start to finish, this blog post does that wonderfully.

”Oh, please don’t worry. I’m not going into that cavity.”

However, this is the most secure option if you have ADFS already setup in your organization. It will ensure no user credentials are stored on the server, but you still need to go through the user setup on the Datazen server. It also offers some additional options for the security team, like using a smart card to login to the Datazen server.

However, and without getting into the sordid details of why, Single Sign-On doesn’t work with that type of login security scenario. Should it work? Yes, it should, but it doesn’t. It’s something that will be addressed by the team as we move forward with the product.

External authentication

This option works in the opposite manner of Windows Authentication – a user’s username and password is checked first against an external source, then looks for a match on the username stored in the Datazen server.  You have to be careful when using this method because –

– You’re assuming the username and password are checked.  If that isn’t setup properly, it’s a massive security hole you’ve potentially enabled.
– The mobile apps don’t work with it.  It was designed for web-only scenarios.
– You can’t make changes to the server when you are running in external authentication.  You need to switch to another authentication method, make your changes, and then switch it back.

I’ve not run into a customer yet using this setup, so I’m curious to hear from folks on how they’re using it in their organizations.

Whew – now that our visit to the dentist is over, hopefully you have some more clarity around the different user authentication options in the product.  The team is fully aware of the limitations I’ve called out in this post, and we’re committed to improving these options as the product is fully integrated into the Microsoft platform.