In this post, I will share with you a story about why it is so important to be aware of any 3rd parties dependencies and how you manage the ownership and access control to them.
Context
Starting a few years ago it becomes widespread to integrate your web application with 3rd parties identity providers like Facebook, Google or Twitter. From the consumer perspective, it is more straightforward to have only one identify and use it on multiple web application versus having different accounts and password for each application.
Let’s take Facebook as an example where to be able to do such an integration you need to create a Facebook App that it is used as the authentification and authorization layer for your app. The application can be created by a normal Facebook Account that becomes the Administrator of the Facebook App.
In most of the cases, the company that owns the web application does not have IT capabilities and use an external company to implement the web application and manage the Facebook account. Everything is going as planned until in the moment the company decides to change the IT provider that manages the web application.
In general, you have a contract with the IT provider that it is offering IT services. The source code of the web application it is own by you, the custom DNS name and HTTPS certificates are own by you also, the same thing applies for other dependencies. However, you might forget to add in the contract the 3rd parties applications, that from an ethical perspective are own by the customer. The perfect example here is the Facebook App. Why? Because the IT company might claim the rights on it and give you headaches once you are not their customer anymore.
Scenario
This is the following case that I had to manage:
BOOOMMM!!!!
This is the moment when things become ugly. The previous IT company disable the Facebook application. Guess what? The web application becomes unusable, and the customer is losing money.
After long discussions, they are accepting to enable the Facebook App for 30 days, but they are refusing to add as an administrator of the Facebook, the real owner of the Facebook App.
Remember: It is important to know that an administrator of a Facebook App can add another administrator. Besides this, an administrator can remove the previous administrators.
Even if creating a new app might be a solution, because you cannot migrate users from one Facebook App to another, you cannot do a user’s migrations. Using user email address that you already store in the web application you might find solutions to link a new user registration with previous data. These come at an extra cost and a risk to do something wrong and have users that don’t have the old data merged with the new account. It can become a disaster when users are paying a monthly fee to have access to the web application, and you need to do manual actions to merge the accounts. These risks combine with a high volume of users (let’s say 50.000 unique register users) it’s a good receipt for disaster.
Lesson learned
From a contractual point of view you shall always ensure that besides source code, all 3rd party applications and systems are own by the customer and not by the IT company that offers support. In this way, from a legal perspective, you can secure the Facebook Application that it is own by you (the customer) and not by the IT company that you subcontracted.
Additional to this on all 3rd party systems you should manage them using dedicated accounts and not a personal account. In the case of Facebook App, you need to create a Facebook Account that is owned by the customer and has full rights to the Facebook App. Depending on the policy that you want to use you might share the account with the IT company or add additional administrators to the app.
Conclusion
The most important thing that needs to be done is to ensure that you the 3rd party applications are managed using accounts and channels that are own by the customer and not by IT company that is offering support. The legal owner of the system shall ensure that has full control over their systems.
Context
Starting a few years ago it becomes widespread to integrate your web application with 3rd parties identity providers like Facebook, Google or Twitter. From the consumer perspective, it is more straightforward to have only one identify and use it on multiple web application versus having different accounts and password for each application.
Let’s take Facebook as an example where to be able to do such an integration you need to create a Facebook App that it is used as the authentification and authorization layer for your app. The application can be created by a normal Facebook Account that becomes the Administrator of the Facebook App.
In most of the cases, the company that owns the web application does not have IT capabilities and use an external company to implement the web application and manage the Facebook account. Everything is going as planned until in the moment the company decides to change the IT provider that manages the web application.
In general, you have a contract with the IT provider that it is offering IT services. The source code of the web application it is own by you, the custom DNS name and HTTPS certificates are own by you also, the same thing applies for other dependencies. However, you might forget to add in the contract the 3rd parties applications, that from an ethical perspective are own by the customer. The perfect example here is the Facebook App. Why? Because the IT company might claim the rights on it and give you headaches once you are not their customer anymore.
Scenario
This is the following case that I had to manage:
- A company is subcontracting an IT company to develop a Web Application.
- The Web Application authentication and authorization mechanism it is only based on Facebook.
- A Facebook Application is created to handle this by the IT company.
- From the IT company, an employee is using his own personal account to create and manage the Facebook App.
- The web application goes live for a while
- The customer decides to change the IT company that offers support
BOOOMMM!!!!
This is the moment when things become ugly. The previous IT company disable the Facebook application. Guess what? The web application becomes unusable, and the customer is losing money.
After long discussions, they are accepting to enable the Facebook App for 30 days, but they are refusing to add as an administrator of the Facebook, the real owner of the Facebook App.
Remember: It is important to know that an administrator of a Facebook App can add another administrator. Besides this, an administrator can remove the previous administrators.
Even if creating a new app might be a solution, because you cannot migrate users from one Facebook App to another, you cannot do a user’s migrations. Using user email address that you already store in the web application you might find solutions to link a new user registration with previous data. These come at an extra cost and a risk to do something wrong and have users that don’t have the old data merged with the new account. It can become a disaster when users are paying a monthly fee to have access to the web application, and you need to do manual actions to merge the accounts. These risks combine with a high volume of users (let’s say 50.000 unique register users) it’s a good receipt for disaster.
Lesson learned
From a contractual point of view you shall always ensure that besides source code, all 3rd party applications and systems are own by the customer and not by the IT company that offers support. In this way, from a legal perspective, you can secure the Facebook Application that it is own by you (the customer) and not by the IT company that you subcontracted.
Additional to this on all 3rd party systems you should manage them using dedicated accounts and not a personal account. In the case of Facebook App, you need to create a Facebook Account that is owned by the customer and has full rights to the Facebook App. Depending on the policy that you want to use you might share the account with the IT company or add additional administrators to the app.
Conclusion
The most important thing that needs to be done is to ensure that you the 3rd party applications are managed using accounts and channels that are own by the customer and not by IT company that is offering support. The legal owner of the system shall ensure that has full control over their systems.
Comments
Post a Comment