Re: [Ace] Ace Digest, Vol 29, Issue 12

[Ludwig Seitz <[e-mail]>]

On 2016-04-19 08:58, Vasu Kantubukta wrote:
> Hi Ludwig Seitz,
>
> I have a quick look on your draft. We are happy even to discuss about
> our draft and can collaborate.
>
> Plz find my few inline comments below:
>
> Actually that draft is not so much about pre-configuring endpoints
> with tokens, the idea behind OAuth is that you supply these tokens on
> demand, i.e. when a client tries to access a resource on a server.
>
> Btw: The reference is wrong, it's now draft-ietf-ace-oauth-authz
>
> ----> Thanks for bringing me to notice the new draft
> "draft-ietf-ace-oauth-authz-01"

----> Yes, these tokens are not
> configured at the endpoints, those are at AS, my doubt is about how
> AS can make dynamic configuration of security policies about RS, and
> clients. Does there be any frequent updates about policies from RS to
> AS.
>

The RS is not supposed to manage policies at the AS. Managing access 
control policies at the AS is the job of the Resource Owner RO (i.e. the 
entity in charge of RS). Since the AS and RO are not considered to be 
constrained devices, normal web tools can be used for that. Furthermore 
since the AS is not constrained it is considered to be connected at all 
times, thus frequent access control policy updates are possible.
How AS are implemented in detail is not in scope for ACE, you might be 
able to get some feedback on that from people at the OAuth WG.

> I'm not sure what you mean with those points. Priority of requests
> and QoS could be parameters that have a bearing on what kind of
> access token you get, but they are certainly out of scope for ACE.
> The operations that clients can perform on the resource are supposed
> to either be encoded in the token, or available through introspection
> by ways of the "scope" of an OAuth token.
>
> ---> Authorization server provides resource access to client by
> giving access tokens to client that includes only security context,
> and kind of protocol access.

The token only includes very few parameters indeed, but the policies the 
AS uses to determine what token a client can get in a specific situation 
can be as complex as you like (e.g. depending on requested QoS or 
whatever else).

Btw: I really don't know what exactly you mean with 'security context' 
and 'protocol access', in order to avoid misunderstandings it would be 
good to get to a common understanding on the terms we use.


---> Suppose RS cannot handle any
> request at that time, and some other similar resource can handle the
> request. Does the RS will update to AS?. If not, then request should
> not be allowed.

You are aware that in some usecases the RS is not even be able to 
communicate with AS?

Note however that an access token might be valid for more than just one 
specific RS, so in the case you describe above, where several RS could 
satisfy the client's request, the AS could issue such a token to the 
client, and the client could contact all the matching RS using the same 
token until it finds one that can satisfy its request.

> Here the check is not happened based on the resource
> management. Only protocol operations like (PUT,POST,GET etc) may not
> be sufficient to distinguish the resource access. Resource oriented
> operations are more appropriate for resource control (for ex. for
> resource IP Camera, the operations allowed are {"turn it up", "turn
> it down", "play", "pause"}).

Such resource oriented operations can be encoded in an access token as 
well using a different set of OAuth scopes. The ACL defined in
draft-bormann-core-ace-aif is just one example specific to protocol 
operations. This will probably pan out for IoT the same way it has for 
Web OAuth: There will be many different application specific uses scope, 
that define resource oriented permissions similar to those you listed 
above.
See https://www.brandur.org/oauth-scope for an overview of how people 
have used scopes differently to implement application/resource specific 
permissions.

> Centralized resource control is required
> to admit client request. On what basis these tokens assigned is very
> important in constrained environments. only based on security context
> is not sufficient to authorize the resource. Authorization should
> include both admission and resource control. There should be some
> decision making required to provide access controls on resource
> access not only just by the security context.

Again it is hard for me to discuss your points unless I know what you 
mean with 'security context', 'admission control' and 'resource 
control'. Could you please clarify these terms?

Note that there is centralized control today in OAuth through the AS.

--> Admission control
> does not have to consider about resource management, but resource
> control should consider. And, any access control mechanism should
> include both admission and resource control. Permission to access a
> resource is an authorization. So, managing and monitoring of access
> controls of a resource is also a part of resource access.
>
> Moreover, other few queries about draft-ietf-ace-oauth-authz-01:
>
--->resource server is involved in processing the access token which
> is supplied as payload from client request. Or in other case, it has
> to construct new introspection request to AS and verify the access
> token of client. Which burdens the resource heavily due to limited
> memory.
--->why can't this be delegated to some intermediate server
> that do access token verification on behalf of RS.

The RS would still have to get the results from the intermediate server 
in a secure way and verify that they are correct.

a.) In some usecases this does not work at all because the RS has no 
connectivity
b.) In most cases I expect that verifying the intermediate servers 
assertions and maintaining a secure connection to this intermediate 
server is going to be at least as burdensome for the RS as just 
verifying token itself.

Note that the idea is that the AS makes an access control decision, 
which is a heavyweight process, it encodes this decision into an access 
token. The RS then only enforces the decision made by the AS, and for 
that it has to verify the token, which is supposed to be a lightweight 
process.

--->Does the RS
> has to do this verification of access request for each client and
> resource request?.
>
Access requests are verified by the AS, the RS only matches the resource 
request against the token to see if the token authorizes this resource 
request.


Regards,

Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone [phone]
http://www.sics.se