Authentication and Authorization
My current project at TeamViewer has provided a lot of opportunity to learn about security, authentication and authorization protocols and standards.
Fundamentals of Authentication and Authorization
TeamViewer being a product that allows remote access to devices, it is imperative for organizations to set right access mechanisms to prevent unauthorized access. In short, we want to be able to authenticate and authorize our users. Since I was thrown into the deep end of the pool with this project, I had to build my foundational knowledge.
Authentication means verifying that someone is indeed who they claim to be. Authorization means deciding which resources a certain user should be able to access, and what they should be allowed to do with those resources.
The three most common web standards are:
- SAML (provides both authentication and authorization)
- OpenID (authentication)
- OAuth2 (authorization)
Other non-web standards are:
SAML, OAuth, and Open ID are all federated identity services, which means that they can provide authentication across a range of different identity management systems.
SAML stands for Security Assertion Markup Language. It’s an open standard that provides both authentication and authorization. There are three actors in SAML:
- User: End user trying to access a resource.
- Service Provider: the web server that the principal is trying to access.
- Identity Provider: The server that holds the user’s identities and credentials.
What is the workflow?
- User has an account at the Identity Provider (IdP).
- IdP and Service Provider(SP) are related because they want to federate identities.
- User tries to use a particular application — for eg, a sales manager want to use the CRM
- When that happens, the federated identity software running at IdP validates the user’s identity and authenticates him.
- It then constructs specially formatted message containing information about that user, which it then communicates to federated identity software at the SP end.
- That software at the SP then determines that the message has come from a known identity provider. The response from IdP to SP is called an assertion, in SAML (similar to a token for OpenID or OAuth2). his assertion can contain statements about authentication, authorization, and/or attributes (specific information about a user, such as email or phone number).
- It then creates a session for that specific user and allows the user to get direct access to that application.
OpenID is an open standard for authentication, promoted by the non-profit OpenID Foundation. As of March 2016, there are over a billion OpenID-enabled accounts on the internet, and organizations such as Google, WordPress, Yahoo, and PayPal use OpenId to authenticate users.
A user must obtain an OpenID account through an OpenID identity provider (for example, Google). The user will then use that account to sign into any website (the relying party) that accepts OpenID authentication (think YouTube or another site that accepts a Google account as a login). The OpenID standard provides a framework for the communication that must take place between the identity provider and the relying party.
On a website, the exchange looks like this:
By contrast, OAuth2 is an open standard for authorization. OAuth2 is also the basis for OpenID Connect, which provides OpenID (authentication) on top of OAuth2 (authorization) for a more complete security solution.
OAuth2 provides secure delegated access, meaning that an application, called a client, can take actions or access resources on a resource server on the behalf of a user, without the user sharing their credentials with the application. OAuth2 does this by allowing tokens to be issued by an identity provider to these third-party applications, with the approval of the user. The client then uses the token to access the resource server on behalf of the user.
Yet Twitter’s OAuth guide says that OAuth2 is an authentication standard. So what gives? As it turns out, authorization can be used as a form of pseudo-authentication.
Online, an OAuth2 use case might look like this: Alice signs up for a new account at NewApp and is offered the option to see which of her friends already use NewApp so she can connect with them. There’s a button labeled “import contacts from Facebook.” Alice clicks that button, and she is redirected to Facebook to log in. Alice successfully logs in and is asked if she wants to share her Facebook friend list with NewApp. She clicks yes, and is forwarded back to NewApp along with a token. NewApp now has permission (with the token) to access Alice’s friend list, without her sharing her credentials directly with NewApp. This eliminates the risk of NewApp logging into Facebook on Alice’s behalf and doing things she wouldn’t want (posting status updates, changing her password, etc.).
Kerberos is quite interesting to understand because this authentication works on the basis of tickets to allow allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.
Kerberos unlike SAML is not used for authorization. For authorization, the application server relies on Active Directory (or some other directory system), accessed via Kerberos. Ticket-based security protocol means that users retrieve a ticket/token from their network server, and that ticket is then passed to a network resource that they want to access. That resource needs to operate within a certain realm. A “realm” in Kerberos terms is equivalent to a domain in Windows. The realm name is, by convention, the DNS domain name but in upper case letters. As an example, “mydomain.com” is the DNS domain name, while “MYDOMAIN.COM” is the realm name.
- Active Directory provides both Kerberos and LDAP services together in the same package. While Kerberos provides authentication, LDAP provides authorization.
Disadvantage: Kerberos requires user accounts, user clients and the services on the server to all have a trusted relationship to the Kerberos token server (All must be in the same Kerberos domain or in domains that have a trust relationship between each other). Kerberos cannot be used in scenarios where users want to connect to services from unknown/untrusted clients as in a typical Internet or cloud computer scenario, where the authentication provider typically does not have knowledge about the users client system.
1. SAML is used over the Internet. If you have a web application you would use SAML. SAML is just a standard data format for exchanging authentication data securely using XML Schema, XML signature, XML encryption and SOAP. You would typically use it for a web SSO (single sign on). For example Hue, Cloudera Manager UI etc.
2. Kerberos is used in an enterprise LAN typically. Kerberos requires that the user it is authenticating is in the kerberos domain. It supports strong authentication in open, distributed networks. Kerberos provides not only single sign-on to allow users to access a variety of systems and services without needing to enter their user ID and password repeatedly,but it also provides a robust general framework for secure authentication in open distributed systems.
Our team is still deciding which of the above four protocols to implement. Once we are decided, I will update the blog post.