-
Notifications
You must be signed in to change notification settings - Fork 123
Apigility - Authentication - Per Api authentication adapter - Authorization problem #104
Comments
Some throughs about this issue: When enabling an authentication adapter for a given API (let's say a basic authentication adapter), any API call will require an authentication, even if some HTTP methods are not put under authentication. This is the current behavior at least which doesn't fit with the apigility REST tutorial. This behavior is due to the fact that the authentication process occurs before the authorization process. The authentication listener know nothing about authorization rules. What we could expect If not authentication data are provided in the request, the authentication should result in a guest identity (which is the case), but because the authentication result from the http basic adapter (bad credential result) is added to the MvCAuth event (which is checked later on), we end with an 401 unauthorized response and thus, the authorization rules are not checked (from my point of view, a method that is not put under authentication means that a guest can access it without authenticating). To resume In case not authentication data are provided in the request, the authentication result from the basic http adapter should not be set on the MvcAuth event. By doing this, the authentication listener would simply return. Note: Even more, in case no authentication data are provided, the basic httpd adapter should not been involved and a simple guest identity should be returned. However from my point of view, this is not really good because the lead to confusion when authorization get rejected too (we now have forbiden response when in fact, we would ask the user to authenticate). For me, enabling an authentication adapter for a specific API should only mean that in case a HTTP method is put under authentication, that adapter should be used. Thus, in case a guest (unauthenticated user) user try to call method which is put under authentication (as stated in the apigility authorization tab), it should receive a 401 response and not a 403 response. The 403 response would be fine if apigility could handle per identity permissions out of box, but currently, this is not the case. For apigility, authentication process could be
About apigility authorization process Depending on how you see things, you could send a 401 unauthorized response instead of a 403 Forbidden response in case an user is not authenticated (guest user) and the called HTTP method is put under authentication (require authentication). |
As you asked me on IRC, I provide result with cURL: nuxwin@dev:~/Bureau/imscp-git$ curl -i 127.0.0.1:8080/status
HTTP/1.1 401 Unauthorized
Host: 127.0.0.1:8080
Connection: close
X-Powered-By: PHP/5.6.11-1~dotdeb+7.1
Content-Type: application/problem+json
WWW-Authenticate: Basic realm="api"
{"type":"http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html","title":"Unauthorized","status":401,"detail":"Unauthorized"} nuxwin@dev:~/Bureau/imscp-git$ curl -i -u nuxwin 127.0.0.1:8080/status
Enter host password for user 'nuxwin':
HTTP/1.1 200 OK
Host: 127.0.0.1:8080
Connection: close
X-Powered-By: PHP/5.6.11-1~dotdeb+7.1
Content-Type: application/json; charset=utf-8
{"0":{"id":1,"message":"Hello World","timestamp":null,"user":"nuxwin"},"1":{"id":"3b7e0cb2-0565-4645-8512-ed9b86c85bd3","message":"First post","timestamp":null,"user":"mwop"},"2":{"id":"2fd4e0fa-e9dd-461d-b0c3-18e29081c155","message":"Second post","timestamp":null,"user":"mwop"},"3":{"id":"7a85d61b-5d18-490e-aecd-830452737cc5","message":"Test validation","timestamp":null,"user":"mwop"}} |
Hello
I've tested the apigility REST tutorial and it seem that there is a bug in the authentication process.
In the tutorial, we create a Basic HTTP authentication adapter and we enable it for the "Status" api. Once done we setup autorizations for some Http methods.
As I understand the tutorial, we should be able to access the status collection (GET) without authenticating but in fact, we cannot.
We always receive the following answer:
but when we disable the authentication adapter, all is working as it should (including authorization per HTTP methods). Here, we are back to the andy authentication adapter (per application adapter). The problem with that is that now, we cannot select a specific authentication adapter for a specific API.
For instance:
With that configuration snipped, which is automatically put in the global.php configuration file, the following configuration snippet from the moduls.config.php file doesn't longer work as expected:
Here, I would expect no authentication for the collection GET HTTP method.
To resume, for the following API call:
Current result
Expected result
The text was updated successfully, but these errors were encountered: