How should I make different data & operations available per role?

[Lance N.]

In general, what is the best way to make different resources (data and operations) available to clients with different roles?

The context: this set of APIs is for a small, specialized company doing applications with very strict security requirements. Our internal and customer-visible web apps are probably the only users for awhile. (My experience has been that customers don't want to code).

If we demarcate role visibility at the resource level, that makes for a lot of resources. If we apply role visibility to within returned data, then the same client code will receive different data for different users. This sounds like a very bad idea. If we apply role visibility to the parameters used in creating or updating resources, then our code has a lot of options to check. Given all of this, applying role visibility to resources makes a lot of sense.

We would like to not divulge the existence of resources that the client's role(s) cannot access. Yes, this is security by obscurity. It also makes the "_links" blocks much smaller.

Are there other ways to do this? Does anyone have war stories of solutions that did or did not work?

TIA

Lance Norskog

[Dietrich Schulten]

It depends :o)

In fact, we  use resources with lists of possible actions per role, and the resources are in part not uniform, some have detail attributes which are not available on others. We can assume however that some attributes are always there.
The client handles this by expecting dynamic lists of actions, it makes menus from them (simple). The details display is programmed to show what is there (not so simple). We apply display templates which follow an all or nothing approach, i.e. if there are no sufficient data for an item, the entire item is skipped, and we have the possibility to define fallbacks. In our case, that was worth the effort since we need all kinds of decorations, layouts, fallback texts depending on the type of resource.

So it is not immediately obvious to me why it seems a bad idea to have the difference within the resource.

I'm not saying this is the single best way, but once we accepted the necessity to have powerful templates for the client ui, things fell into place for us. Can you give us more details about your use case, and why you think having different resources is better?

Best regards
Dietrich

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group, send email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
 
 

[Mike Kelly]

On Sun, Dec 30, 2012 at 8:16 AM, Dietrich Schulten
<dietrich...@googlemail.com> wrote:
> It depends :o)
>
> In fact, we use resources with lists of possible actions per role, and the
> resources are in part not uniform, some have detail attributes which are not
> available on others. We can assume however that some attributes are always
> there.
> The client handles this by expecting dynamic lists of actions, it makes
> menus from them (simple). The details display is programmed to show what is
> there (not so simple). We apply display templates which follow an all or
> nothing approach, i.e. if there are no sufficient data for an item, the
> entire item is skipped, and we have the possibility to define fallbacks. In
> our case, that was worth the effort since we need all kinds of decorations,
> layouts, fallback texts depending on the type of resource.
>
> So it is not immediately obvious to me why it seems a bad idea to have the
> difference within the resource.

The main reason is that it severely limits your ability to cache the
representation, because the variance isn't visible to intermediaries.
So in practice this means a reverse proxy cache like varnish is
useless for any resource which behaves this way.

For this reason, I prefer to pull out and isolate the variance into a
"permissions" resource which I can link to and/or inject into the
representation with edge side includes. This means the main resource
can be consistent for all clients (and is therefore cacheable), and
the variance is isolated to a small resource that also gives you a
natural place for client and server to focus on
how-variance-is-dealt-with.

Of course, if you are genuinely concerned about reducing the "noise"
in your representations, then that might not work for you.. although
that concern is sometimes a smell indicative of poor granularity of
resources.

HTH

Cheers,
M

[Felipe Sere]

Correct me if I am wrong, but if you use something like OAuth2 with an Authorization header all kinds intermediaries (aside from LoadBalancers, IIRC) are out of the loop anyway. 

We use OAuth to check roles and then act based upon that. Though we primarily on do authorisation (allowing/denying access based on a role)…

Cheers.

 

[Mike Kelly]

It depends where your auth layer is relative to your caching layer
i.e. if your auth layer in front of your caching layer then you're
still good. The approach can also benefits in-memory caching too.
Also, it's not always the case that the resource is non-public.

It is possible that these concerns around caching are not applicable
to your app, I just brought it up since that is the main reason
variability of resources can be considered a bad thing.

Cheers,
M

--
Mike

http://twitter.com/mikekelly85
http://github.com/mikekelly
http://linkedin.com/in/mikekelly123

[Dietrich Schulten]

Good point, Mike.  Thank you.
Cheers,
Dietrich

[Dietrich Schulten]

The reason it works for us is, we must revalidate with etags anyway because of the nature of our data but send back not modified as long as the data did not change, so usually the cache can be used which normally gains us quite an improvement. The cases where the role changes are rare and handled by revalidation.
So it works for us, but that is a special case. Having a separate resource for role dependent stuff is certainly the cache-friendlier approach. Still I wanted to mention that caching is still possible for a single resource as long as the role rarely changes and you revalidate anyway.
Cheers,
Dietrich

[Lance Norskog]

Thank you, I did not think about caching.

My personal objection to having variable resources is that this is a
small project with a small client base. We will not have online docs for
what resources are available, why they appear in some responses and not
others, etc. Everyone will just read the code. In this environment
having resource contents change accd. to the role will be confusing and
a time-waster.

There are not very many resources at this point. I will use role-based
resources. If we have an explosion of role-based resources we will
reconsider this design.

Thanks for your time,

Lance