[errai-dev] Initial version of security module: security features and API

[Jonathan Fuerth]

I was going to follow up with my thoughts on Erik Jan's new Security module for Errai, which was committed here:

https://github.com/edewit/errai/commit/d2ce53082a5cc0c90c357781c7cfc21541f75195

But first, since we haven't discussed it, maybe we should work on brainstorming a list of requirements and non-requirements for an Errai security module.

Here's what I think apps might require from Errai security (just brainstorming to start the discussion!):

 1. A mechanism for logging in with the server
 2. A mechanism for logging out with the server
 3. A mechanism for caching credentials for use with JAX-RS calls (client-side; the "logged in" state doesn't exist on the server)
 4. A mechanism for finding out what roles the current authenticated user belongs to
 5. The ability to ask if the logged in user has permission to perform a specific action (client and server)
 6. The ability to ask if the logged in user has permission to see a specific piece of data (definitely server; maybe client, but client shouldn't have any illegal data to ask about!)
 7. All client features should work offline (eg. when the client can't contact the server)
 8. At the discretion of the app developer, login sessions on the client should survive traditional server session timeouts. The client should be able to work offline, allowing server reachability to come and go. Think about how long you can stay authenticated in Gmail or StackOverflow. This is useful behaviour for most non-banking type apps.
 9. Ability to protect an ErraiBus subject on the server side (prevent certain clients from subscribing to certain subjects.. perhaps even matching subjects by regex). This low-level feature is analogous to an IP firewall with rules by port number.
 10. Ability to protect Errai RPC (and JAX-RS?) service endpoints based on user roles

Non-requirements (again, sharing my opinions to get the ball rolling):

 1. Built-in ability to create and delete users. This is going to depend a lot on what kind of user object the app needs, how it's stored, etc.
 2. Details like password hashing, user object storage and retrieval, etc. These should be left to a 3rd party security framework like PicketLink

-Jonathan