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
_______________________________________________
errai-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/errai-dev

Reply via email to