SciTokens: Capability-Based Secure Access to Remote Scientific Data

The management of security credentials (e.g., passwords, secret keys) for computational science workflows is a burden for scientists and information security officers. Problems with credentials (e.g., expiration, privilege mismatch) cause workflows to fail to fetch needed input data or store valuable scientific results, distracting scientists from their research by requiring them to diagnose the problems, re-run their computations, and wait longer for their results. In this paper, we introduce SciTokens, open source software to help scientists manage their security credentials more reliably and securely. We describe the SciTokens system architecture, design, and implementation addressing use cases from the Laser Interferometer Gravitational-Wave Observatory (LIGO) Scientific Collaboration and the Large Synoptic Survey Telescope (LSST) projects. We also present our integration with widely-used software that supports distributed scientific computing, including HTCondor, CVMFS, and XrootD. SciTokens uses IETF-standard OAuth tokens for capability-based secure access to remote scientific data. The access tokens convey the specific authorizations needed by the workflows, rather than general-purpose authentication impersonation credentials, to address the risks of scientific workflows running on distributed infrastructure including NSF resources (e.g., LIGO Data Grid, Open Science Grid, XSEDE) and public clouds (e.g., Amazon Web Services, Google Cloud, Microsoft Azure). By improving the interoperability and security of scientific workflows, SciTokens 1) enables use of distributed computing for scientific domains that require greater data protection and 2) enables use of more widely distributed computing resources by reducing the risk of credential abuse on remote systems.Comment: 8 pages, 6 figures, PEARC '18: Practice and Experience in Advanced Research Computing, July 22--26, 2018, Pittsburgh, PA, US

Access Control Mechanism for IoT Environments Based on Modelling Communication Procedures as Resources

Internet growth has generated new types of services where the use of sensors and actuators is especially remarkable. These services compose what is known as the Internet of Things (IoT). One of the biggest current challenges is obtaining a safe and easy access control scheme for the data managed in these services. We propose integrating IoT devices in an access control system designed for Web-based services by modelling certain IoT communication elements as resources. This would allow us to obtain a unified access control scheme between heterogeneous devices (IoT devices, Internet-based services, etc.). To achieve this, we have analysed the most relevant communication protocols for these kinds of environments and then we have proposed a methodology which allows the modelling of communication actions as resources. Then, we can protect these resources using access control mechanisms. The validation of our proposal has been carried out by selecting a communication protocol based on message exchange, specifically Message Queuing Telemetry Transport (MQTT). As an access control scheme, we have selected User-Managed Access (UMA), an existing Open Authorization (OAuth) 2.0 profile originally developed for the protection of Internet services. We have performed tests focused on validating the proposed solution in terms of the correctness of the access control system. Finally, we have evaluated the energy consumption overhead when using our proposal.Ministerio de Economía y CompetitividadUniversidad de Alcal

Implementação de Sticky Policies em um provedor OpenID Connect

TCC(graduação) - Universidade Federal de Santa Catarina. Centro Tecnológico. Sistemas de Informação.Com o crescente mercado de sistemas web, deve crescer também o cuidado das organizações com os dados sensíveis dos usuários de seus serviços, em especial dados de identificação, também chamados de PII (personally identifiable information), enviados pelos usuários para as suas aplicações. Quando usuários compartilham seus dados com um serviço, devem ter controle sobre o uso destes e certeza que o destino destes dados será cumprido, além das regras quanto ao seu uso ou divulgação a terceiros. As políticas de privacidade são os documentos que destinam-se a ajudar o usuário a entender sobre o tratamento dos dados após a coleta. Através delas, o usuário é questionado ou informado sobre as informações coletadas, o uso dessas informações, o tempo de retenção ou da divulgação das mesmas. O OpenID Connect, que conta com diversas implementações Open Source e baseado no protocolo OAuth 2.0, visa garantir autenticação e autorização entre um usuário e o serviço desejado. Para tanto, fornece as informações sobre o usuário final na forma de um token, que contém as informações básicas de perfil sobre o usuário. Através deste trabalho, foi realizada a implementação de uma extensão em um provedor de identidades que utiliza o protocolo OpenID Connect, permitindo o envio de políticas de privacidade no contexto da utilização do serviço, juntamente com as informações básicas contidas no token. Para tal, é utilizado o contexto de Sticky Policies, que agrega as políticas de privacidade aos dados do usuário normalmente enviados pelo protocolo OpenID Connect, permitindo que o usuário de um serviço tenha controle sobre a aplicação e divulgação de seus dados.As the web systems market grows up, organizations concern with services classified users data must grow as well, especially identification data, also called PII - Personally Identifiable Information, which is sent from the users to companies applications. When users share their data with a service, they must have control upon it’s destination and make sure it’s purpose will be fulfilled, beyond third party usage and disclosure rules. Privacy policy are documents intended to help final users understand the handling given to their data after they’ve been collected. Through them the user is questioned or informed about collected information, it’s usage, retention time or even dissemination. The OpenID Connect, which has some Open Source implementations and is based on OAuth 2.0, aims on guarantee authentication and authorization between a user and the desired service. For such, it provides end-user information in form of a token containing basic information about the user’s profile. Through this paper an extension to a OpenID Connect identity provider was implemented, allowing the transmission of privacy policies on service utilization context, together with basic user information incorporated on token. By that, the context of Sticky Policies is used, which adds the privacy policies to the user data normally sent by the OpenID protocol, allowing a user to have control upon application and propagation of it’s data while using a service

