This adds API tokens as a new credential type. Their format is:
`oh.<name>.<random chars>`
The "oh." prefix is used to tell them apart from a JWT access token,
because they're both used as a Bearer authorization scheme, but there
is no semantic value attached to any of the other parts.
They are stored hashed in the user's profile, and can be listed, added
or removed managed with the new `openhab:users` console command.
Currently the scopes are still not checked, but ultimately they could
be, for instance a scope of e.g. `user admin.items` would mean that the
API token can be used to perform user operations like retrieving info
or sending a command, _and_ managing the items, but nothing else -
even if the user has more permissions because of their role (which
will of course still be checked).
Tokens are normally passed in the Authorization header with the Bearer
scheme, or the X-OPENHAB-TOKEN header, like access tokens.
As a special exception, API tokens can also be used with the Basic
authorization scheme, **even if the allowBasicAuth** option is not
enabled in the "API Security" service, because there's no additional
security risk in allowing that. In that case, the token should be
passed as the username and the password MUST be empty.
In short, this means that all these curl commands will work:
- `curl -H 'Authorization: Bearer <token>' http://localhost:8080/rest/inbox`
- `curl -H 'X-OPENHAB-TOKEN: <token>' http://localhost:8080/rest/inbox`
- `curl -u '<token>[:]' http://localhost:8080/rest/inbox`
- `curl http://<token>@localhost:8080/rest/inbox`
2 REST API operations were adding to the AuthResource, to allow
authenticated users to list their tokens or remove (revoke) one.
Self-service for creating a token or changing the password is more
sensitive so these should be handled with a servlet and pages devoid
of any JavaScript instead of REST API calls, therefore for now they'll
have to be done with the console.
This also fixes regressions introduced with #1713 - the operations
annotated with @RolesAllowed({ Role.USER }) only were not authorized
for administrators anymore.
* Generate a unique salt for each token
Reusing the password salt is bad practice, and changing the
password changes the salt as well which makes all tokens
invalid.
Put the salt in the same field as the hash (concatenated
with a separator) to avoid modifying the JSON DB schema.
* Fix API token authentication, make scope available to security context
The X-OPENHAB-TOKEN header now has priority over the Authorization
header to credentials, if both are set.
* Add self-service pages to change password & create new API token
Signed-off-by: Yannick Schaus <github@schaus.net>
* Allow basic authentication to authorize API access
Closes#1699.
Note, this opens a minor security issue that allows an attacker
to brute force passwords by making calls to the API - contrary to
the authorization page, the credentials parsing for the REST API
is stateless & doesn't have a lock mechanism to lock user accounts
after too many failed login attempts.
Signed-off-by: Yannick Schaus <github@schaus.net>
Catch specific exceptions and don't log errors but instead add an appropriate message and preserve the stacktrace.
Signed-off-by: Wouter Born <github@maindrain.net>
Currently the AuthFilter will try to find a token in the
X-OPENHAB-TOKEN HTTP header - only when it finds a cookie
named X-OPENHAB-AUTH-HEADER. It can cause problems because
browsers or proxies might block the cookie from being sent
for various reasons (for instance if there's a path set
for it).
There is no downside IMHO to always try to fallback to
checking the X-OPENHAB-TOKEN header for a token, if and
only if it's not already provided in the Authorization
header. It is the responsibility of the client to decide
how it wants to authorize the request among the available
options - by checking a cookie, or something else entirely.
Also removed the '?api_key=' option because Swagger UI
doesn't provide tokens that way anymore.
Signed-off-by: Yannick Schaus <github@schaus.net>
* Migrate to JAX-RS Whiteboard
* Upgrade Jackson and Swagger TP feature dependencies
The upstream JAX-RS Whiteboard feature is not used because the version ranges currently do not work with Karaf on Windows.
See: https://issues.apache.org/jira/browse/KARAF-6536
* Update Felix logback to 1.0.2
This version adds the jul-to-slf4j bridge (FELIX-6027).
JUL is used by CXF and using the bridge we can use logback to reduce the verbosity of the info logging whenever org.apache.cxf.endpoint.ServerImpl creates endpoints.
* Update Aries Whiteboard to 1.0.8
* Removes the hated default web application (ARIES-1931)
* Improves performance
* Uses CXF 3.2.12
* Don't reuse SSE event builders
SSE event builders are not thread-safe.
It also causes the wrong default values being used.
Also-by: Markus Rathgeb <maggu2810@gmail.com>
Signed-off-by: Wouter Born <github@maindrain.net>
* add project for publisher
* add unmodified com.eclipsesource.jaxrs.publisher sources
* modify and use modified publisher
* drop tracker usage (only for custom whitelist by fragments)
* add the new code to new classes and namespace
Also-by: Kai Kreuzer <kai@openhab.org>
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
