Projects‎ > ‎

Authorization Check

Overview

Expose an interface, on the OpenPTK Server, that will enable the application (Client) to check / test if a given Operation (CRUDS) is allowed, against a particular Resource, for a given Principal / User.

Requirements

  1. Levergage the existing RESTful Web Service interface provided by the OpenPTK Server
  2. Checks (Test) should be representative of the real Operation against actual Resource
  3. Responses shall return an unambiguous answer related to the authorization check (test)

Design Ideas

This section outlines a number of design options.  Each option would support the following Operations:  CREATE, READ, UPDATE, DELETE, SEARCH.

The curl command line utility is used to "mock-up" the various options.  Each line represents the following operations (in this order)
  • CREATE
  • READ
  • UPDATE
  • DELETE
  • SEARCH

Request Option 1

Leverage the HTTP HEAD Method with HTTP Header variables

curl -X HEAD -H "X-Operation: CREATE" http://server/openptk/contexts/devel/subjects
curl -X HEAD -H "X-Operation: READ"   http://server/openptk/contexts/devel/subjects/ja1324
curl -X HEAD -H "X-Operation: UPDATE" http://server/openptk/contexts/devel/subjects/ja1324
curl -X HEAD -H "X-Operation: DELETE" http://server/openptk/contexts/devel/subjects/ja1324
curl -X HEAD -H "X-Operation: SEARCH" http://server/openptk/contexts/devel/subjects

Pro

  • Leverage an unused HTTP Method (no confusion with existing Methods)
  • No need for query parameters

Con

  • So clients may not easily support HEAD Method
  • Some network security / firewalls may not allow HEAD Method
  • Have to set Header Variable

Request Option 2

Override the "real" HTTP METHOD with a query parameter (flag)

curl -X POST   http://server/openptk/contexts/devel/subjects&isAllowed=CREATE
curl -X GET    http://server/openptk/contexts/devel/subjects/ja1324&isAllowed=READ
curl -X PUT    http://server/openptk/contexts/devel/subjects/ja1324&isAllowed=UPDATE
curl -X DELETE http://server/openptk/contexts/devel/subjects/ja1324&isAllowed=DELETE
curl -X GET    http://server/openptk/contexts/devel/subjects&isAllowed=SEARCH

Pro

  • Uses the actual HTTP METHOD that the "real" operation would execute

Con

  • Have to add a query parameter to indicate the OpenPTK Operation
  • May have issues with networks / firewalls that don't support all these HTTP Methods (PUT, DELETE)
Request Option 3

Use HTTP GET for all checks, with a query parameter (flag)

curl -X GET http://server/openptk/contexts/devel/subjects&isAllowed=CREATE
curl -X GET http://server/openptk/contexts/devel/subjects/ja1324&isAllowed=READ
curl -X GET http://server/openptk/contexts/devel/subjects/ja1324&isAllowed=UPDATE
curl -X GET http://server/openptk/contexts/devel/subjects/ja1324&isAllowed=DELETE
curl -X GET http://server/openptk/contexts/devel/subjects&isAllowed=SEARCH

Pro

  • Uses only the HTTP GET Method, network / firewall friendly

Con

  • Have to add a query parameter to indicate the OpenPTK Operation

Request Option 4

Use a "new" URL ... "authz" instead if "contexts"

curl -X POST   http://server/openptk/authz/devel/subjects
curl -X GET    http://server/openptk/authz/devel/subjects/ja1324
curl -X PUT    http://server/openptk/authz/devel/subjects/ja1324
curl -X DELETE http://server/openptk/authz/devel/subjects/ja1324
curl -X GET    http://server/openptk/authz/devel/subjects

Pro

  • Uses "matching" HTTP Methods, for the related OpenPTK Operations
  • No need for query parameters

Con

  • It is a different URL, Client would have to substitute the key word
  • May have issues with networks / firewalls that don't support all these HTTP Methods (PUT, DELETE)

Response


If the check / test evaluates to ALLOW,  return an HTTP 200: OK Response
If the check / test evaluates to DENY, return an HTTP 401: UNAUTHORIZED Response