Guidance on auth

[jeremy303]

I'm unable to find any documentation regarding authentication and authorization for FROST. Is there any documentation available?

I did notice the "keycloak" and "basicAuth" branches, however both of these branches are stale. If these stale branches are the advised path for securing FROST, could these auth features be integrated into master as configurable options?

I understand that FROST is used in production at Fraunhofer and I expect elsewhere, so how is auth addressed in the production systems?

Thanks!

[hylkevds]

You are right that documentation on how to add authentication to FROST is currently severely lacking. One of the reasons is that there are so many ways to do authentication and authorisation on the web that any single solution is only used by few people.

We do plan on making both basic auth and keycloak easier to use, but we haven't gotten to doing it.

The easiest way to do authentication is by putting FROST behind a reverse proxy that handles it. That's usually what we do too. No need to change anything to FROST in that case.

If you deploy FROST as war to Tomcat (so not using the docker images) then you can also have your Tomcat handle the basic auth. There are quite a few tutorials on the web that explain how to do that. The only thing you need to change in FROST in that case is the web.xml file, so basic auth branch really only adds the bits to the web.xml that sets up the security roles and the security constraints. Since the branch changes so little, it still merged without issue, so I've updated the branch.
The disadvantage is that this only adds authentication to the HTTP part, not the MQTT part.

The keycloak branch also added authentication to the MQTT server, so I'll have to look into merging the latest changes into that branch.

[selimnairb]

@HolySamosa we are using FROST with JWT authentication that we have implemented. You can find it here: https://github.com/kinota/kinota-server

[hylkevds]

I've added the auth* bits to the master branch, and written a pluggable system so the authentication options can be extended more easily. I've added some documentation at: https://github.com/FraunhoferIOSB/FROST-Server/blob/master/docs/auth.adoc

You can now add basic or keycloak auth out of the box by setting the relevant options.

@selimnairb: it might be interesting to see if your JWT authentication can also be converted to the new system.

[selimnairb]

@hylkevds I would like to get the JWT code into the FROST. I am short on time in the near term, but will put this on my list of things to do ...

[jeremy303]

Thanks for the insights, guys. Now that I have a better understanding of both FROST and the needs for our project, I expect we will likely go with securing at the reverse proxy / API gateway.

@hylkevds I would be interested to learn more about the proxy / gateway setup you typically use. In our case, we want to allow public reads but want to secure PUT/POST/PATCH/DELETE. Ideally, we would like to extend the same security to MQTT over websockets (which it appears is supported by Moquette). On the surface, it seems like Kong might be a good solution for the gateway.

[hylkevds]

We don't have any large installations, so we usually simply use Apache as a reverse proxy, with basic authentication configured there.

Securing the MQTT access using a reverse proxy is tricky. That's why I extended the FROST security options to cover both the HTTP .

[hk298]

I'm curious to see what BasicAuthProvider can do with the database in terms of authorization. Our goal would be to limit MQTT access to datastreams on a per user basis. Since the documentation doesn't say much about the database, I suppose I should just run the server once with auth_autoUpdateDatabase=true and then check what happened in the database.

Has the BasicAuthProvider been implemented in the 1.9 docker image?

[hylkevds]

The Authentication code has been merged into the master branch, so it is available in the 1.9 snapshots.

The BasicAuthProvider creates two user tables, like described in the DataSourceRealm documentation of Tomcat except with the names in upper case, like the rest of the database.

The USERS table has USER_NAME and USER_PASS columns with username/password combinations.
The USER_ROLES table has USER_NAME and ROLE_NAME columns, mapping roles to users.

[hk298]

Thanks. I was looking for a finer grain authorization as in the ACLs provides by Moquette (http://andsel.github.io/moquette/documentation.html#_credentials_management). Are these configurations supported in the FROST Server?

[hylkevds]

The current BasicAuthProvider only has global write authorisation, no ACLs.
You could try extending the Provider to add that. Each write action is authorised separately, though currently the AuthProvider interface only has a userHasRole(String clientId, String userName, String roleName) method. It would require adding a method to the AuthProvider interface that checks if the user can write on a given path, something like
userHasRight(String clientId, String userName, String path, Role action)

[ghost]

Regarding basic auth it might be a bit more secure if passwords were not stored in plain text in the database?

[hylkevds]

Yes, it would be better if the passwords in the database were salted and hashed.
Do you have time to look into this?

[ghost]

@hylkevds For now time is a bit tight so I'm going to stick to a reverse proxy auth as suggested above. Actually thinking more about this, in most cases people will want to integrate to their existing user database. So maybe it's fine to keep the basic auth backend as it is, as a simple example on which people can base their own backend. If I end up modifying the basic auth backend I'll submit a patch though.

[salixh5]

Possibly I'm misunderstanding some terminology, but in the docs it mentions the write role, but I was always getting this error when trying to publish something over MQTT:
ERROR io.moquette.broker.PostOffice - client is not authorized to publish on topic

After looking through the source code here

FROST-Server/FROST-Server.Auth.Basic/src/main/java/de/fraunhofer/iosb/ilt/frostserver/auth/basic/BasicAuthProvider.java

Line 34 in d317eca

public class BasicAuthProvider implements AuthProvider, LiquibaseUser, ConfigDefaults {

I noticed that it mentions the role create instead. After assigning this create role instead of write I can successfully publish.

Hopefully this helps someone! :)

[hylkevds]

Yes, the roles are read, create, update, delete and admin.
The default users that the basic auth module generates are read, write and admin.

There was one typo in the docs that stated that the admin user had role write, that should have been role create.

[salixh5]

Thanks @hylkevds! Re-reading it now, and it seems like I was tripped up by exactly that typo. Somehow my eyes fixated only on the admin user line. 😃