• No results found

Third Party Authentication and OAuth 2.0

The purpose of the third (3rd) party authentication is to enable security authorization from a user’s so- cial media subscriptions. Using third party social networking Application Programming Interface (API) in personalized and enterprise oriented applications is becoming very popular for different reasons. But for this work, the motivation for the integration with the social networking services is to facilitate business– to–business (B2B) as well as business–to–consumer (B2C) support for the CSB–UCC framework. The B2B model facilitates enterprise adoption of the framework to provide an authentication layer for sharing doc- uments with other enterprises while the B2C model supports direct end–user (i.e. employees or external customers) access to the enterprise document.

Furthermore, the social networking feature makes the CSB–UCC usable for different enterprises which may have varying business workflow as well as business focus. For instance, an enterprise that wants to support only their internal staff (employees) to access Amazon S3 hosted data can employ the simple login approach. This approach requires that the user provides a username and a password from the mobile device to the broker; and the CSB–UCC checks from its repository of users to determine whether the supplied credentials are valid and matching. Provided the user’s credentials match, the CSB–UCC then fetches the user’s Amazon S3 credentials and forwards the request to Amazon. In this process of authentication, the enterprise’ data accessibility is “sandbox” and only legitimate employees can have access to the data. Also, there is nothing like data sharing; and hierarchical privileges can be enforced. The same simple login can be used to access personalized data from Dropbox and MEGA. But, another point of call is what happens when the enterprise is an advertising or marketing company and will like to target multiple customers outside their facility.

The social networking authentication component allows users of the CSB–UCC to login through Facebook, or Google+. The authentication through the social networking sites is based on OAuth 2.0 technology. Thus, when a user opts to login through a social media say Facebook, the broker forwards the request to the Facebook authentication system where the user will be presented with the option to provide Facebook ID and password. If the user is a valid Facebook account holder, the broker fetches the user’s credentials including the Facebook security access token and stores these credentials in the user token repository (a storage area on the broker). But, in an enterprise where security is paramount and only employees are required to access the data on the Amazon S3 facility, the system administrators are strongly advised to pre–populate the user’s accounts including the access tokens from the social media as well. In that case, if a user logs into the system and the credentials are not already stored in the broker’s repository, the user will be denied access to the data. The pre–population of the social media access token is also to prevent the creation of fake identities for malicious purposes on the Online Social Networks since Jin et al. [147] report on the increasing menace. Another issue that is observed is the possibility of having one user with multiple social media accounts. To solve this issue with multiple accounts, a graph database is created that links (or maps) the accounts of each user. Since the work relies on the security tokens which are unique for every user account, the user only need to specify his/her accounts and the tokens are linked from the various social media forums. Also, following the OAuth 2.0 technique, an end–user does not need to provide security credentials all the time until the browser session ends.

A third way that the CSB–UCC is useful in the context of social media is the facilitation of an authenti- cation approach that this dissertation describes as the hybrid authentication mechanism (i.e. either by social networking or proprietary personal login). Since enterprises have different needs, it is likely to find some that may require the hybrid authentication approach in order to meet their business execution workflow. The proposed framework can deal with such a situation since all the features are available for combinatorial usage. The social media authentication does not influence the Dropbox and MEGA services as much as Amazon

S3 since in most cases, the latter facility is employed by enterprises for group access while the former frame- works are mostly personal. The only advantage it offers Dropbox and MEGA users is the flexibility of using any account and the broker will determine the exact account that the user is registered with on those IaaS providers and issue the request with that account.

But, there is a security risk that is worth noting. Since, the OAuth 2.0 technique is employed for logging through social media, the mobile embedded browser keeps a session of the login details. Hence, when a user logs into the system on the first occasion through social media say Facebook and the “keep me logged in” option is checked, the subsequent login (within some time frame) takes the user straight to the application interface without the option to provide user credentials. Hence, end–users are cautioned to logout of the application all the time rather than just closing the application. Also, this caution should be a guiding principle for the high security enterprises that will adopt the CSB–UCC framework. To overcome this risk, it is recommend that the browser cache and cookies be programmatically cleared each time the application closes. Also, the user should be signed out automatically after the application is idle for some pre–define time.