Wez Furlong
4055c50522
This commit is a step towards some general improvements around our handling of authentication and authorization. This commit is focused primarily on authorization, but there are some adjustments to how we track authentication as part of enabling that. We now have a separate AuthInfo type that holds the overall authentication information/context associated with an inbound SMTP or HTTP session. It is populated with the peer_address as a fact rather than a statement of trust. If authentication via the appropriate lua auth callback is successful, then the AuthInfo has additional identities added. There are some types and events for loading access control lists and matching their rules against an AuthInfo. There is now a system default ACL that is equivalent to the prior hard-coded access policy that was encoded into each HTTP endpoint. This change makes it possible to replace the ACL with a user-defined ACL. Later will be some work on authentication to allow more options for HTTP auth.
2.5 KiB
tags
| tags | |
|---|---|
|
kumo.aaa.make_http_url_resource
{{since('dev')}}
local resource = kumo.aaa.make_http_url_resource(LOCAL_ADDR, HTTP_URL)
This function can be used to create a resource object that represents an HTTP URL in the HTTP listener. The two parameters are:
LOCAL_ADDR- a string like127.0.0.1:8080defining the local address (NOT the peer address!) of the HTTP listener endpoint. This local address doesn't have to be a loopback address; it should map to the local "sockname" of the connected HTTP session and can be the external/public IP of the local system.HTTP_URL- a URL string likehttps://localhost/api/admin/bazdefining the endpoint to which access is being requested.
The eagle eyed reader will realize that LOCAL_ADDR is somewhat redundant with
the host portion of the URL. They are separate parameters because the
underlying Rust logic needs to process an URL from a live HTTP request and that
may have a hostname supplied by the client. Authorization checks are always
performed using the local address regardless of the hostname coming from the client.
The HTTP URL Resource object encodes the specific resource name that exactly
matches the combination of LOCAL_ADDR and HTTP_URL, but also encodes a list
of fall-back resource names that allow ACL rules to be effectively inherited
when performing ACL checks.
For example, when constructing a resource object like this:
local resource = kumo.aaa.make_http_url_resource(
'127.0.0.1:8080',
'https://localhost/foo/bar/baz'
)
produces a resource object that, when used as part of an ACL query via kumo.aaa.query_resource_access, will cause the following sequence of resource names to be loaded via get_acl_definition until that event returns an ACL:
http_listener/127.0.0.1:8080/foo/bar/bazhttp_listener/127.0.0.1:8080/foo/barhttp_listener/127.0.0.1:8080/foohttp_listener/127.0.0.1:8080http_listener/*/foo/bar/bazhttp_listener/*/foo/barhttp_listener/*/foohttp_listener
You can see that this sequence of resource names corresponds to a tree-like
structure that allows you to, for example, set rules on a very specific
resource path such as http_listener/127.0.0.1:8080/foo/bar/baz that either
widen or narrow the scope of a more general rule that might be defined on a
path such as http_listener/*/foo/bar.
The product default ACLs take advantage of this structure to define a general
access rule for http_listener/*/api/admin.