OverviewExpose 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- Levergage the existing RESTful Web Service interface provided by the OpenPTK Server
- Checks (Test) should be representative of the real Operation against actual Resource
- Responses shall return an unambiguous answer related to the authorization check (test)
Design IdeasThis 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 1Leverage 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
- Uses the actual HTTP METHOD that the "real" operation would execute
- 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
- Uses only the HTTP GET Method, network / firewall friendly
- 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
- Uses "matching" HTTP Methods, for the related OpenPTK Operations
- No need for query parameters
- 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
|