lingwei.kong/hawkbit
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

Add multi-user support (#829)

Browse Source 
This allows optionally configuring multiple static users with varying
permissions. If used, Spring Security user/password are ignored.
Otherwise, the old behavior is retained.

Signed-off-by: Stefan Schake <stefan.schake@devolo.de>
This commit is contained in:
Stefan Schake
2019-05-21 11:09:58 +02:00
committed by Dominic Schabel
parent d34e7f35c5
commit 7c04ca1967
5 changed files with 179 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
docs/content/concepts/authorization.md
View File

@@ -9,7 +9,7 @@ Authorization is handled separately for _Direct Device Integration (DDI) API_ an
However, keep in mind that hawkBit does not offer an off the shelf authentication provider to leverage these permissions and the underlying multi user/tenant capabilities of hawkBit. Check out [Spring security documentation](http://projects.spring.io/spring-security/) for further information. In hawkBit [SecurityAutoConfiguration](https://github.com/eclipse/hawkbit/blob/master/hawkbit-autoconfigure/src/main/java/org/eclipse/hawkbit/autoconfigure/security/SecurityAutoConfiguration.java) is a good starting point for integration.
The default implementation is single user/tenant with basic auth and the logged in user is provided with all permissions.
The default implementation is single user/tenant with basic auth and the logged in user is provided with all permissions. Additionally, the application properties may be configured for multiple static users; see [Multiple Users](#multiple-users) for details.
## DDI API
An authenticated target is permitted to:
@@ -21,6 +21,26 @@ A target might be permitted to download artifacts without authentication (if ena
## Management API and UI
### Multiple Users
hawkBit optionally supports configuring multiple static users through the application properties. In this case, the user and password Spring security properties are ignored.
An example configuration is given below.
hawkbit.server.im.users[0].username=admin
hawkbit.server.im.users[0].password={noop}admin
hawkbit.server.im.users[0].firstname=Test
hawkbit.server.im.users[0].lastname=Admin
hawkbit.server.im.users[0].email=admin@test.de
hawkbit.server.im.users[0].permissions=ALL
hawkbit.server.im.users[1].username=test
hawkbit.server.im.users[1].password={noop}test
hawkbit.server.im.users[1].firstname=Test
hawkbit.server.im.users[1].lastname=Tester
hawkbit.server.im.users[1].email=test@tester.com
hawkbit.server.im.users[1].permissions=READ_TARGET,UPDATE_TARGET,CREATE_TARGET,DELETE_TARGET
A permissions value of `ALL` will provide that user will all possible permissions. Passwords need to be specified with the used password encoder in brackets. In this example, `noop` is used as the plaintext encoder. For production use, it is recommended to use a hash function designed for passwords such as *bcrypt*. See this [blog post](https://spring.io/blog/2017/11/01/spring-security-5-0-0-rc1-released#password-storage-format) for more information on password encoders in Spring Security.
### Delivered Permissions
- READ_/UPDATE_/CREATE_/DELETE_TARGETS for:
- Target entities including metadata (that includes also the installed and assigned distribution sets)