This work introduces the available authorization frameworks for the purpose of Single Sign-On functionality within an enterprise, along with the fundamental technicalities. The focus of the work is on SAML 2.0 and OAuth 2.0 frame- works. Following the details related to available protocol flows, supported client profiles and security considerations, the two frameworks are compared in accordance with a set of factors given in a criteria. The report discusses the possibilities provided by a Microsoft Windows based infrastructure, as well as different scenarios and their feasibility in an enterprise environment. The preferred framework, OAuth 2.0, is selected according to the given criteria and the comparative discussions.

The diploma thesis deals with the analysis of the company and the focus on data security. Based on the company analysis and requirements is designed a new system of employee authorization in CMS systems of the company. The design of the employee authorization API solution is based on the OAuth 2.0 protocol.

I detta projekt har SharePoint integrerats i SiteVision. Flera av SiteVision AB:s kunder har efterfrågat en möjlighet att integrera produkten med SharePoint. Microsoft tillhandahåller inga direkta API:er för SharePoints objektmodell i Java som SiteVision är skrivet i. SiteVision AB visste inte hur kunderna ville kunna arbeta med SharePoint i SiteVision och var angelägna om att ta reda på detta. Det övergripande syftet med denna rapport har varit att möjliggöra en attraktiv integration av SharePoint från SiteVision. Detta har utförts genom att undersöka vilka delar av SharePoint som SiteVision AB:s kunder vill kunna komma åt från SiteVision och hur kunderna vill kunna komma åt dessa delar i SiteVision. Undersökningen har genomförts genom kvalitativa intervjuer med några av SiteVision AB:s kunder. Undersökningen har visat att kunderna helst vill ha en integration mot SharePoints dokumenthanteringssystem. De vill ha möjligheten att lista filer från SharePoint i SiteVision utifrån en given mapp eller metadata. De vill även kunna söka efter SharePoint-filer i SiteVision. Ett internt API för kommunikation mot SharePoint i Java har konstruerats. Efter kundernas önskemål har en SiteVision-modul som listar filer utifrån en angiven mapp skapats. Dessutom har en enkel prototyp till sökmodul konstruerats. Resultaten från intervjuerna kan inte anses vara representativa för hela kundkretsen men gav en indikation om vad som skulle utvecklas först. Projektets mål är uppfyllda men modulerna behöver utvecklas vidare innan de kan lanseras. / In this thesis project, SharePoint has been integrated in SiteVision. Several customers of SiteVision AB have requested an integration of SharePoint from SiteVision. Microsoft doesn’t provide any API for Java to SharePoint object model. SiteVision AB did not know in what form the customers wanted to access SharePoint from SiteVision but was keen to find out. The overall aim with this thesis has been to make an appealing integration of SharePoint from SiteVision possible. This has been accomplished by performing a study investigating what parts of SharePoint the customers wanted to access from SiteVision and in what form they wanted to access it. The study has been performed by qualitative interviews with some of the customers of SiteVision AB. The study has shown that the customers most of all wants to integrate the document management system of SharePoint. They want to be able to view SharePoint files inside SiteVision based on a provided folder, or file meta data. They also want to search for SharePoint files in SiteVision. An internal API for communication with SharePoint in Java has been constructed. Based on the customers’ requests, a SiteVision module that lists SharePoint files based on a folder has been created. Furthermore, a simple prototype for a search module has been constructed. The results from the study cannot be considered as representative of all customers but gave an indication of what should be developed first. The overall aim has been fulfilled but the modules need additional developing before they can be released.

