What are your Authentication and Authorization needs?

Friday, 22 April 2016

Team,

Due to the changes in requirements for Hawkular, I'm collecting the 
needs we have around authentication and authorization.

On another thread, I mentioned that I'm inclined to settle on JAAS, but 
before I invest more time on that, I'd like to hear from you on your 
needs. Ultimately, securing your component is of my interest, but I 
don't have a complete picture on what your needs are.

The current plan is to reduce Accounts 3.x to a minimum. Ideally, we 
won't even need Accounts 3.x, if we find out that all we need is JAAS.

As a summary, here's what we have in Accounts that might currently be in 
use by other modules:

- WebSocket authentication of messages. Each WebSocket message coming to 
the server has an "authentication" property, with credentials or tokens. 
The idea is that long-running connections would re-authenticate from 
time to time, without closing/opening the connection. The obvious easy 
solution here is to force-close a connection on the server side, and do 
a reconnect on the client. Ideally, however, we would find a way to 
authenticate the user with JAAS API. If that's possible, Accounts can 
help and consumers of WebSocket auth (ie: command gateway) won't need to 
be changed.

- Multi tenancy: so far, I have not heard any concrete use cases for 
multi tenancy other than "it would be nice to have". Remembering that 
multi tenancy here is different than storing tenant information. We 
could certainly keep storing tenant information, but I don't see a case 
where we would need to perform authorization there.

- Token support: this is not, per se, supported by vanilla JAAS. On the 
other hand, this can be emulated by having multiple "opaque" accounts on 
the JAAS user storage. So, this is not a big deal, except that the token 
API will cease existing (ie: any REST calls to /secret-store). This 
should affect *only* the UI and the Android client.

- Functional users instead of real users: this is the main change. Users 
won't be "real" users anymore (ie: jpkroehling), but technical users 
(ie: miq-prod-01). Effectively, this is similar to authentication done 
by backend services, such as Cassandra and Postgresql. For us, this 
would be 100% handled by JAAS, so, we don't need to worry whether users 
are real or functional, but we would recommend using functional users.

- Authorization: we currently have an API for authorization. I don't 
think anyone is using that, except perhaps for Inventory. As such, I 
would just remove it in favor of JAAS' authorization. This effectively 
means that you should be able to annotate "@RolesAllowed()" into your 
business methods, and JAAS would ensure that the user belongs to any of 
the authorized roles. We would, however, need to define the roles we 
need. I'd suggest starting with "read-only" and "read-write" as
roles.

- Events from the auth server: components are currently able to register 
a listener on a JMS queue or CDI event, to receive Keycloak server 
events (user logged in, user registered, ...). This will also cease to 
exist. It was implemented as a requirement from Inventory, but I think 
it's not being used anymore.

- Feature pack: components building feature packs or consuming Accounts 
feature pack would need to use Nest instead. I don't expect this to be a 
big issue, though.

- User jdoe : this will still be available on dev builds, on both the 
"read-only" and "read-write" roles that I suggested above.

I appreciate that you are all busy, so, I'll assume you are OK with the 
proposed changes if I don't hear from you until next Friday :)

- Juca.

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015