docs: warden resource names are wrong on apiary

[nikolay-turpitko]

At http://docs.hdyra.apiary.io/#reference/warden:-access-control-for-resource-providers/check-if-an-access-tokens-subject-is-allowed-to-do-something/check-if-an-access-token's-subject-is-allowed-to-do-something

Access Control Requirements
Resource: rn:hydra:warden:token:allowed:<id>

What exactly is <id>? Is it id of another policy which this token allowed to check or something else?

Particularly, we want to create set of policies, to manage access to particular API methods of our app. Like:
token xxx allowed to do GET requests to /api/profile,
token yyy allowed to do also POST requests to /api/profile, etc.

In our middleware we are trying to check if access token from web client allowed to do particular task.

Now we are struggling with policies setup. I understood that we must allow to server-to-server token to do requests to validate other tokens like:
hydra policies create --allow -r "rn:hydra:warden:token:allowed:<[^:]+>" -s "<.*>" -a "decide" --skip-tls-verify (allow everyone to decide). And hydra policies create --allow -r "/api/profile" -s "<.*>" -a "GET" --skip-tls-verify (allow everyone to access particular URL).

With this setup we get 403 Forbidden in Hydra log. What we are missing?
Also, is it allowed to use slashes in resource field?

Is it possible to restrict access to particular URL for some client_id in this request?

[aeneasr]

Sorry for that, this is a classic typo :) The resource is rn:hydra:warden:token:allowed which causes rn:hydra:warden:token:allowed:<[^:]+> to mismatch as it expects something like rn:hydra:warden:token:allowed:a.

I will update the API blueprint later, thanks for the hint!

[nikolay-turpitko]

Please, disregard following comment. I've found an issue. It was due of outdated docker image.

Yet another question about this request. When I send request with some scope in it, it responds with another set of scopes and "allowed": true. Is it intended behavior? Sample:

request:
{"token":"xxx","resource":"rn:xxx","action":"get","scopes":["test.zzz"]}

response:
 {"sub":"","scopes":["core","hydra.keys.get"], ...,"ext":null,"allowed":true}

Here, test.zzz is arbitrary scope which is not in the set of scopes of the client.
Question is: shouldn't response be status 403 Forbidden? Or should API user compare set of scopes himself?

I use dockerized version of Hydra.

Clarification: we fixed setup in accordance with your previous answer, now it works in regard to policies, but seemingly ignores scopes.

[aeneasr]

@nikolay-turpitko so everything good with the recent docker image? There was once a bug with scopes, but it should be resolved on the 0.5.X version

[nikolay-turpitko]

Yes, scopes seems to work as we expect with recent docker image. We have not tested them thoroughly, but, at least, unknown scopes are rejected. Documentation is a bit of an issue though. We had to study sources of hydra, fosite and ladon to understand usage of this API request.

[aeneasr]

Glad to hear that scopes work. All cases are also automatically tested, so I don't think that there will be any more issues.

@nikolay-turpitko it would be great if you could create issues for the parts of the documentation that where not up-to-date or that where hard to understand or incomplete. Documentation is only as good as the people who report issues in it :D

[nikolay-turpitko]

Well, regarding this particular request (http://docs.hdyra.apiary.io/#reference/warden:-access-control-for-resource-providers/check-if-an-access-tokens-subject-is-allowed-to-do-something/check-if-an-access-token's-subject-is-allowed-to-do-something), it, probably, helped if description explicitly says what is the meaning of each argument passed to request and what is expected behavior. I mean, it more or less intuitive now, when we know how it works internally, and observe a correct behavior. But we were puzzled, when observed incorrect behavior and were not sure is it incorrect behavior or we misunderstood how it is supposed to work.

[aeneasr]

Thanks, I will improve this!

[aeneasr]

The docs are now updated. The explanation on the warden will be done in the gitbook documentation.