It’s time to seriously consider Identity as a Service (IDaaS) solutions (such as Azure AD B2C) for user authentication

If you watched the news in 2016 alone it would be pretty clear that many organizations are doing a very poor job in protecting the user credentials that are in their care. Even more, when organizations somehow lose credentials for hundreds of millions of users (looking at you Yahoo) and users are not fully up-in-arms about it we know we’re in a bad place – the place where users are so used to hearing bad news related to security or privacy that they almost don’t care anymore.

We can do better than this. The goal of this post is to present arguments on why authentication mechanisms in many organizations are failing and show why Identity as a Service (IDaaS) solutions such as Azure Active Directory B2C (business-to-consumer) are the future.

b2c-auth-options

According to a Gartner report from June 2016 (see link below in the resources section) by 2020, 40% of identity and access management (IAM) purchases will use the identity and access management as a service (IDaaS) delivery model — up from less than 20% in 2016. If you’re planning to build any new consumer facing applications in the near future or if the security of your existing application credentials is keeping you up at night then you should seriously start to look at IDaaS solutions.

Challenges with traditional consumer identity and access management systems

Security & privacy risks

  • The username/password list is a target for attackers – attackers look for easy targets knowing consumers often reuse login credentials across accounts (the credentials list is often more important than the data it protects)
  • Developers often don’t really understand well how to properly secure passwords with custom solutions
  • Attacks are getting more sophisticated / threats are constantly evolving

High TCO (total cost of ownership)

  • Development time & costs – lots of code to write for identity management functions (sign-up/sign-in, email verification, password resets, MFA, user experience UI/UX)
  • Software licensing, maintenance and upgrade costs (when using off-the-shelf software for identity management features)
  • Identity management functionality is a moving target – for example in the Microsoft .NET world built-in identity management approaches change every 1-2 years (ASP.NET Membership, ASP.NET Identity) leaving behind fragmented applications that are hard to maintain

Scalability and availability challenges

  • Consumer traffic is highly seasonal
  • Organizations are forced to provision for peak capacity
  • With millions of users this can be very costly

What is Identity as a Service (IDaaS) and where does it fit in?

  • Cloud-based service that provides a set of identity and access management functions
  • An authentication infrastructure that is built, hosted and managed by a third-party service provider
  • This is in contrast to traditional identity and access management (IAM) solutions that are typically completely on-premises and delivered via bundled software and/or hardware means
  • According to Gartner, IDaaS functionality includes:
    • Identity governance and administration (“IGA”) — this includes the ability to provision identities held by the service to target applications
    • Access — this includes user authentication, single sign-on (SSO), and authorization enforcement
    • Intelligence — this includes logging events and providing reporting that can answer questions such as “who accessed what, and when?”

IDaaS sounds interesting … why consider Azure Active Directory B2C?

Yes – there are quite a few IDaaS solution providers out there – so why am I advocating for Azure AD B2C? To answer that I’ll just point to a recent June 2016 study (see link below) where Gartner analyzed the IDaaS space:

Gartner 2016 Magic Quadrant for Identity and Access Management as a Service

Microsoft with its IDaaS offerings is currently in the leader quadrant. The success of its IDaaS solution (Azure Active Directory) is very closely tied to the success and growth of Microsoft Azure – its cloud solution – and by all indications it has a strong future ahead of it.

What exactly is Azure Active Directory B2C?

  • Cloud identity service with support for social accounts and app-specific (local) accounts
  • For enterprises and ISVs building consumer facing web, mobile & native apps
  • Builds on Azure Active Directory – a global identity service serving hundreds of millions of users and billions of sign-ins per day (same directory system used by Microsoft online properties – Office 365, XBox Live and so on)
  • Worldwide, highly-available, geo-redundant service – globally distributed directory across all of Microsoft Azure’s datacenters

