* mod: remove unnecessary import groupings
Move all imports into one of two groupings:
1. Direct dependencies
2. Indirect dependencies
This is the standard used by the go tool. The old groupings
seemed very random.
* mod: update go-plugin dependency
* refact: to use go-dbw CreateItems, DeleteItems
Latest version of go-dbw updated the signature of
CreateItems(...) and DeleteItems(...) on a happy
note this latest version of go-dbw actually does
batch inserts and updates for this functions.
* all: regenerate protos with new protoc-gen-go version
* api: remove deprecated grant_scope_id field
The grant_scope_id field was deprecated in 0.15.0, so we can remove
it for 0.17.0.
* Fix tests
* Fix more tests
* Remove an option and some related code that stuck around
* Fix bats tests
---------
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
* oss:feat(storage): add observation tag in proto for telemetry
* oss:feat(storage): add observation tag in proto service
* oss:feat(storage): generate proto files with changes
* oss:feat(storage): add storage bucket id to target proto
* Add observation tags to session_recording.proto
* remove scope_info observation tags
* Remove quotes and add tag to storage_bucket_id
* Add tags for session recording service
* Update proto definitions
- Remove gotags on messages
- Remove quotes
* internal/gen: better API docs
Add various pieces of metadata that can be used by the API docs renderer.
Improve the service labels by specifying explicit tags.
Specify error responses. Specify version at generation time.
* internal/gen: add better errors
The default error entry is now used to cover all errors, as
adding a new error for every possible status code was a bit much.
This also properly includes the real error type now!
* Add various pieces of metadata that can be used by the API docs renderer. Improve the service labels by specifying explicit tags.
* make auth method API docs
* make API docs better
* make auth methods API docs nicer
* internal/gen: better attribute examples
Replace Output Only comments with a field behavior annotation in accounts.
Mark some fields as required.
Add elaborate description for attributes.
* Make API docs better
* Make API docs better
* Make API docs better
* internal/proto: regenerate files
* internal/proto: finish off account service
* Make API docs better
* internal/proto: add better API docs for aliases
* Tidy up service descriptions
* Added description for Boundary controller API doc
* internal/gen: add better API intro
Copy parts of the API docs into the description
* sdk: add openapi dependency
* internal/gen: move global API doc to separate file
* internal/gen: remove required annotations
Unfortunately, while these help with the creating of resources, they still
appear required in contexts where they are not, such as when
updating a resource.
* Review comments
---------
Co-authored-by: jigar-hashicorp <jigar.shah@hashicorp.com>
Co-authored-by: Isaac Christian (he/him) <112639904+isaacchristian@users.noreply.github.com>
* Add aliases to target resource and alias resolution to target service
* Wire up the target alias domain package to the target service handler
* Adding alias resolution to target api tests
This allows arbitrary programs to have an easy mechanism to make
connections through Boundary using Go. Internal cluster tests and test
helpers have been migrated to use this package, as well as the `connect`
command.
---------
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Boundary OIDC method does not currently support passing in prompts during authentication. This change adds the capability of passing OIDC prompts. Prompts are optional OIDC parameters that determine the behaviour of the authentication server: https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
## Changes
- New `auth_oidc_prompt` table which contains all the prompts for OIDC auth method
- New `auth_oidc_prompt_enm` table which contains possible enum values for a prompt
- Currently supported:
- `none`:
The Authorization Server MUST NOT display any authentication or consent user interface pages
- `login`: The Authorization Server SHOULD prompt the End-User for reauthentication
- `consent`: The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client
- `select_account`: The Authorization Server SHOULD prompt the End-User to select a user account
- `oidc_auth_method_with_value_obj` view has been updated to return `prompt` value
- Add `prompt` option for OIDC auth method CLI create and update
- Pass configured prompt during OIDC authentication
- Add `prompt` API validation for create and update
In preparation for putting proxy code in the api package this creates some necessary fields in the target output and it pre-moves credential parsing and proxy handshake code to their new places. This will make the diff for the actual proxy code move quite a bit smaller.
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* feat (auth/ldap): add Repo support for max page size and deref aliases (#3670)
* chore: update cap/ldap dependency
This latest version of cap/ldap adds support for MaxPageSize and
DerefAliases
* feat (auth/ldap): add MaxPageSize and DerefAliases to storage proto
* feat (api/authmethods): add new ldap fields.
Add support for maximum_page_size and dereference_aliases
* feat (auth/ldap): schema changes to support new LDAP attributes
* feat (auth/ldap): add Repo support for max page size and deref aliases
* feat (handlers/ldap): add support for new fields (#3674)
Added API support for new ldap fields: MaximumPageSize and
DereferenceAliases
* chore: add CHANGELOG entry for new api auth ldap fields
This allows specifying multiple IDs in grants via an `ids` field, which
will eventually become the normal way to specify IDs. Internally, each
grant with multiple IDs turns into multiple ACL grants each with a
single ID; to make this distinction clearer and allow for better
separation of concerns an AclGrant type has been introduced, so really
multiple IDs in a Grant turn into multiple AclGrants.
The nice thing about doing it this way is that it becomes purely a
parsing concern; no actual validation logic has changed.
For backwards compatibility with grants already stored in roles, we do
not error out if `id` is specified. However, eventually we will simply
not support grants with `id` coming via the API; they will fail API
validation, such that new grants will require the use of the updated
`ids` field.
A follow-on PR will plumb this through the service handlers/API/CLI, but
I decided to do it in separate chunks to make reviewing easier, given
that they are easily separable into the internal and external aspects of
the change.
* Add CLI/API checks around using ID in grants (#3264)
* Plumb through some contexts to remove a lot of deprecated errors (#3268)
* proto: correct classification of authz token
The target authorization token had the invalid classification
"private". Fortunately, classification is a fail-closed system,
so this won't have exposed users authorization tokens, but
we should still use the correct classification. Use "secret".
* scripts: add Go script to remove gotags comments
The new version of grpc-gateway includes our gotags
comments in the generate swagger documentation. This
script removes all mentions of these.
* Upgrade grpc-gateway dependency
Mainly we need this to fix generation of our docs side API docs,
but it also includes a nice fix for the new Download RPC, i.e. it
now contains the correct response schema (a binary stream).