== Secure Object References

=== Start with the end in mind
Do you have your access control documented? If you don't, how can you enforce it?  Access control is defined
by the business logic that guides the application and/or privacy and other laws.

==== Horizontal and Vertical Access Control
Often times we think of access control in terms of 'roles' (user, power-user, admin, etc.).
However, as noted in the previous exercises, users with the same 'role' can access each other's data. This is
horizontal access control.  Both should be enforced.

.Access Control Matrix Example
|===
|Endpoint | Method | Description | Roles, Access Rules | Notes, Caveats

| /profile
| GET
| view user profile
| Logged in User, can only view their own role
| Admin roles must use diff Url to view others' profiles (see below)

| /profile/{id}
| GET
| view user profile of a given user
| Logged in User can view their own profile by {id}, admins can also view
| n/a

| /profile/{id}
| PUT
| edit user profile. profile object submitted from client with request
| Logged in User can edit their own profile by {id}, admins can also edit.
| Admin edit must be logged
|===

==== Audit Access
As displayed in the above example, your access control rules should include provisions of what access is logged.
For example, if a super-user or admin can edit other's profiles ... That is something that should be logged. Other
examples would include detected violations or attempts to violate access control mechanisms.

=== Using Indrect References
Not many applications employ it, but you can use *indirect* references. In this case you can run your references across a hashing,
encoding or other function on the server so that the id that the client sees is not the actual reference
which the server handles.  This will reduce efficiency some (a common trade-off for security) and is still subject to being
guessed, brute-forced or reverse engineered.

This approach should not be the only protection used. It can be used as an additional layer. Your server must
implement the logic of mapping client (indirect) to server (direct) references.

=== Access Control & APIs
Many time, APIs or RESTFul endpoints rely on obscurity , a static 'key', or lack of imagination on the user's part to control access.
Good options such as digitally signed JSON Web Tokens (https://jwt.io) are a good option for API authentication & access control using a
combination of the claims and a digital/cryptographic signature to validate the consumer.  Other emerging standards such as
Secure Token Binding promise a 'cryptographic state' for web services in the request headers ...
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-10

https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-05

https://tools.ietf.org/html/draft-ietf-tokbind-https-06
