4 ms·

There are of course two errors that the developer of the backend made. The first is not filtering what came back from the Amadeus API, but the second one - the

by robjan 6y ago

There are of course two errors that the developer of the backend made. The first is not filtering what came back from the Amadeus API, but the second one - the one I am referring to - is using an Amadeus API key with too much access. Amadeus filters the booking record depending on the level of access that the user accessing it has (the user being the backend in this case). In a previous life for another airline, I have experienced this problem before when a vendor tried to get something through to production which was retuning credit card numbers and expiry dates to the frontend (but not the CV3). This was all because the vendor tried to use the highest privilege API key rather than the one with access to the specific info they needed. It never got past UAT thanks to thorough security review in this case.

underwater 6y ago
The API key shouldn't change what type of data an API call returns. The developer should explicitly request data and that either succeeds or fails based on authorisation. Making assumptions about the use case from the key will of course lead to this kind of error.
- robjan 6y ago
  The PNR (passenger name record) is the data record which represents your booking on Amadeus. It's basically a semi-structured flat text file. Each line is an entry which may represent a leg of your journey, your name, the payment method used to make the booking or various remarks (which themselves are arbitrarily structured). These lines are filtered / redacted depending on your role. You have to remember that this is a legacy system which has remained pretty much unchanged for 40-50 years. It's hard to change because hundreds of airlines have their own legacy systems which rely on bookings being structured this way. And when you book a multi-carrier itinerary, the airlines often all access this same record directly on Amadeus. There has been some movement in recent years in a platform called NDC[0] (new distribution capability) but most airlines still rely on the PNR at the moment. [0]: https://www.iata.org/en/programs/airline-distribution/ndc/ https://www.iata.org/en/programs/airline-distribution/ndc/
- pathseeker 6y ago
  This is pretty standard when fetching entire complex objects from many backends. You get the full object with all of the fields the authorization layer allows you to see. Something like "GET /reservation/<id>" would rarely require you to specified the 50 fields that you would like included in the response. Many offer fields to explicitly filter for specific things, but the default is almost always to return the full object as much as the caller is allowed to see.
  - Aeolun 6y ago
    You shouldn’t arbitrarily include or exclude information. The response to a given input should always be the same output, and not depend on what API key you are calling with.
    - saberdancer 6y ago
      I agree. Using API key to determine what kind of information is returned is a strange solution. It would effectively mean that if the airline is developing an application that has multiple levels of users (airline employees, customers, admins) it would need to store and use multiple API keys to retrieve the data. Ofcourse, real solution here is that the airline software should not just pass along everything it received from Amadeus but rather that they should convert it and return only the relevant subset. This would avoid these type of issues.
      - pathseeker 6y ago
        Well unfortunately that's just not how the real world works. In most production systems you are going to end up with a bunch of fields that aren't visible to regular users. There ends up being a whole bunch of roles that need access to different levels and instead of implementing separate APIs for every user type, you just mask out the fields a specific type isn't allowed to see. This is frequently called property level authorization or field level authorization. https://stackoverflow.com/questions/30002351/enforcing-property-level-authorization-in-domain-objects https://stackoverflow.com/questions/30002351/enforcing-prope... https://help.salesforce.com/articleView?id=security_data_access.htm&type=5 https://help.salesforce.com/articleView?id=security_data_acc... You're just wording it in an indirect way to make it seem like something different. It's not "Using API key to determine what kind of information is returned", it's "hiding sensitive fields based on permissions".
saberdancer 6y ago
OK, thank you for the explanation. I was not aware that Amadeus is some type of backend system that airline software integrates with.

by robjan 6y ago

underwater 6y ago

The API key shouldn't change what type of data an API call returns. The developer should explicitly request data and that either succeeds or fails based on authorisation. Making assumptions about the use case from the key will of course lead to this kind of error.

robjan 6y ago
The PNR (passenger name record) is the data record which represents your booking on Amadeus. It's basically a semi-structured flat text file. Each line is an entry which may represent a leg of your journey, your name, the payment method used to make the booking or various remarks (which themselves are arbitrarily structured). These lines are filtered / redacted depending on your role. You have to remember that this is a legacy system which has remained pretty much unchanged for 40-50 years. It's hard to change because hundreds of airlines have their own legacy systems which rely on bookings being structured this way. And when you book a multi-carrier itinerary, the airlines often all access this same record directly on Amadeus. There has been some movement in recent years in a platform called NDC[0] (new distribution capability) but most airlines still rely on the PNR at the moment. [0]: https://www.iata.org/en/programs/airline-distribution/ndc/ https://www.iata.org/en/programs/airline-distribution/ndc/
pathseeker 6y ago
This is pretty standard when fetching entire complex objects from many backends. You get the full object with all of the fields the authorization layer allows you to see. Something like "GET /reservation/<id>" would rarely require you to specified the 50 fields that you would like included in the response. Many offer fields to explicitly filter for specific things, but the default is almost always to return the full object as much as the caller is allowed to see.
- Aeolun 6y ago
  You shouldn’t arbitrarily include or exclude information. The response to a given input should always be the same output, and not depend on what API key you are calling with.
  - saberdancer 6y ago
    I agree. Using API key to determine what kind of information is returned is a strange solution. It would effectively mean that if the airline is developing an application that has multiple levels of users (airline employees, customers, admins) it would need to store and use multiple API keys to retrieve the data. Ofcourse, real solution here is that the airline software should not just pass along everything it received from Amadeus but rather that they should convert it and return only the relevant subset. This would avoid these type of issues.
    - pathseeker 6y ago
      Well unfortunately that's just not how the real world works. In most production systems you are going to end up with a bunch of fields that aren't visible to regular users. There ends up being a whole bunch of roles that need access to different levels and instead of implementing separate APIs for every user type, you just mask out the fields a specific type isn't allowed to see. This is frequently called property level authorization or field level authorization. https://stackoverflow.com/questions/30002351/enforcing-property-level-authorization-in-domain-objects https://stackoverflow.com/questions/30002351/enforcing-prope... https://help.salesforce.com/articleView?id=security_data_access.htm&type=5 https://help.salesforce.com/articleView?id=security_data_acc... You're just wording it in an indirect way to make it seem like something different. It's not "Using API key to determine what kind of information is returned", it's "hiding sensitive fields based on permissions".

saberdancer 6y ago

OK, thank you for the explanation. I was not aware that Amadeus is some type of backend system that airline software integrates with.