Access Control

[John Lim]

While not specifically confined to the Cj domain, how should one use Cj to implement access control? For example, given the following Cj

{ "collection" :
  {
    "version" : "1.0",
    "href" : "http://example.org/friends/",


    "links" : [
          {"rel" : "feed", "href" : "http://example.org/friends/rss"}
  ],


    "items" : [
          {
            "href" : "http://example.org/friends/jdoe",
            "data" : [
                  {"name" : "full-name", "value" : "J. Doe", "prompt" : "Full Name"},
                  {"name" : "email", "value" : "jd...@example.org", "prompt" : "Email"}
          ],
            "links" : [
                  {"rel" : "blog", "href" : "http://examples.org/blogs/jdoe", "prompt" : "Blog"},
                  {"rel" : "avatar", "href" : "http://examples.org/images/jdoe", "prompt" : "Avatar", "render" : "image"}
          ]
          },


          {
            "href" : "http://example.org/friends/msmith",
            "data" : [
                  {"name" : "full-name", "value" : "M. Smith", "prompt" : "Full Name"},
                  {"name" : "email", "value" : "msm...@example.org", "prompt" : "Email"}
          ],
            "links" : [
                  {"rel" : "blog", "href" : "http://examples.org/blogs/msmith", "prompt" : "Blog"},
                  {"rel" : "avatar", "href" : "http://examples.org/images/msmith", "prompt" : "Avatar", "render" : "image"}
          ]
          },  
  ],  
    "template" : {
    "data" : [
            {"name" : "full-name", "value" : "", "prompt" : "Full Name"},
            {"name" : "email", "value" : "", "prompt" : "Email"},
            {"name" : "blog", "value" : "", "prompt" : "Blog"},
            {"name" : "avatar", "value" : "", "prompt" : "Avatar"}
    ]
  }
  }
}

Given that that are two roles, "Admin" and "User", where one client requires that  "Admin" is able to modify "full-name" and "email" but "User" is able to edit only "email". I understand that one of the approach would be to omit "full-name" from the template if the request was from a "User". My question is, given that a "User" knows the api, what is preventing the user from generating a Cj with the correct template and POST it to the URI? Unless the backend implements the said access controls, a "User" could potentially alter records. 

Assuming a different client to my service requires that "User" is able to edit "email" but not "full-name", how can I decouple this "access" control from my backend using Cj? How can I support these two clients? It would be impossible for my service to support both of them if I were to couple their access requirements to my backend service. 

Thanks,

John

.  

[mca]

<snip>

My question is, given that a "User" knows the api, what is preventing the user from generating a Cj with the correct template and POST it to the URI? Unless the backend implements the said access controls, a "User" could potentially alter records. 

</snip>

correct -- you are not able to prevent devs from crafting their own requests to servers and attempting operations that are not valid or are possibly harmful. what you can do, however, is make sure the server does not honor those invalid/harmful requests.

<snip>

 It would be impossible for my service to support both of them if I were to couple their access requirements to my backend service. 

</snip>

i have no idea what this sentence means. 

your scenario includes two diff "personas" or "actors" -- "admin" and "user". these are the "contexts" for requests. for example, context A is "the persona making this request is admin". in your example, it is up to the server to establish this context. a user login is proly the best way to do that. 

once the persona is established, your server can enforce whatever context-related workflow or security is appropriate. that can include crafting resource representations that are context-specific (e.g. they only display information valid for that persona, the templates are appropriate for the context, the link collections (for the response and each item) are also appropriate for the context.

and, yes, this is not a Cj-related question -- this problem exists for all web servers. the good news is the solution is the same no matter the representation format -- establish and honor the context of the request.

cheers.

mca

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

--
You received this message because you are subscribed to the Google Groups "Collection+JSON" group.
To unsubscribe from this group and stop receiving emails from it, send an email to collectionjso...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Lim]

Hi Mike,

Thanks for your reply. It clarified the confusion I had.

Regards,

John