I hate to admit when I don’t know much about a subject, but the best way to learn is to say “I don’t know.” When it comes to identity, the amount I don’t know far exceeds what I do know. My entire history with identity is Active Directory. Never struggled with that thing. Make sure my Windows desktops/servers are connected to AD (check), setup some groups/users (check), assign groups to applications, folders, data (check), assign users to groups. Done and done. The first 15 years of my career my AD skills were more than enough to get me by; add in some group policy wizardry and a script or two and you got yourself a business. Sure, once in awhile I’d have to do some LDAP thing to solve a Linux or Mac issue, but I never dug deeper into this world. It was a set-and-forget type world.
Then this cloud/mobile thing happens. Applications changed, enterprises changed, and my entire industry changed. I witnessed this from afar because as this was gaining traction, I was over at Gartner getting smart on virtualization and protocols and wondering when the year of VDI would finally happen. In doing so, I all but ignored identity. This was dumb. Now I’m behind the curve (something I hate) and as I start learning about identity, I realize that every article I read on this subject isn’t written to my liking. I don't understand half of what these articles say, even when they are talking about things I know. As I was learning this stuff, I was making notes and I thought, wouldn’t this be a nice thing to share?—a guide to identity for people like me that kinda ignored it. It is to you, the IT guy/gal too busy to bother learning identity, that I dedicate this article.
Before I get into some story telling behind identity, I thought I’d start with identifying terms. While I group these like a typical list of definitions, I wrote them so they build off each other, and they’re designed to be read from top to bottom like any other article. So do me a favor and do that. I’ll try and keep you entertained while I go through this.
Identity: Every time you go to a website and create an account, what it's doing is creating an identity for you. It asks you some questions that help them confirm you are who you say you are, in as much as you = an email address or a phone number. Since where you work is a bit more important than that Reddit account you created under a false pseudonym, they do a bit more verification to make sure you are who you say you are. At Citrix I’m firstname.lastname@example.org. This is my identity (managed by Active Directory) and Citrix has confirmed it with my drivers license and Social Security number, as well as numerous other means. Using that ID, I access all kinds of resources inside of Citrix. The problem is I don’t just have this one identity, I have loads! Google, LinkedIn, Twitter, FedLoans, Cigna, E-Trade, Gartner, WSJ, SAP, etc, etc, etc. Seriously I pulled up an app I use to organize my identities and it was over a hundred long. I hope you’re reading this article because you understand this struggle and are looking to learn more about how you fix it. If that’s you, then great, I hope this can help.
Identity Federation: Hahahahahah. Yeah, we aren’t there yet, slow your roll. Let’s first discuss the 3 A’s of identity: Authentication, Authorization and Auditing.
Authentication: The process of confirming an identity. So you are you, but I don’t know you are you, and I won’t until you’ve been authenticated. Once you’ve been authenticated, I’ll trust that you are who you say you are, even if you aren’t, which is why we need to start talking about the different levels of authentication.
Pro Tip: When discussing authentication and authorization in the same sentence shorten everything to “auth” that way no one knows which one you are talking about but they’ll assume you know which one you are talking about, so you will always be right.
Single-factor Authentication: I’m only going to confirm you are you using a single form of authentication. Most commonly this is a username/password. Obviously this isn’t very secure because the identity provider could get hacked (remember LinkedIn/Yahoo) and now your username/password is blasted all over the Internet. So if I’m doing single-factor authentication to test if you are you, but “you” are some hacker that has your password, you aren’t really you, are you? Let’s keep this simple and consider your credit card: you swipe the card and pay for the thing. Sure you have to sign something, but that signature isn’t actually checked by anything, so there is really just one factor of authentication going on there.
Two-factor Authentication (2FA): Instead of relying on just that single factor, I’m going to add a second level of authentication to verify that you are you. Again, think of your credit card in a future utopia where every purchase requires you to enter your pin. Now to purchase something you need two factors: something you have (the card) and something you know (the pin). If you lose your credit card in this two factor world, there is a lot lower chance that it will be used illegally. Going back to the IT world, this typically means you are using some kind of pin: a number that is texted to you (not super safe btw), an application that gives you a pin (Symantec VIP), or some other second factor such as fingerprint, iris, stool samples... You get the idea.
Multi-factor authentication (MFA): You should get the idea by now what this means. I would argue that multi-factor would include two factor, but I feel this argument is the same one I get into with my wife about the difference between “a few” and “a couple”. (“A few” is > 2 in my opinion, and I’m right.) Anyway, most of the time people use the term MFA when they are talking about any number of factors (including cool analytics) to determine identity.
Continuous authentication: Someone at Citrix recently pitched an idea of using the virtual channel in ICA to see if the rate of typing matches the historical rate of typing for this a specific user. After all, at a certain point in time our typing skills get pretty consistent. Thus, if out of the blue you can type 140 words per second, maybe you aren’t you. I really like concepts like this because they don’t force the user to do yet another thing, instead they analyse the user's behavior patterns to determine their identity. (Eventually we’ll get to thought recognition and invite 1984 into our worlds one step at a time.)
It’s also kinda cool to think that authentication shouldn’t remain as simple as “enter the front door and we trust you once you are in the house.” Continuous authentication means the system would monitor you while you are in the house, see what you are doing, and throw up some red flags when you are doing things that don’t seem like the typical “you”. There are a plethora of ways to use analytics to drive a more secure and better user experience in IT. Mark my words, analytics will make a massive breakthrough in the near future. Ten years from now we may not even use passwords anymore, and wouldn’t that be something?
Authorization: So above we talked about how auth determines if you are you. Once we have determined that you are who you say you are, we then look at your auth to determine what stuff you have access to. Do you see how annoying it is when you shorten everything to “auth”!? Anyway, authorization is the list of stuff you have been granted access to use (i.e., you are authorized). That could be applications, data, devices, your wife's car... you get the idea. This world gets a lot more interesting when you start talking about Access Control.
Access Control: Just because you are an administrator (I’ve authenticated you) and you have been authorized to control everything in my datacenter, doesn’t mean I’m cool with you doing this after hours, or out of the building or country. This is where Access Control steps in and starts creating conditions where and when I am okay with you having authorization to do things, and when I am not okay with it.
Role Based Access Control (RBAC): Even though this isn’t really a part of my story flow, I just mentioned Access Control so my mind jumped to RBAC. This is just a form of access control based on job title. Which means when you hire a person of a certain job title they probably are going to have access to the same types of things of a person with a similar title. That’s RBAC, and there are a lot of different access control models other than RBAC, but that’s the one I hear the most so I figured I’d share it. Now back to the flow.
Auditing: The final of the 3 A’s of Identity and Access Management. Auditing, as its name implies, keeps track of all the changes that were made. So when a helpdesk employee accidentally deletes all the VMs in the datacenter, there will be a great log trail leading back to the person who authorized the them to do that kind of action. In reviewing this article, my security smarty pants colleague (Kurt Roemer) pointed out that ISC2 calls this “Accounting”, and that there is a bit of a debate on what the third A is. I don’t know what ISC2 is and I refuse to Google it because my ISP can now track my every move (or Kurt can… not sure which is worse). Regardless if its Auditing or Accounting, it all pretty much means the same thing—this is the tracking portion of the 3 A’s.
Identity and Access Management (IAM or IdM): So if I were to quiz you right now on the 3 A’s of Identity are you’d pass right? Auth, auth and au...diting. You got it! I’ll teach you a little trick now, when you lump all of those together you get your next cool acronym on your way to being a identity wizard: IAM. Simply put (and I’m lifting this directly from Wikipedia), IAM “enables the right individuals to access the right resources at the right times for the right reasons.” (My college professors would be so proud of my blatant plagiarism.)
The reason I started to dig into all of this is that I wanted to fully understand some concepts I hear talked about on a daily basis, but I lacked knowledge of at a technical level. Sure at a marketing level I could discuss them, but I lose self-respect if I know in my heart that I don’t fully understand why something works; it's just how I’m wired. I need to understand what is happening behind the scenes, how does SSO work, why doesn’t it work on some things. When you start asking the right questions you start to discover an entire world of things to ask more questions about, but I had to draw the line in the sand or I’d end up talking about protocols, JSON and APIs. So to keep things dialed in for this article I’m going to focus on SAML because that’s what’s important to me at the moment. However, I’d encourage you to read up on OpenID Connect and OAuth, as SAML is just the primer course to the wide word of identity management. (I’d highly recommend Modern Identity and APIs: Mobile, OpenID Connect, OAuth, JSON and REST. It’s behind a Gartner paywall, but it’s an outstanding document that goes into a lot more depth on identity.)
Security Assertion Markup Language (SAML): I’ve mentioned SAML (when spoken it sounds like Sam-ul) but I forgot to tell you what SAML is, sorry. SAML is a data format that was designed to send authorization and authentication information between Service Providers and Identity Providers securely. It does this by sending something called an identity assertion. (I’ve also heard people call this assertion a token, but I’m not sure that’s technically correct.)
That definition is really hard to understand because it’s loaded with terms you don’t know yet. So let's break them down:
Identity Provider (IDP): Think Active Directory. What is the thing that stores all of the identities? That’s your IDP. In the enterprise world, Microsoft has been fairly dominant in the IDP market. 90% of the time they are the IDP all the time, or something like that.
Microsoft domination has come under threat lately from cloud-based IDPs (like Google/Facebook). You know how some websites don’t require you to create an account, and instead they give you a blue option to use your Facebook account or a red option to use your Google account? I don't’ know about you, but I LOVE it when websites do this. It's one less credential I need to remember, it's one less site that when it gets hacked causes me all kinds of issues, and instead I get a central location to control access to these other sites. This is why cloud based IDPs have become mainstream. They increase security and create a better user experience at the same time.
Service Provider (SP): Pretty much any website, application, or thing you use that you would typically log into.
Side Note: The service provider isn’t worried about how you authenticated with the IDP, that’s the IDP’s job. A relationship between the IDP and the service has already been established, so the service assumes that if it gets an assertion from the IDP, then you are good to go.
Assertion: A package of information containing the authentication statement (this shows that the user authenticated with the IDP), attribute statement (elements that are essential to validating trust), and the authorization decision statement (this is basically saying that the person has access to the service or not). You should understand all of what's inside the assertion because we spoke about this earlier in this article.
Identity Federation: Okay, seriously this time, you know the basics, so this should be easy enough to grasp. This is when two sources agree they want to share an identity. Say when Zillow wants to allow you to use your Facebook ID to log into its website, this connection between the IDP (Facebook) and the SP (Zillow) is called ID federation. Think of this as the back end work an administrator has to do in order to create a great user experience.
Words from a true Security Guru: After reviewing this post, Kurt Roemer (who’s been a Chief Security Officer in numerous jobs and is all around smarter than me in this area) didn’t like my definition of ID federation, so he gave me this:
“Federation is a connector—an agreement between directory owners on how to connect their directories. This is typically done with one AD domain needing to include users/groups from another AD domain. For example, a contractor who has access to a file can validate their employees—and you as the contract owner don’t need to manage all of the contracting employees, just the connector between directories on what you trust the contractor to manage…”
Who wrote the definition better? I say I did and it's my article, so who’s gonna correct me.
Single Sign-On (SSO): That great user experience that we just created by federating the identities manifests itself by enabling users to log in once, with one credential, and then use that credential to automatically log into multiple SPs. This “log in once and never again” is affectionately named single sign-on.
Geeky Details: Federating identities to create an SSO solution doesn’t mean that every time a user goes to use another resource (think website) that the IDP has stored the user's credentials. NO! Think how insecure that would be—all of a sudden every website you visit that has done all this federation work would be getting your credentials. Be grateful this isn’t how this works—otherwise, your credentials would be spread all over the internet. No. No. No. What actually happens is that the user authenticates to the IDP once—i.e., that’s the username/password and any MFA stuff you may have set up at the IDP. After that, the IDP sends just an assertion to each resource provider on an as needed basis.
SAML in action
Now that you know each of the terms, let’s discuss them in action. There are three things in play:
- The person that wants to use a service. (User)
- The service provider has the service the user wants to use. (SP)
- The IDP that knows the person and has a relationship with the service provider. (IDP)
With SAML, instead of every application (or service provider) storing your authentication and authorization information locally (which is where we end up having a lot of usernames and passwords), applications that support SAML trust a third-party IDP to store your identity, instead of creating their own. This means that when you attempt to use a service, instead of asking the you to authenticate, the service is going to talk to the IDP and get an assertion from it. So long as the IDP says you are authorized to use the service (and you have authenticated into the IDP at some point in the past) the service/application will let you use it. This is all seamless to the user. If the user hasn’t authenticated to the IDP yet, then it would simply ask you to log in, however, once you’ve authenticated to the IDP, any future SPs you want to use won’t require a username and password—instead, they will get the assertion from the IDP. Easy peasy!
So that’s it, that wasn’t so bad. At this point in time you should have a pretty good idea of high level identity terms, and you should be able to apply those to form an understanding of how SAML works. I probably should mention that the IDP can be federated to any number of service providers—after all, what good would it be if it only worked with one app? As I said earlier, there is a ton more to learn on this subject, but most SaaS apps these days support SAML and that’s what I set out to learn about.
I hope my learning has helped you, but if not, there are plenty of other resources out there. If you haven’t dug into this stuff yet let, me encourage you to get an understanding now. This is how apps work today, and you need to know how to secure them and how to make sure your users love their IT experience. If not, they will go around you and that makes your security situation much worse. Figure it out! Get in the game, create better user experiences, make IT an asset to the way people want to work, and increase productivity. Remember, if you work in IT you are in a services business and we need to make the best experience possible for each and every one of our clients (our users/co-workers). SSO should be table stakes for any IT department these days, let’s get to it.
Special thanks to Kurt Roemer and Chuck Hirstius for their help in answering numerous questions I had as I wrote this thing.