nisavid / bedframe Goto Github PK

secure:

• authz is determined for identities ascertained by secure auth.
• each user and subsystem can be restricted to operate with a narrowly defined set of privileges. an operation is allowed only if both the user and the subsystem have sufficient privileges.
• privileges are determined by an authorization authority, not by application code.

extensible:

• the interface is simple: check for particular privileges (with the user, the subsystem, or both together), require particular privileges (likewise). every conceptual privilege is encoded as a privilege that is verifiable by the authority. privileges are only additive.
• privileges can be managed with few or no limitations. for example, adding support for new privileges requires the application code to only request the new privileges and handle their availability accordingly; code for handling other privileges needs not be affected.

decoupled:

• the association of privileges with users and subsystems is the responsibility of the authority. application code cannot inspect or alter this procedure.
• security mechanisms used during authorization (e.g. hashing algorithms) are implementation specific.

use HTTP status 202 Accepted.

skip startup resolution for especially complex process templates. provide a means for the service to set which process templates should be resolved on startup.

use WADL?

in principle, transport encryption (mainly TLS) can provide sufficient security for even plain auth (commonly HTTP Basic). however, transport encryption is often disabled, misconfigured, configured to use insecure or questionable mechanisms, or handled inappropriately by clients or users. older versions of common protocols and mechanisms, which have known vulnerabilities, are still commonly deployed. if the security of auth depends on the security of transport encryption, then vulnerabilities in the latter imply vulnerabilities in the former, which can be very bad. ideally, auth security should not be contingent on transport encryption security.

required security provisions:

• secrets are never transmitted unencrypted (transport encryption does not count).
• handshake uses server-side nonce.
• handshake uses client-side nonce.

example: attempt session login alongside existing session ID.

an auth process constraint is a tuple of the form (connector class, process connection affordance set, connector class). a process plan template has an auth process constraint set. the authenticator resolves each connection according to the matched constraints, matching connection endpoints via isinstance().

support these settings:

• allowed IP addresses (also use this when starting the service) (default *)
• whether to allow the local hostname (socket.gethostname()) and FQDN (socket.getfqdn()) (default yes)
• whether to allow all detected hostnames of each allowed IP address ((socket.gethostbyaddr()[0],) + socket.gethostbyaddr()[1]) (default yes)
• whether to allow all detected equivalent IP addresses of each allowed IP address (socket.gethostbyaddr()[2]) (default yes)
• allowed additional hostnames (default empty)

use HTTP headers Accept-Ranges and Range.

the goal here is to handle requests for URIs of the form resource.ext, where

• resource is an existing resource URI,
• ext is a recognized file extension with a corresponding mediatype, and
• the requested web method supports the inferred mediatype for its response content.

in such a scenario, the requested web method should be treated as only supporting the inferred mediatype for its response content.

in other words, if the client's acceptable media ranges (according to the Accept header) include the inferred mediatype, then the response content type should be that mediatype. if not, then the response should be a NoAcceptableMediaType exception (in HTTP, 406 Not Acceptable).

Bedframe should provide a default mapping of file extensions to media types, as well as some means to customize this mapping.

some web methods return representations whose media types are parametric. currently, a web method that supports more than one combination of media type param values must define a separate representation function for each combination (actually, for best results, one for each permutation).

when encountering a parametrized media type, Bedframe should parse out the params and pass them into the corresponding repr method. this way, only one repr method is needed for each (unparametrized) repr type.

use this to obey HTTP Expect: 200-ok.