Skip to content

Releases: hashicorp/boundary

v0.2.2

19 May 16:06
Compare
Choose a tag to compare

0.2.2 (2021/05/17)

New and Improved

  • Inline OIDC authentication flow: when the OIDC authentication flow succeeds,
    the third-party provider browser window is automatically closed and the user
    is returned to the admin UI.

Bug Fixes

  • oidc: If provider returns an aud claim as a string or []string,
    Boundary will properly parse the claims JSON.
    (issue,
    PR)
  • sessions: Clean up connections that are dangling after a worker dies (is
    restarted, powered off, etc.) This fixes some cases where a session never goes
    to terminated state because connections are not properly marked closed.
    (Issue 1, Issue
    2
    ,
    PR)
  • sessions: Add some missing API-level checks when session cancellation was
    requested. It's much easier than interpreting the domain-level check failures.
    (PR)
  • authenticate: When authenticating with OIDC and json format output, the
    command will no longer print out a notice that it's opening your web browser
    (Issue,
    PR)

v0.2.1

06 May 17:26
Compare
Choose a tag to compare

0.2.1 (2021/05/05)

Deprecations/Changes

  • API delete actions now result in a 204 status code and no body when
    successful. This was not the case previously due to a technical limitation
    which has now been solved.
  • When using a delete command within the CLI we now either show success or
    treat the 404 error the same as any other 404 error, that is, it results
    in a non-zero status code and an error message. This makes delete actions
    behave the same as other commands, all of which pass through errors to the
    CLI. Given -format json capability, it's relatively easy to perform a check
    to see whether an error was 404 or something else from within scripts, in
    conjunction with checking that the returned status code matches the API error
    status code (1).
  • When outputting from the CLI in JSON format, the resource information under
    item or items (depending on the action) now exactly matches the JSON sent
    across the wire by the controller, as opposed to matching the Go SDK
    representation which could result in some extra fields being shown or fields
    having Go-specific types. This includes delete actions which previously
    would show an object indicating existence, but now show no item on success
    or the API's 404 error.
  • Permissions in new scope default roles have been updated to include support
    for list, read:self, and delete:self on auth-token resources. This
    allows a user to list and manage their own authentication tokens. (As is the
    case with other resources, list will still be limited to returning tokens on
    which the user has authorization to perform actions, so granting this
    capability does not automatically give user the ability to list other users'
    authentication tokens.)

New and Improved

  • permissions: Improving upon the work put into 0.2.0 to limit the fields that
    are returned when listing as the anonymous user, grants now support a new
    output_fields section. This takes in a comma-delimited (or in JSON format,
    array) set of values that correspond to the JSON fields returned from an API
    call (for listing, this will be applied to each resource under the items
    field). If specified for a given ID or resource type (and scoped to specific
    actions, if included), only the given values will be returned in the output.
    If no output_fields are specified, the defaults are used. For authenticated
    users this defaults to all fields; for u_anon this defaults to the fields
    useful for navigating to and authenticating to the system. In either case,
    this is overridable. See the permissions
    documentation

    for more information on why and when to use this. This currently only applies
    to top-level fields in the response.

  • cli/api/sdk: Add support to request additional OIDC claims scope values from
    the OIDC provider when making an authentication request.
    (PR).

    By default, Boundary only requests the "openid" claims scope value. Many
    providers, like Okta and Auth0 for example, will not return the standard claims
    of email and name when you request the default claims scope (openid).

    Boundary uses the standard email and name claims to populate an OIDC
    account's Email and FullName attributes. If you'd like these account
    attributes populated, you'll need to reference your OIDC provider's documentation
    to learn which claims scopes are required to have these claims returned during
    the authentication process.

    Boundary now provides a new OIDC auth method parameter claims_scopes which
    allows you to add multiple additional claims scope values to an OIDC auth
    method configuration.

    For information on claims scope values see: Scope Claims in the OIDC
    specification

  • cli: Match JSON format output with the across-the-wire API JSON format
    (PR)

  • api: Return 204 instead of an empty object on successful delete operations
    (PR)

  • actions: The new no-op action allows a grant to be given to a principals
    without conveying any actionable result. Since resources do not appear in list
    results if the principal has no actions granted on that resource, this can be
    used to allow principals to see values in list results without also giving
    read or other capabilities on the resources. The default scope permissions
    have been updated to convey no-op,list instead of read,list.
    (PR)

  • cli/api/sdk: User resources have new attributes for:

    • Primary Account ID
    • Login Name
    • Full Name
    • Email

    These new user attributes correspond to attributes from the user's primary
    auth method account. These attributes will be empty when the user has no
    account in the primary auth method for their scope, or there is no designated
    primary auth method for their scope.

  • cli: Support for reading and deleting the user's own token via the new
    read:self and delete:self actions on auth tokens. If no token ID is
    provided, the stored token's ID will be used (after prompting), or "self"
    can be set as the value of the -id parameter to trigger this behavior
    without prompting. (PR)

  • cli: New logout command deletes the current token in Boundary and forgets it
    from the local system credential store, respecting -token-name
    (PR)

  • config: The name field for workers and controllers now supports being set
    from environment variables or a file on disk
    (PR)