A lot of information nowadays is made available through Web APIs on the Internet and without security and encryption; it is very easy for malicious users to access confidential information. The goal was to find out what different mechanisms that are available for providing a safe communication with a web API from web clients and mobile applications with little as possible impact on the performance. Learning, implementing and maintaining the mechanisms are also im- portant aspects looked at in the evaluation. Many mechanisms are available for use to secure the communication but not all are suitable for public clients. The suitable mechanisms are Digest authentication and OAuth 2.0. The chosen mechanisms were developed, tested and evaluated in regard to safety, performance impact and usabil- ity from a company perspective. The authentication and authorization mechanism, which was the most suitable, was OAuth 2.0as it has least impact on performance and better security features than the other mechanisms. / Mycket information finns numera tillgänglig via Web API:er på Internet och utan säkerhet och kryptering är det mycket lätt att illvilliga personer får tillgång till konfidentiellinformation. Målet är att ta reda på vilka olika säkerhetsmekanismer som finns tillgängliga för att tillhandahålla en säker kommunikation med ett Web API från webbklienter och mobila applikationer med så liten påverkan på prestanda. Kunskapsinhämtning, utveckling och underhållandet av lösningar är också viktiga aspeketer som tittats på vid utvärderingen av mekanismerna. Flera mekanismer finns att använda sig av för att säkra kommunkationen men de lämpliga mekanismerna för publika klienter är Digest Authentication och OAuth 2.0. De utvalda mekanismerna har utvecklats, testats, utvärderats med avseende på säkerhet, påverkan på prestanda och användbarhet utifrån ett företags perspektiv. Autentiserings- och behörighets-mekanismen som blev den utvalda var OAuth 2.0 då den har minst påverkan på prestandan och bättre säkerhets egenskaper än de andra mekanismerna.

The aim of this project has been to explore alternative technical solutions for making own extensions in the CMS SiteVision. The purpose of these extensions is to retrieve data from an external API (Office 365) which requires OAuth 2.0 authentication. Additional, the alternative technical solutions have been evaluated and compared. The comparisons have been made based on criteria developed through interviews with professional IT-consultants. The purpose of the project has been to contribute to more efficient digitization, integration and individualization of datasystems. Within the project, an applied example (POC) has been created to show examples of how the technology can be used. In this example, Java Portlets have been used to implement the above functionality. WebApps in SiteVision have also been studied since this technology is an alternative to Java Portlets. The survey shows that it is fully possible to create a separate extension in SiteVision that performs authentication with OAuth 2.0 and then uses it to retrieve data from an external API. The results from the comparison between the two different Java Portlets and WebApps technologies show that there are pros and cons of each technique. The alternatives studied where comparable in performance. Individual circumstances can dictate which alternative is best. / Det övergripande syftet med detta projekt har varit att bidra till en effektiviserad digitalisering och individualisering. Målet för projektet har varit att undersöka alternativa tekniska lösningar för att göra egna tillägg i CMS:et SiteVision. Tillägg vars uppgift består i att hämta data från ett externt API (Office 365) som kräver autentisering med OAuth 2.0. Vidare har de alternativa tekniska lösningarna värderats och jämförts. Jämförelsen har gjorts utifrån kriterier som tagits fram genom intervjuer med utvecklare på ett IT-konsultbolag. Inom projektet har ett tillämpat exempel (POC) skapats för att visa exempel på hur tekniken kan användas. I detta exempel har Java Portlets använts för att implementera ovanstående funktionalitet. Även WebApps i SiteVision har studerats då den tekniken utgör ett alternativ till Java Portlets. Undersökningen visar att det är fullt möjligt att skapa ett eget tillägg i SiteVision som genomför autentisering med OAuth 2.0 och sedan använda denna för att hämta data från ett externt API. Resultaten från jämförelsen mellan de två olika teknikerna Java Portlets och WebApps visar att det finns för- och nackdelar med respektive teknik. Båda alternativen framstår som jämstarka i jämförelsen. De individuella omständigheterna kring ett framtida användande bör fälla avgörandet för vilken teknik som väljs.

