Security failing for mapping endpoints

[jvendetti]

There doesn't appear to be any functioning security in place that prevents mapping endpoints from returning mappings with classes from private ontologies that are read restricted for callers.

---

Example 1 (get mappings for an ontology)

Issue a GET request for all mappings for a private ontology, e.g., http://data.bioontology.org/ontologies/RAD/mappings. Use an API key that doesn't have read access for said ontology.

Expected result: access denied error
Actual result: collection of mappings are returned with 200 OK status

---

Example 2 (get mappings for a class)

Issue a GET request for all mappings for a class. Choose a class from a public ontology that has a mapping to a class from a private ontology. Use an API key that doesn't have read access for the private ontology. To follow is an example from BioPortal's current data set:

The Normal anatomy class in the public SNOMEDCT ontology maps to:

normal anatomy (RADLEX - public ontology)
Human body structure (RCD - public ontology)
anatomAa normal (SCTSPA - public ontology)
normal anatomy (RAD - private ontology)

Request to retrieve mappings for "Normal anatomy":

http://data.bioontology.org/ontologies/SNOMEDCT/classes/http%3A%2F%2Fpurl.bioontology.org%2Fontology%2FSNOMEDCT%2F361083003/mappings?include=prefLabel

Expected result: three mappings returned (mapping with class from private ontology removed)
Actual result: all four mappings returned

---

The security layer is architected in such a way that it expects to operate on objects that inherit from LinkedData::Models::Base - see here and here. The Mapping class doesn't meet this requirement and the results of API calls are simply returned without any data filtering.

This security flaw has resulted in at least one case of an attempted workaround for not displaying private data in BioPortal's front-end, see ncbo/bioportal_web_ui#86.