What are your Authentication and Authorization needs?
by Juraci Paixão Kröhling
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.