Examensarbetet går igenom vanliga säkerhetsrisker med publika API:er och ger information om IIS, Apache, Nginx, OAuth 2.0 och några av deras säkerhetsmoduler som kan implementeras. IIS och Apache har inbyggda hanteringsprocesser för att motverka ”Distributed-Denial-of-Service” (DDoS) attacker som jämförs med varandra utifrån analys av en befintlig rapport som testar två olika DDoS attacktyper. Säkerhetslösningarnas autentiseringsmoduler bryts ner i olika verifieringsprocesser, där det framkommer att verifieringsprocesserna har en gemensam svaghet mot ”Man-in-The-Middle” (MitM) attacker. Rapporten går in djupare hur man kan skydda sig mot MitM attacker med bra krypteringsprotokoll, ”Transport Layer Security” (TLS), samt undersöker den nyaste versionen TLS 1.3 / The thesis examines common security risks with public APIs and provides information about IIS, Apache, Nginx and OAuth 2.0 and some of the security modules they provide that can be implemented. IIS and Apache have builtin modules for handling Distributed-Denial-of-Service (DDoS) attacks that are compared against eachother through analyzing a existing report that tests two different DDoS attack types. The security solutions authentication modules are broken down into different types of verification processes, where it comes forth that the processes share a common security risk against Man-in-the-Middle (MitM) attacks. The report goes through how you can protect against MitM attacks with secure encryption protocols, Transport Layer Security (TLS), and analyzes the newest version TLS 1.3.

Stora mängder data genereras dagligen av slutanvändare hos olika tjänster. Denna data tenderar att tillhandahållas av olika aktörer, vilket skapar en fragmenterad marknad där slutanvändare måste nyttja flera programvaror för att ta del av all sin data. Detta kan motverkas genom utvecklandet av aggregeringstjänster vilka samlar data från flera tjänster på en enskild ändpunkt. Utveckling av denna typ av tjänster riskerar dock att bli kostsamt och tidskrävande, då ny kod skrivs för flera projekt trots att stora delar av funktionaliteten är snarlik. För att undvika detta kan etablerade tekniker och ramverk användas för att på så vis återanvända mer generella komponenter. Vilka av dessa tekniker som är bäst lämpade och således kan anses vara mest effektiva ur ett utvecklingsperspektiv, kan dock vara svårt att avgöra. Därför baseras denna uppsats på vad som genom analys av akademisk litteratur kan utläsas som ett akademiskt konsensus.Innan denna uppsats påbörjades utvecklades en Java-baserad dataaggeringstjänst baserad på krav från ÅF i Malmö. Denna experimentella implementation har som syfte att samla in data från två separata tjänster, och tillgängliggöra denna på en enskild ändpunkt. Efter att implementationen färdigställts påbörjades arbetet på uppsatsen. Denna består av en litteraturstudie för att undersöka vilka tekniker och ramverk som akademisk forskning funnit bäst lämpad för användningsområdet. Vidare används resultaten från studien även för att analysera i vilken grad dessa korrelerar med de krav som ÅF presenterade inför den experimentella implementationen.Litteraturstudien visar på att de teknikmässiga val som gjordes av företaget i stor utsträckning korrelerar med de tekniker som akademisk forskning funnit bäst lämpade för användningsområdet. Detta innefattar bland annat OAuth 2.0 för autentisering, JSON som serialiseringsformat samt REST som kommunikationsarkitektur. Vidare visar denna litteraturstudie på en eventuell lucka inom den tillgängliga litteraturen, då sökningar kring specifika programvaror relaterade till området endast resulterar i en mindre mängd artiklar. / Large quantities of data are generated daily by the end users of various services. This data is often provided by different providers, which creates a fragmented market where the end users have to utilize multiple applications in order to access all of their data. This can be counteracted by the development of aggregation services that gather data from multiple services to a combined endpoint. The development of these kinds of services does however run the risk of becoming costly and time-consuming since new code is written for several projects even though large portions of the functionality is similar. To avoid this, established technologies and frameworks can be utilized, thereby reusing the more general components. Which of the technologies are the best suited, and thereby can be considered the most effective from a development perspective, can however be difficult to determine. This essay is therefore based on what can be considered an academic consensus through analysis of literature regarding earlier reasearch on the subject. Before the writing of the essay began a Java-based data aggregation service was developed, based on requirements from the company ÅF in Malmö. The purpose of this experimental implementation is to gather data from two separate services, and make them accessible on a unified endpoint.After the implementation was finished, work on the essay began. This consists of a literature review to investigate what technologies and frameworks that has been found best suited for this area of application by academic research. The results from this study are also used to analyze the extent of the correlation between the results and the requirements presented by ÅF regarding the experimental implementation. The literature review shows that the choices made by the company largely correlates with the technologies that the academic research has found best suited for this area of application. This includes OAuth 2.0 for authentication, JSON as a serialization format and REST for communications architecture. The literature review also indicates a possible gap within the available academic literature since searches regarding specific pieces of software related to the subject only results in a small amount of articles.

