Bug 1009843 - [RFE] [REST-API]: Implement public queries in API
[RFE] [REST-API]: Implement public queries in API
Status: CLOSED WONTFIX
Product: ovirt-engine
Classification: oVirt
Component: RFEs (Show other bugs)
---
Unspecified Unspecified
unspecified Severity medium (vote)
: ---
: ---
Assigned To: Ravi Nori
: FutureFeature
: 1132241 1138598 (view as bug list)
Depends On:
Blocks: 1026718 1027210 1132506
  Show dependency treegraph
 
Reported: 2013-09-19 05:48 EDT by David Jaša
Modified: 2016-11-29 04:51 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-29 04:42:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 20197 None None None Never

  None (edit)
Description David Jaša 2013-09-19 05:48:23 EDT
Description of problem:
When users log in via User or Webadmin portals, they are given list of domains where their usernames belong. The same is not true for REST API-based apps as they can fetch domain list at /api/domains only after successful authentication, creating a chicken-egg problem.
Given that the domains are already listed for authenticated users at /api/domains, it should be quite simple & straightforward to:
1) return HTTP 200 to unauthorized requests to /api that would contain just:
<api>
    <link href="/api/domains" rel="domains"/>
</api>

2) return HTTP 200 to unauthorized users requesting /api/domains with all the internal info stripped:
<domains>
    <domain>
        <name>example.com</name>
    </domain>
    <domain>
        <name>internal</name>
    </domain>
</domains>

This way, potential adversaries can not gain any new information that they don't already have (from user & webadmin portal) while UX of REST API apps can be greatly improved.


Version-Release number of selected component (if applicable):
is15 / rhevm-restapi-3.3.0-0.22.master.el6ev.noarch

How reproducible:
always

Steps to Reproduce:
1. try to get authentication domain names as an unauthenticated REST API user 
2.
3.

Actual results:
the information can not be retreived

Expected results:
domain names are somehow exposed

Additional info:
CCing people who have stumbled upon this issue (teuf, Shireesh)

If you think that domain list should not be publicly exposed at all, then the domain chooser should also be removed from User/Webadmin portals as well for sake of consistency...

References:
whole thread starting here: http://lists.ovirt.org/pipermail/engine-devel/2013-March/003894.html
Comment 1 Barak 2013-10-07 04:20:15 EDT
*** Bug 958874 has been marked as a duplicate of this bug. ***
Comment 2 Michael Pasternak 2013-10-14 08:25:21 EDT
please define the list of the entities that should/can be fetched without auth.
Comment 4 Juan Hernández 2014-06-16 11:03:20 EDT
Authentication and authorization is outside of the scope of the RESTAPI now, but managed by the authentication infrastructure and the backend.
Comment 5 Alon Bar-Lev 2014-06-16 11:27:40 EDT
Yair,
I had the impression that the restapi cannot be accessible by regular user, not to mention separate between view that can be seen by one user and another.
In order to implement anonymous subset of the rest-api we should have this supported before implementation is aaa specific.
So this bug is not about aaa but the support of rest-api in different views for different users, one which can be anonymous.
Do I miss anything?
Comment 6 Juan Hernández 2014-06-16 11:32:31 EDT
The RESTAPI is already accessible by any user. Each user can see whatever the permissions system determines, as queries performed by the RESTAPI only return whatever the backend considers appropriate for that user.
Comment 7 Alon Bar-Lev 2014-06-16 11:44:43 EDT
(In reply to Juan Hernández from comment #6)
> The RESTAPI is already accessible by any user. Each user can see whatever
> the permissions system determines, as queries performed by the RESTAPI only
> return whatever the backend considers appropriate for that user.

great. so all we need is to have user that is anonymous and can access what "public" is.
Comment 8 Barak 2014-06-24 12:14:28 EDT
(In reply to Juan Hernández from comment #6)
> The RESTAPI is already accessible by any user. Each user can see whatever
> the permissions system determines, as queries performed by the RESTAPI only
> return whatever the backend considers appropriate for that user.

Juan - the above permissions you have mentioned are dealing only with the system managed entities.
AFAIU here we need anonymous access to at least the folowing:
- authentication profiles (to be used by the UI on the login screen)
- health (server status, version) same as appears in the login screen
Comment 9 Juan Hernández 2014-06-24 12:32:04 EDT
This bug is (or was) about providing anonymous access to existing resources. If new resources are needed then please open the corresponding bugs to request their creation.

If additional resources are created they should work like any existing resource. The RESTAPI doesn't check permissions, it sends queries to the backend and renders whatever the backend gives as output. So, in order to access anonymously those potential new resources, what is requested in this bug will still be needed.
Comment 10 Juan Hernández 2014-09-02 05:42:15 EDT
*** Bug 1132241 has been marked as a duplicate of this bug. ***
Comment 11 Juan Hernández 2014-09-05 05:38:34 EDT
*** Bug 1138598 has been marked as a duplicate of this bug. ***
Comment 12 Yair Zaslavsky 2014-12-08 21:12:55 EST
Per my work on BZ1168842 I would like to consider giving this priority in 3.6.
Juan, is there any technical limitation when it comes to rest-api side of not performing authentication beisdes the need to call on Backend runPublicQuery?
Comment 13 Alon Bar-Lev 2014-12-09 00:46:55 EST
In 3.6 I would like the runPublicQuery use context of guest user, so it be a standard query that is permitted to guest.
Comment 14 Juan Hernández 2014-12-09 04:28:16 EST
The current limitation is that the backend requires a session, and that the RESTAPI needs to know the identity of the user in certain places (look for getCurrent().get(DbUser.class)). The RESTAPI expects these two things (session and user identity) to be populated by the authentication process, although this doesn't mandate a complete authentication process, that is up to the authentication infrastructure.
Comment 15 Moran Goldboim 2016-11-29 04:42:16 EST
closing this one. since we don't see an immediate need for it.
as a workaround an unanimous user can be created with empty password.
Comment 16 Christophe Fergeau 2016-11-29 04:51:35 EST
Initial request was
"When users log in via User or Webadmin portals, they are given list of domains where their usernames belong. The same is not true for REST API-based apps as they can fetch domain list at /api/domains only after successful authentication, creating a chicken-egg problem."

Even with an anonymous user without a password, we'd have to guess the authentication domain, and maybe the username of that anonymous user (unless it has to be hardcoded to 'anonymous'). In short, I do not think the workaround would work for the initial use case.

Note You need to log in before you can comment on or make changes to this bug.