Sécurisation d'un réseau d'équipement loT avec le protocole Oauth

Selon une étude de l’entreprise américaine Gartner, le nombre d’objets (IoT) connectés à internet devrait presque doubler durant les deux prochaines années, passant de 11,1 milliards en 2018 à 20.4 milliards en 2020. La sécurité des IoT n’est pas facile à mettre en place. Certains appareils manquent simplement de puissance de calcul ou de mémoire et peuvent difficilement communiquer de façon sécurisée. D’autre part, une grande partie de l’internet des objets utilise la technologie « machine to machine » (M2M) pour communiquer entre eux et ne passe pas par un serveur centralisé. Le M2M nécessite un certain niveau de confiance entre les objets interconnectés qu’il est difficile de garantir même dans un réseau local. Dans le cadre de la sécurisation de systèmes IoT distribués, il est nécessaire de centraliser le système d’autorisation d’accès aux ressources et de pouvoir gérer et révoquer tout type de client au besoin. Le standard Oauth2.0 fourni les éléments nécessaires pour concevoir le système d’autorisation centralisé d’accès aux services distribués. Cependant, ce protocole est fortement dépendant de TLS. Toute communication doit être sécurisée au travers de requêtes https ce qui élimine de facto une partie non-négligeable des objets connectés actuellement sur le marché. Par ailleurs, en dérogeant légèrement au standard il est possible d’adapter le protocole pour supporter une partie des flux de communication sans TLS tout en offrant les mêmes garanties que dans sa forme initiale

Integrasi WSO2 API Manager Dengan MyITS Single Sign-On Berbasis OAuth2

Di dalam organisasi (dalam hal ini DPTSI-ITS), yang mengimplementasikan atau menjalankan WSO2 API Manager sekaligus MyITS Single Sign-On sebagai authorization server, menghadapi masalah di mana WSO2 API Manager memiliki basis data pengguna dan data client (Aplikasi yang mengakses data pengguna). Sedangkan di lain pihak, MyITS Single Sign-On juga memiliki basis data pengguna dan data client sendiri. Permasalahan basis data yang terpisah ini membuat operasional menjadi sulit, sebagai contoh apabila ada API Resource yang diproteksi oleh WSO2 API Manager, maka API Manager akan mengeluarkan access token secara mandiri untuk dapat mengakses API atau Resource yang diproteksi oleh WSO2 API Manager. Pengguna dan client yang dapat mengakses resource tersebut hanyalah pengguna dan client yang terdaftar di basis data WSO2 API Manager. Padahal MyITS Single Sign-On mempunyai data-data tersebut. Tugas akhir ini ingin menyelesaikan masalah tersebut dengan melakukan integrasi antara WSO2 API Manager dengan MyITS Single Sign-On di mana MyITS Single Sign-On digunakan sebagai external authorization server oleh WSO2 API Manager. Sehingga, WSO2 API Manager tidak perlu menggunakan basis datanya sendiri dan tidak perlu menggunakan built-in authorization server-nya sendiri melainkan menggunakan MyITS Single Sign-On sebagai external authorization server =============================================================================================================================== Within the organization (in this case DPTSI-ITS), which implements or runs the WSO2 API Manager as well as MyITS Single Sign-On as an authorization server, faces problems where the WSO2 API Manager has a user database and client data (Applications that access user data). On the other hand, MyITS Single Sign-On also has its user database and client data. This separate database problem makes operations difficult, for example, if there is an API Resource protected by WSO2 API Manager, the API Manager will issue an access token independently to be able to access the API or Resource protected by WSO2 API Manager. Users and clients that can access these resources are only users and clients registered in the WSO2 API Manager database. Even though MyITS Single Sign-On has these data. This final project wants to solve this problem by integrating WSO2 API Manager with MyITS Single Sign-On where MyITS Single Sign-On is used as an external authorization server by WSO2 API Manager. Thus, WSO2 API Manager does not need to use its database and does not need to use its built-in authorization server but instead uses MyITS Single Sign-On as an external authorization server

Formal Analysis and Verification of OAuth 2.0 in SSO

This thesis examines the OAuth 2.0 protocol within Single Sign-On (SSO) systems through modelling and formal analysis. The versatile Performing Security Proofs of Stateful Protocols (PSPSP), a theory for the Isabelle/HOL proof assistant was used to carry out the verification. Additionally the Open-Source Fixedpoint Model-Checker (OFMC), was used in this verification for its accessibility. PSPSP notably supports the modelling of mutable long-term state, a feature not common in many similar tools. The challenge lies in crafting a model that accurately mirrors real-world scenarios while integrating the OAuth 2.0 protocol on top of the TLS 1.2 protocol. The goal is to produce a model that is both realistic and doesn't induce false attack vectors in its abstraction. The complexity of combining SSO, OAuth, and TLS often necessitates simplifications for effective verification. This study explores the modelling of OAuth components without drastic over-simplifications, verifying each in isolation, and then applying compositional reasoning available in PSPSP/Isabelle to introduce the TLS protocol as well. This process necessitates a well-defined interface between components and verification of all components individually and in the composition. Both tools confirm the lack of detectable vulnerabilities in the OAuth 2.0 protocol, reinforcing its security and prominence in SSO systems. The research explores the process of modelling and formally verifying security protocols, and deepens the understanding of OAuth 2.0's role in SSO systems