How is it better than a custom authentication solution?

  • Easy to integrate consumer self-service capabilities (sign-up, password resets)
  • Site owner controls user experience (custom html & css for sign-in/sign-up)
  • Enterprise-grade security with continuously evolving anomalous activity, anti-fraud and account compromise detection systems (offload security to the real domain experts)
  • Benefits of security-at-scale – uses machine learning to watch billions of authentications per day across the entire Azure AD ecosystem and detect unusual behavior
  • Superior economics compared to on-premises – pay-as-you-go pricing + free tier
  • Based on open protocols and open standards – OAuth 2.0, OpenID Connect
  • Uses open source libraries for .NET, Node.js, iOS, Android and others / REST-based Graph API for management
  • Better and faster development experience for authentication / easy to integrate with existing sites wherever they’re running from (not just those in Azure)
  • Ability to easily integrate social logins if needed (Facebook, Google and such)
  • Support for MFA (multi-factor authentication)
  • Authentication database is separate from the application data / easier to enable SSO (single sign on) later across other apps in the enterprise (unified view of the consumer across apps)

Sounds interesting – tell me more: who is using Azure AD B2C?

  • Azure AD B2C is a natural choice for consumer facing apps hosted on Azure (but certainly not only for those)
  • Some stats (from Microsoft presentations as recent as September 2016) on Microsoft Azure AD (the technology that B2C is built on)
    • 90% of Fortune 500 companies use Microsoft Cloud
    • More than 10 million Azure AD directories
    • More than 750 million user accounts in Azure AD
    • More than 110K third-party applications that use Azure AD each month
    • More than 1.3 billion authentications every day with Azure AD
  • The state of Indiana used Azure AD B2C for user authentication in order to integrate various features into a single citizen portal
  • Real Madrid (one of the most popular soccer clubs on the planet) uses Azure AD B2C to offer authentication services for their mobile app used by more than 450 million fans (Microsoft case study)

What about security for all this authentication data in the cloud?

To answer the topic of security for authentication data when IDaaS solutions are used I’ll just include a quote from the Gartner report I mentioned above – I totally agree with their assessment:

No security is perfect. Ultimately, prospective customers must decide whether vendors’ stated control sets are sufficient for their needs. IDaaS vendors give significant attention to ensure the security of their platforms. Based on the number of enterprise security breaches that have been made public, and the lack of any such breaches for IDaaS providers, Gartner believes that IDaaS vendors are more likely to provide better security for IAM services than their customers could provide for themselves.

Additional Resources

List of technology podcasts

I’m a full believer in the term “Automobile University” that was coined by the well-known motivational speaker Zig Ziglar – the idea being that time spent in traffic can and should be used to educate oneself on a variety of subjects. As such, I have quite a few technology / IT podcasts that I subscribe to and I make sure that my audio player always has plenty of interesting episodes available in the queue.

I already shared the list below with plenty of friends and co-workers who know that I listen to a variety of podcasts so I figured I should probably just create a blog post with this information for future reference.

At the time of this post all podcasts mentioned below appear to still be active – kudos and many thanks to all these authors who keep creating solid technical content for all of us to enjoy.

In the list below I link to the actual podcast sites. If you want to actually subscribe to them you should be able to find them in the iTunes store or wherever else you grab your podcasts from. If you know of any other ones in the various categories listed below please add them in the comments.

Cloud Computing

Big Data

Databases (SQL Server)

Development (.NET, Javascript)

Infrastructure, Networking, Enterprise Tech

Security

I should also mention the amazing list of shows / podcasts from the TWiT network. Leo Laporte and his amazing crew create some awesome content – way faster than I can possibly consume it. You’ll probably find some interesting topics there as well.

Time to say goodbye to usernames and passwords for website authentication

We have to admit that our current model of using usernames and passwords for website authentication is utterly broken. It may have been fine back in the days of mainframes when users would have one account to remember but it just does not scale (safely at least) in the current day when the average user probably has tens (if not hundreds) of usernames and passwords to remember.

