* LDAP: Allow an user to be synchronised against LDAP
This PR introduces the /ldap/sync/:id endpoint. It allows a user to be synchronized against LDAP on demand.
A few things to note are:
LDAP needs to be enabled for the sync to work
It only works against users that originally authenticated against LDAP
If the user is the Grafana admin and it needs to be disabled - it will not sync the information
Includes a tiny refactor that favours the JSONEq assertion helper instead of manually parsing JSON strings.
* API: Add `updatedAt` to api/users/:id
This adds the timestamp of when a particular user was last updated to
the `api/users/:id` endpoint.
This helps our administrators understand when was the user information last
updated. Particularly when it comes from external systems e.g. LDAP
Adds the definition of `GetTeamsForLDAPGroupCommand` which handles the lookup of team information based on LDAP groupDNs.
This is an Enterprise only feature. To diferentiate,a response will contain the `team` key as `null` on OSS while on Enterprise the key will contain an empty array `[]` when no teams are found.
* LDAP: Add API endpoint to query the LDAP server(s) status|
This endpoint returns the current status(es) of the configured LDAP server(s).
The status of each server is verified by dialling and if no error is returned we assume the server is operational.
This is the last piece I'll produce as an API before moving into #18759 and see the view come to life.
* Move the ReloadLDAPCfg function to the debug file
Appears to be a better suite place for this.
* LDAP: Return the server information when we find a specific user
We allow you to specify multiple LDAP servers as part of LDAP authentication integration. As part of searching for specific users, we need to understand from which server they come from. Returning the server configuration as part of the search will help us do two things:
- Understand in which server we found the user
- Have access the groups specified as part of the server configuration
* LDAP: Adds the /api/admin/ldap/:username endpoint
This endpoint returns a user found within the configured LDAP server(s). Moreso, it provides the mapping information for the user to help administrators understand how the users would be created within Grafana based on the current configuration.
No changes are executed or saved to the database, this is all an in-memory representation of how the final result would look like.
* Emails: resurrect template notification
* Phantomjs (oh yeah, there is another dev dep phantom :-) was failing for
the generation of the html templates so I had to update the dependencies
in order to fix it. While doing that I update the scripts field and docs
for it as well. yarn.lock is included
* Move splitting of the emails to separate helper function, since more services
coming up that would need to use this functionality
* Add support for enterprise specific email letters. Probably could
be done in the better way, but it's not a priority right now
* Auth: change the error HTTP status codes
* Use 407 HTTP status code for incorrect credentials error
* Improve proxy auth logs
* Remove no longer needed TODO comment
Fixes#18439
It seems `ldap` module introduced new error type of which
multildap module didn't know about.
This broke the multildap login logic
Fixes#18491
Ref #18587
* SQLite migrations
* cleanup
* migrate end times
* switch to update with a query
* real migration
* anno migrations
* remove old docs
* set isRegion from time changes
* use <> for is not
* add comment and fix index decleration
* single validation place
* add test
* fix test
* add upgrading docs
* use AnnotationEvent
* fix import
* remove regionId from typescript
Existing /api/alert-notifications now requires at least editor access.
Existing /api/alert-notifiers now requires at least editor access.
New /api/alert-notifications/lookup returns less information than
/api/alert-notifications and can be access by any authenticated user.
Existing /api/org/users now requires org admin role.
New /api/org/users/lookup returns less information than
/api/org/users and can be access by users that are org admins,
admin in any folder or admin of any team.
UserPicker component now uses /api/org/users/lookup instead
of /api/org/users.
Fixes#17318
* Do not set SameSite login_error cookie attribute if cookie_samesite is none
* Do not set SameSite grafana_session cookie attribute if cookie_samesite is none
* Update middleware tests
* Fix CreateTeam api endpoint
No team member should be created for requests
authenticated by API tokens.
* Update middleware test
Assert that `isAnonymous` is set for `SignedInUser`
authenticated via API key.
* Add test for team creation
Assert that no team member is created if the signed in user
is anomymous.
* Revert "Fix CreateTeam api endpoint"
This reverts commit 9fcc4e67f5.
* Revert "Update middleware test"
This reverts commit 75f767e58d.
* Fix CreateTeam api endpoint
No team member should be created for requests
authenticated by API tokens.
* Update team test
* Change error to warning and update tests
This commit addresses half of #13749 by making sure GetMetricData
works for alerting. Math Expressions (compound metrics) will still not
work for alerting, this would require a bigger refactoring of Grafana's
alerting service. However, with this commit at least alerting for basic
metrics with non empty query Id will work.
Fixes half of #13749
* Auth: Do not search for the user twice
Previously `initContextWithBasicAuth` did not use `LoginUserQuery`, doing
`GetUserByLoginQuery` only i.e. looking user in DB only, things changed when
this function started to check LDAP provider via `LoginUserQuery` (#6940),
however, this request was placed after `GetUserByLoginQuery`, so we first
looking in DB then in the LDAP - if LDAP user hasn't logged in we will
not find it in DB, so `LoginUserQuery` will never be reached.
`LoginUserQuery` request already performs `GetUserByLoginQuery`
request in correct sequence. So we can just remove redundant request.
* Correct sequence execution during authentification &
introduce tests for it
* Move basic auth tests to separate test file, since main test file already
pretty large
* Introduce `testing.go` for the middleware module
* Remove redundant test helper function
* Make handler names more explicit
Ref 5777f65d05Fixes#18329
* Auth: address review comment
* added alert rule tags in webhook notifications
* fix: don't include whole list of Tag objects but only key/value pairs in Webhook JSON
* marked webhook alerts to support alert rule tags
* Add tests for errors basic auth cases and moves tests to separate test-case.
Also names test cases consistently
* Add additional test helper
Ref 82661b9f69
* LDAP: nitpicks
* Add more tests
* Correct and clarify comment for Login() method
* Rename methods (hail consistency!)
* Uppercases first letter of the logs everywhere
* Moves method definitions around to more appropriate places
Fixes#18295
* Auth: consistently return same basic auth errors
* Put repeated errors in consts and return only those consts as error strings
* Add tests for errors basic auth cases and moves tests to separate test-case.
Also names test cases consistently
* Add more error logs and makes their messages consistent
* A bit of code style
* Add additional test helper
* Auth: do not expose even incorrect password
* Auth: address review comments
Use `Debug` for the cases when it's an user error
The `oauth_state` cookie used to be created with the SameSite value set
according to the `cookie_samesite` configuration.
However, due to a Safari bug SameSite=None or SameSite=invalid are treated
as Strict which results in "missing saved state" OAuth login failures
because the cookie is not sent with the redirect requests to the OAuth
provider.
This commit always creates the `oauth_state` cookie with SameSite=Lax
to compensate for this.
* Auth Proxy: Include additional headers as part of the cache key
Auth proxy has support to send additional user attributes as part of the
authentication flow. These attributes (e.g. Groups) need to be monitored
as part of the process in case of change.
This commit changes the way we compute the cache key to include all of the
attributes sent as part of the authentication request. That way, if we
change any user attributes we'll upsert the user information.
