Bug 1009843
| Summary: | [RFE] [REST-API]: Implement public queries in API | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | David Jaša <djasa> |
| Component: | RFEs | Assignee: | Ravi Nori <rnori> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | --- | CC: | amureini, bazulay, bugs, cfergeau, gklein, iheim, juan.hernandez, lpeer, mgoldboi, nbarcet, oourfali, oramraz, rbalakri, Rhev-m-bugs, rnori, sbonazzo, shireesh, srevivo, ykaul |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | Flags: | ylavi:
ovirt-future?
rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack? |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-29 09:42:16 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1026718, 1027210, 1132506 | ||
*** Bug 958874 has been marked as a duplicate of this bug. *** please define the list of the entities that should/can be fetched without auth. Authentication and authorization is outside of the scope of the RESTAPI now, but managed by the authentication infrastructure and the backend. 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? 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. (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. (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 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. *** Bug 1132241 has been marked as a duplicate of this bug. *** *** Bug 1138598 has been marked as a duplicate of this bug. *** 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? In 3.6 I would like the runPublicQuery use context of guest user, so it be a standard query that is permitted to guest. 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. 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. 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. |
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