What do most users do in the face of the ever increasing number of websites that require authentication? They start reusing information – in particular passwords. We should all know that this is a bad idea. The best practice in this area is to have separate and strong passwords for each website account used … but how many people actually do that?

Before we put all the blame on users let’s not forget the websites themselves which are not doing a good job at all protecting all this authentication data. The best practice there would be to properly hash a user’s password in a way that even brute force attacks against that data would not be very successful … but we know that’s not happening. It seems that not a month goes by without some news story informing us that large numbers of user accounts from some website just got dumped online … and passwords were either poorly hashed or not hashed at all (simply stored in plaintext).

Other authentication models exist where some third-party is used to consolidate user accounts and allow users to logon to websites using credentials from that third-party (think OpenID, Facebook, Twitter, Google and so on). The problem with all these is the third-party: can it be trusted? will it protect our information and privacy? do we really want some corporate third-party knowing all the sites we visit simply because those sites rely on its authentication methods?

What we need is a modern authentication system that’s cryptographically secure, easy to use and preferably two-party (involving just the user and the website the user wants to visit).

Enter SQRL – Secure Quick Reliable Login (also see the Wikipedia page). The protocol typically uses a QR code, which provides authentication, where a user identifies anonymously rather than providing a user ID and password. SQRL is the brainchild of Steve Gibson – the host of the long-running and well-respected Security Now podcast. Steve has a lot of information about it at this location – https://www.grc.com/sqrl/sqrl.htm. He also recently did a presentation on SQRL at the DigiCert Security Summit 2014:

We need to start moving in this direction for website authentication because what we have right now is simply not working.

HTTPS certificate verification problem in Python 2.7.9

Over the last few days I was working through some AWS security best practices as outlined in a video presentation from AWS re:Invent 2013 called “Intrusion Detection in the Cloud (SEC402)” (video linkPDF presentation link).

One of the interesting ideas that the authors were promoting was this particular Python script (script linkJSON template for IAM policy) which would use the AWS Python SDK to obtain textual descriptions of various critical security settings that would be part of an AWS account (such as IAM users, groups and policies, S3 bucket policies, EC2 security groups and so on). These settings could all be exported and saved in a text file, the script could be scheduled to run at various intervals and alerts could be raised each time differences in the file would be detected.

I’m currently in the middle of setting up the AWS environment for a client project so I liked the idea of having a script such as the one mentioned above which I could use to script various critical settings and monitor how they change over time. Besides … Python is not really a language that I use often (though I do plan to become more familiar with it) so I welcomed the chance to try something new – how hard could it really be? 😉

I initially proceeded to download and install the latest version of Python – 3.4.2. It didn’t take too long to realize that the script authors actually wrote it for the Python 2.x branch. I was getting all sorts of errors trying to run it under 3.4.2 – as soon as I managed to get one of them fixed, another one came up. I didn’t really care much which version of Python I’d use so since 3.4.2 was giving me enough trouble I decided to switch to the 2.x branch and installed 2.7.9.

Success … or so it seemed. The script finally started running until half-way through its execution it died with this strange looking error while trying to connect to some AWS API endpoint:

ERROR: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

I was pretty sure that Python was not happy about some discrepancy it found in a HTTPS certificate that it received while trying to make a HTTPS call to AWS. The problem was that the HTTPS site it was reaching out to was controlled by AWS and used deep in the AWS Python SDK code – not a resource for which I could do anything about the configuration of its HTTPS certificate.

So what exactly was Python complaining about? After some research I came across this link:

https://www.python.org/dev/peps/pep-0476/

It appears that a fairly recent change was made in the 2.7.x branch in regards to the default behavior for certificate verification. I ended up using the following monkey patch to globally disable verification for all HTTPS calls made by the script:

import ssl

ssl._create_default_https_context = ssl._create_unverified_context

The script finally ran successfully to the end and I had my scripted security settings. All in all it was an interesting first adventure in the land of Python.