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

[Lucas Ponce]

Hi Juca,

Thanks for bringing this.

For alerting, all model is tenant-based, and I don't see that aspect is going to change (or we can change it without a major refactor).

In alerting there is not fine grained authorization, it should be a major overkill.

So, no new security requeriments from this component, internally we work with the tenant that is translated from hawkular accounts (or taken from a header in standalone scenarios).

Lucas

----- Mensaje original -----
> De: "Juraci Paixão Kröhling" <jpkroehling at redhat.com>
> Para: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Enviados: Viernes, 22 de Abril 2016 13:47:47
> Asunto: [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
>