File Server migration to the Google Cloud Platform (GCP)
Sabre will begin restricting access to the existing legacy endpoints of our File Server (http://webservices.sabre.com) starting in February 2024. Sabre will continue disable access to the legacy endpoints in a controlled manner through May 2024. During this time, Sabre will be available to assist customers with any issues they may encounter with adopting and File Server endpoints now hosted in the Google Cloud Platform (GCP).
We previously communicated about this migration in June 2022 (SAN16642) and in the original posting of SAN17008 on 12th June 2023 and repost on 26th September 2023. If you have already taken the specified action below, please disregard this message as these actions will be transparent.
Why are we doing this?
As a part of our multi-year Tech Transformation Initiative and the efforts to enhance agile, modern infrastructure at a global scale, increasing the speed and quality of product delivery and customer experience, including moving our on-premises data centers to the Google Cloud Platform (GCP).
Who will be impacted?
This change will impact the customers who are currently using legacy endpoints and have not yet taken the action specified below.
We strongly recommend that customers download and save all files instead of binding applications to the files on the File Server.
File Server vs Gateway migration
Sabre has also migrated customers from old HTTPS Webservices gateway URLs. We have two separate URLs that have a common domain main webservices.sabre.com, but each of them has a different purpose:
- http://webservices.sabre.com – is used by File Server (port: 80)
- https://webservices.sabre.com – is used as Web Services gateway (port: 443)
If you have any business questions, please reach out to your Account Manager. If you have any technical questions, please contact Customer Care/Support.
What does it mean?
We are asking all of Sabre customers currently using the following HTTP endpoints http://webservices.sabre.com and http://wsdl-crt.cert.sabre.com during accessing to File Server Sabre Dev Studio or Sabre APIs files like WDSL or XSD to make an endpoint change or reconfigure their application to point to the new endpoint and start using the following endpoint via the URL: https://files.developer.sabre.com. Please note that the new endpoint in GCP will utilize the HTTPS protocol and HTTP will not be available.
CURRENT ENDPOINTS - Current example domain names? (to be decommissioned)
- http://webservices.sabre.com/wsdl/(with_path_and_name).wsdl
- http://webservices.sabre.com/wsdl/(with_path_and_name).xsd
NEW ENDPOINTS - New example Domain Name in GCP *
- https://files.developer.sabre.com/wsdl/(with_path_and_name).wsdl
- https://files.developer.sabre.com/wsdl/(with_path_and_name).xsd
*We strongly recommend that customers download and save all files in local repository instead of binding applications to the files on the File Server. Binging new URL may create issues with access to files in future.
We will be restricting access to the legacy File Server based on customer's IP address.
Therefore from February 2024 through to May 2024, we will gradually blacklist IPs, starting with known internal IPs but proceeding to any IP that is currently calling the legacy File Server.
If you downloaded XSD files a long time ago (mainly check: xmldsig-core-schema.xsd and xml.xsd files), please verify if in the content of those files you don't have DOCTYPE elements like the below:
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN" http://webservices.sabre.com/wsdl/sabreXML1.0.00/tpf/XMLSchema.dtd ... >
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN" http://webservices.sabre.com/wsdl/sabreXML1.0.00/usg/XMLSchema.dtd ... >
If you find them, please remove DOCTYPE from XSD files. They contain an old URL to http://webservices.sabre.com/ .
The potential impact to customers
PLEASE NOTE: This legacy file server was publicly available for customers to download files and use them as required in their implementations. If you are calling the old file server in the standard running of your application, this is not a suggested practice. Any impact would be due to this type of implementation.
Example of impact to customers
Example scenario, where impact of severity could be high and stop an application functioning.
Every time your application runs it calls e.g. http://webservices.sabre.com/wsdl/sabreXML1.0.00/usg/SessionCreateRQ.wsdl
When the IP is blocked, this URL will no longer respond, therefore the application may not be able to create the session.
The range of impact will differ by customer but has the potential to stop your application from running.
This is why we encourage our customers to review and ensure that their applications are not using legacy URLs in their implementation.