Estudio de soluciones AAI, definición de escenarios de prácticas y análisis de seguridad

Abstract

Extended Abstract The use of digital services has experienced a massive increment in recent years. Nowadays, any citizen has an account with big service providers like Google, Amazon, Microsoft, etc. This has led to the continuous generation of private and identity data that is being stored and managed by the services people and businesses use daily. From profiles on social networks to banking accounts, digital identity has become even more prevalent and valuable. Before this success of online services, the use cases for identity management were as simple as an login form with a username and a password. However, as years passed, other cases began to emerge, such as SSO (Single Sign On), federated authentication, login from smartphones and delegated authentication, among others. In this context, protocols for AAI (Authentication and Authorization Infrastructure) began to be developed to meet those use case demands. To fulfill these needs, protocols such as SAML (Security Assertion Markup Language), OAuth 2.0, and OIDC (OpenID Connect) were created. One one hand, this AAI are vital to some service provider because, concepts like federated authentication, which is an agreement between two entities with different domains where they establish a trusted relationship for the exchange of identity information, allow them to partially alleviate the cost associated with storing user identities and some legal responsibilities associated with it. As a result, these service providers can focus their efforts on delivering quality services to all users. On the other hand, identity provider organizations responsible for the storage and registration of user credentials and identities can focus on enhancing the security level for the proper functioning of their system. In addition to this, these identity providers also gain a dominant position on the Internet, becoming significant companies that other organizations turn to for establishing identity federations. On the side of end-users, these concepts help them avoid the burden of having to remember different credentials for each service they want to use. This results in the user potentially only having to remember one password to authenticate with the identity provider, promoting the use of more secure access credentials. Another benefit for the user is the convenience provided by SSO. This concept states that a user, for various accesses to one or different services, only needs to enter their login credentials once. xiv This saves time for the user, which can create a positive experience and become a key factor in deciding whether to use one service over another. However, a clear disadvantage of these centralized authorization and authentication systems is precisely their centralization. If an attacker manages to compromise the security of an identity provider or intercept and decrypt certain messages related to user identity, it can cause significant harm to the confidentiality of information associated with user identities. Considering that these identity providers (such as Google, Facebook, Twitter, etc.) often have massive user bases, an error in any of these protocols can compromise the identities of billions of users. With this context, this Degree’s thesis presents scenarios developed with Docker for testing and security analysis of some of the most notable security considerations of the SAML, OAuth 2.0, and OIDC protocols. These scenarios can serve as a ground for establishing teaching practices that facilitate the analysis and configuration of these solutions at an academic level. To commence this thesis, an state-of-art research was performed to introduce the three technologies in question. The first of these protocols, SAML, is one of the most widely adopted solutions for SSO and identity federation globally. Its main advantage is its support for both authentication and authorization, and the use of signed XML payloads, called Assertions, to establish an interoperable protocol for identity federations and SSO. This protocol introduces two actors apart from the user: the Identity Provider (IdP), responsible for registering and authenticating users, and the Service Provider (SP), which offers a service and relies on the IdP to authenticate users. To achieve these objectives, SAML supports two main flows, depending on where the flow is initiated: SP-initiated flow or IdP-initiated flow. While both flows are widely adopted, the explanation of how this protocol work is focused on the SP-initiated flow as it is more commonly used. With this flow in mind, the main messages of the flow and the main components of an Assertion were explained to provide a general understanding of how SAML achieve this secure interdomain exchange of identity information. The second protocol, OAuth 2.0, is a widely implemented protocol dedicated to delegated authorization, which involves granting permissions to a third-party application to perform certain actions on a user’s protected resources. It is worth noting that OAuth 2.0 uses JSON for information exchange, making it lighter than SAML. However, despite many services using OAuth 2.0 for years to authenticate, it is not designed to provide authentication functions. It is primarily designed for authorization purposes only. Furthermore, OAuth 2.0 introduces three actors apart from the user: the OAuth client, which is the third-party app that want to make use of user’s resources; the Authorization Server (AS), which is in charge of providing the client with tokens when the user have authorized it; and the Resource Server (RS) that serves the user’s xv resources. In addition, OAuth 2.0 can be used with different flows depending on the type of client that it is going to be implemented. These flows include the Authorization Code Grant, primarily used by clients that can act as intermediaries between the user and the AS, typically web servers; Implicit Grant, suitable for clients implemented within a browser using JavaScript; Client Credentials Grant, utilized by clients that only require access to their own resources; and Resource Owner Grant, which is less commonly used due to the need for user credentials to obtain the token. Since Authorization Code Grant is the most common flow, we use it as basis for providing a general description of protocol messages and tokens such as the Authorization Code and Access Code. This will help us explain how the OAuth 2.0 protocol enables the use of redirections and tokens to provide a natural way to allow and delegate authorization to a third-party application access certain protected resources on behalf of a user. The last protocol, OIDC, addresses the authentication limitation of OAuth 2.0. OIDC is a protocol that builds on top of OAuth 2.0 to provide an authentication layer. This protocol is necessary because with OAuth 2.0 a user authenticates in way that is unknown to the protocol. OAuth 2.0 alone does not provide a way to identify the authenticated user, understand how the authentication was performed, or determine the validity period of the authentication. In its state of art section, we explain how the AS, now referred to as OpenID Provider (OP), can generate an ID Token. This ID Token serves the purpose of transporting information about the authentication process to OAuth clients, which are now referred to as Relaying Parties (RP). In addition, we explain how RPs can verify the authenticity of the ID Token using the digital signatures present within it. With these three protocols in mind, the first step taken was to build and deploy two environments using Docker containers to create a platform for testing and analyzing the studied protocols. We chose to utilize Docker because it not only provides isolation but also offers enhanced portability. Docker allows us to encapsulate the necessary components and dependencies into a few files, making it easier to transfer the entire environment to another machine. Unlike other alternatives like VirtualBox, there is no need to move the entire system. Additionally, the deployment process with Docker is much more convenient, allowing a fast deployment and configuration of the testing environments. The first environment was built for SAML. In this environment, the simpleSAMLphp application and Apache were used to deploy three SAML components within Docker containers. Firstly, an IdP was configured to provide login capabilities. Test user credentials were added to test the Assertions generated once users’ logins were completed. Secondly, a first SP was developed to provide a test application that utilizes the configured IdP and its identities to consume the generated Assertions, ensuring the correct authentication of the test users. Thirdly, a second SP, which is almost identical to the first one, was developed to test the SSO across the different SPs. xvi In addition to the SAML components, a user container was defined to provide easy access to this environment. This was achieved by including a noVNC container with Ubuntu Desktop and network analysis tools within the defined Docker internal network, where the other elements communicate. With this container, a tester can access the desktop in their chosen browser using noVNC. Once the tester is working within this container, they can perform test actions within the SAML messages and simultaneously capture the traffic for later use or real-time analysis using Wireshark or SAML Tracer extension. In this case, we have use this environment to record logs and traces in order to perform a security analysis of SAML. In this analysis, the SAML messages and their main characteristics are described to inform about how real life implementations materialize the directives given by the technical rules of the protocol. In addition, small proof of concepts that could abuse certain protocol flaws are shown in order to inform about these possibilities and how to avoid them. The second environment was specifically built for OAuth 2.0 and OIDC. To create this environment, we utilized the oauthlib and Flask libraries to establish an OAuth Client that can also function as an RP. The OAuth Client and RP components were encapsulated within a Docker container, exposing port 80 to access the web application. Within this web application, various functionalities were provided to test the redirection and authorization processes. Additionally, the application was configured to make use of the Google Calendar API, allowing users to view their Google Calendar events list within this OAuth client. To achieve this, a registration process for the OAuth client was performed to obtain a Client ID and Client Secret. These credentials were necessary to establish the OAuth flows correctly to authenticate the OAuth client with the Google AS. Furthermore, an OIDC button was incorporated into the web page. As this OAuth client is now an OIDC RP, data related with the authentication process is now sent by the AS, now called OP. This data is carried in an ID Token that allows the RP to query some details about this authentication, such as the user identifier, email, and expiration time, etc. Additionally, the RP can verify the authenticity of this ID Token by validating the signature contained within the token. When the mentioned OIDC button is clicked, the user is redirected to an endpoint that displays the unencoded contents of all ID Token parts and shows the user if this token is verified or not. To facilitate the testing of this environment, a user container was established to allow a user to make some testing. For this purpose, a noVNC container with Ubuntu Desktop was once again deployed within the Docker internal network of the environment. With this system a user could use this OAuth client and test the different characteristics of this environment. At the same time, this user can generate logs and traces that could be used for later analysis. xvii With this environment up and running, some traces were generated and analyzed to learn about the precise parameters and flows used by the OAuth 2.0 and OIDC protocols in real implementations as the one built. In addition to that, the major security implications about the OAuth 2.0 protocol were researched in order to perform some basic proof of concepts to test some of this security concepts and to check patches and fixes that could be applied in order to solve those security risks. In summary, this thesis focuses on the research and analysis of three widely used protocols in the context of AAI: SAML, OAuth 2.0, and OIDC. Throughout this research, some state of the art was written about how these protocols work with the description of the general flows and components that they use. After this, a design process was made in order to build two Docker-based benchmark environments to simulate realworld scenarios and evaluate the protocols’ functionalities and configurations. Finally, an analysis of the traces and logs generated by the environments was made to provide a better understanding of the parameters that a real implementation can produce. Furthermore, the benchmark environments has allowed us to test some possible vulnerabilities that this protocols have and some of the patches that can be used to solve them.