Bug Fixes

  • cors: Fix allowing all origins by default
    (PR)
  • cli: It is now an error to run boundary database migrate on an uninitalized db.
    Use boundary database init instead.
    (PR)
  • cli: Correctly honor the -format flag when running boundary database init
    (PR)

v0.2.0

15 Apr 00:59
Compare
Choose a tag to compare

0.2.0 (2021/04/14)

Deprecations/Changes

  • The auth-methods/<id>:authenticate:login action is deprecated and will be
    removed in a few releases. (Yes, this was meant to deprecate the
    authenticate action; apologies for going back on this!) To better support
    future auth methods, and especially the potential for plugins, rather than
    defining custom actions on the URL path the authenticate action will consume
    both a map of parameters but also a command parameter that specifies the
    type of command. This allows workflows that require multiple steps, such as
    OIDC, to not require custom subactions. Additionally, the credentials map in
    the authenticate action has been renamed attributes to better match other
    types of resources. credentials will still work for now but will be removed
    in a few releases. Finally, in the Go SDK, the Authenticate function now
    requires a command value to be passed in.
  • Related to the above change, the output of an API
    auth-methods/<id>:authenticate call will return the given command value
    and a map of attributes that depend on the given command. On the SDK side, the
    output of the Authenticate function returns a map, from which a concrete
    type can be easily umarshaled (see the updated authenticate password command
    for an example).
  • Anonymous scope/auth method listing: When listing auth methods and scopes
    without authentication (that is, as the anonymous user u_anon), only
    information necessary for navigation to an auth method and authenticating to
    the auth method is now output. Granting u_anon list access to other resource
    types will not currently filter any information out.

New and Improved

  • cli/api/sdk: New OIDC auth method type added with support for create, read,
    update, delete, and list (see new cli oidc subcommands available on CRUDL
    operations for examples).
    PR
  • cli: support to login using an OIDC auth method (see the new authenticate password oidc subcommand for an example)
    PR
  • server: When performing recursive listing, list action is not longer
    required to be granted to the calling user. Instead, the given scope acts as
    the root point (so only results under that scope will be shown), and list
    grant is evaluated per-scope.
    PR
  • database init: If the database is already initialized, return 0 as the exit
    code. This matches how the database migrate command works.
    PR

Bug Fixes

  • server: Roles for auto generated scopes are now generated at database init.
    PR
  • cli: Don't panic on certain commands when outputting in json format
    (Issue,
    PR)

v0.1.8

10 Mar 16:09
c0f33f9
Compare
Choose a tag to compare

0.1.8 (2021/03/09)

Changes/Deprecations

  • api: A few functions have changed places. Notably, instead of ResponseMap()
    and ResponseBody(), resources simply expose Response(). This higher-level
    response object contains the map and body, and also exposes StatusCode() in
    place of indivdidual resources.
    PR
  • cli: In json output format, a resource item is now an object under the
    top-level key item; a list of resource items is now an list of objects under
    the top-level key items. This preserves the top level for putting in other
    useful information later on (and the HTTP status code is included now).
    PR
  • cli: In json output format, errors are now serialized as a JSON object with
    an error key instead of outputting normal text
    PR
  • cli: All errors, including API errors, are now written to stderr. Previously
    in the default table format, API errors would be written to stdout.
    PR
  • cli: Error return codes have been standardized across CLI commands. An error
    code of 1 indicates an error generated from the actual controller API; an
    error code of 2 is an error encountered due to the CLI command's logic; and
    an error code of 3 indicates an error that was caused due to user input to
    the command. (There is some nuance sometimes whether an error is really due to
    user input or not, but we attempt to be consistent.)
    PR

New and Improved

  • list filtering: Listing now supports filtering results before being returned
    to the user. The filtering takes place server side and uses boolean
    expressions against the JSON representation of returned items. See the
    documentation

    for more details. (PR 1)
    (PR 2)
    (PR 3)
  • server: Officially support reloading TLS parameters on SIGHUP. (This likely
    worked before but wasn't fully tested.)
    (PR)
  • server: On SIGHUP, worker
    tags
    will be
    re-parsed and new values used
    (PR)
  • server: In addition to the existing tls_min_version listener configuration
    value, tls_max_version is now supported. This should generally be left blank
    but can be useful for situations where e.g. a load balancer has broken TLS 1.3
    support, or does not support TLS 1.3 and flags it as a disallowed value.

v0.1.7

16 Feb 20:14
Compare
Choose a tag to compare

Release boundary v0.1.7

v0.1.6

12 Feb 21:55
Compare
Choose a tag to compare

Release boundary v0.1.6

v0.1.5

01 Feb 16:38
Compare
Choose a tag to compare

Release boundary v0.1.5

v0.1.4

05 Jan 15:39
Compare
Choose a tag to compare

Release boundary v0.1.4

v0.1.3

18 Dec 20:11
b5d8449
Compare
Choose a tag to compare

Release boundary v0.1.3

v0.1.2

17 Nov 17:48
d802084
Compare
Choose a tag to compare

Release boundary v0.1.2