Single Sign-On (SSO) är en autentiseringsprocess som tillåter en utvecklare att delegera autentiseringsansvaret till en dedikerad tjänst. OAuth 2.0 är ett auktoriseringsramverk som ofta står som grund för ett autentiseringslager som i sin tur möjliggör SSO. En identitetsleverantör är tjänsten som står för hantering av användaruppgifterna och autentiseringen, två vanliga identitetsleverantörer är Google och Facebook som i sin tur implementerar SSO med hjälp utav autentiseringslagren OpenID Connect respektive Facebooks egna autentiseringslager. Det har visat sig att många klienter som ska utnyttja SSO med OAuth 2.0 implementerar det fel så att säkerhetsbrister uppstår, studier har utförts med förslag till lösningar men många bristande implementationer fortsätter produceras och existera. Att skapa diverse verktyg för att främja säkerhet i dessa sammanhang är en metod där OAuthGuard utvecklats med visionen att även kunna skydda användaren, direkt från en webbläsare. OAuthGuard har även tidigare använts för att analysera säkerheten med Google SSO och visat att 50% av undersökta klienter har brister, men motsvarande studie eller verktyg saknas för Facebook SSO. Denna studie gjorde en motsvarande undersökning för Facebook SSO-klienter med en vidareutvecklad version av OAuthGuard och fann att de lider av brister med liknande trend som tidigare studies resultat mot Google-SSO-klienter, men att färre Facebook- SSO-klienter har brister i jämförelse. Vid vidareutvecklingen av OAuthGuard upptäcktes ett antal svårigheter och framtiden för denna typ av verktyg behöver vidare analyseras. Vidare analys behöver även göras för att bedöma om Facebook-SSO kan vara att föredra över Google-SSO ur säkerhetsperspektiv samt vidare utforskande av nya säkerhetsfrämjande metoder behöver utföras. / Single Sign-On (SSO) is an authentication process that allows a developer to delegate the authentication responsibility to a dedicated service. OAuth 2.0 is an authorization framework that often serves as a base for authentication layers to be built upon that in turn allows for SSO. An identity provider is the service that is responsible for handling user credentials and the authentication, two common identity providers are Google and Facebook that implement SSO with the authentication layers OpenID Connect respectively Facebooks own authentication layer. It has been shown that many clients using OAuth 2.0 as base for SSO make faulty implementations leading to security issues, a number of studies has proposed solutions to these issues but faulty implementations are continually being made. To create various tools to promote security in these contexts is a method where OAuthGuard has been developed with the vision to also directly protect the common website user directly from the browser. OAuthGuard has been used in an earlier study to analyze the security of clients using Google SSO and discovered that 50% of the analyzed clients had flaws, no comparable study has been done for clients using Facebook SSO, which is the second largest third party log in variant. This study made a comparable investigation for Facebook SSO clients with a further developed version of OAuthGuard and found that these clients suffer from flaws with a similar trend as the previous study with Google-SSO clients, although fewer Facebook-SSO clients suffer from these flaws. When further developing OAuthGuard a dumber of difficulties was discovered and the future of these kind of tools needs to be investigated. Further analysis needs to be done to assess if Facebook-SSO should be recommended over Google-SSO from a security perspective and also further exploration of new methods to promote security needs to be done.