[Hawkular-dev] What are your Authentication and Authorization needs?

[Matt Wringe]

We have different authentication and authorization needs with Hawkular Metrics in OpenShift.

I am not sure what exactly the plan is for introducing more Hawkular components into OpenShift though, so the requirements there may not really affect what is going on with the Hawkular components aside from Metrics (which we are using a custom setup and not Accounts).

----- Original Message -----
> From: "Juraci Paixão Kröhling" <jpkroehling at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, April 22, 2016 7:47:47 AM
> Subject: [Hawkular-dev] What are your Authentication and Authorization needs?
> 
> 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.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>