5:21 a.m.
Hi Sebi, few comments inline.
On December 3, 2013 at 8:54:22 AM, Sebastien Blanc (scm.blanc(a)gmail.com) wrote:
Hi,
I wanted to start a fresh new thread about user management in the Unified
Push Server, please check below the proposition I made for the next release
(0.10.0) , feel free to comment / ask questions etc ...
(https://gist.github.com/sebastienblanc/6547605)
User Management for the Aerogear Unfied Push
Server
Introduction
The goal of this document is to describe how the User Management will be
implemented in the Unified Push Server. Currently there is only one user
created by default when installing UPS. Having the possibility to create
multiple users is a "Must Have" and should be manageable from the Admin
Console. Some roles should also be introduced
Roles /
Permissions
There will be 3 different roles in this first version :
- *Admin* : The Admin is like the super-user, it can access all the
features of UPS including the creation of users.
- *Developer* : The developer can create/read/update and delete
Applications/variants.
- *viewer* : Can only 'Read', can be useful for monitoring apps (or for
the future UPS Forge Plugin).
Here the Developer role will be able to reset user’s password? Or his own password?
Role / actionCreateUpdateReadDeleteReset pwdUser MngtAdminXXXXXXDeveloperXXX
XXViewer X
User
management flow
An Admin can create new user by providing a loginName. This will be
possible through :
- The console
- The REST service
Password
Management
At creation, the user will have a default password , i.e 123.
I think here is the problem which we can’t delay anymore. At the creation we should
probably send an e-mail with the encrypted url for the password setup.
Is not the same thing, but the url approach can be something similar to what SP does to
register channels.
First Login
When logging in for this first time, the new created user will be prompted
to change his password.
Same thing there, I think users should be able to reset their own password.
Reset
Password Instruction
If a user wants to reset his password, he has to request it manually
(email, post pigeon ...) to an admin. The password will be again the
default one and the user will have to change it again when logging in.
Scope
of the current permissions
Currently, a authenticated user can see all the applications / variants /
installations, no matter he is the author or not. There is also no concept
of groups, that may come in the future releases.
Security
Implementation
Currently, it would be possible to implement this using
Aerogear-Security-Picketlink and with some raw Picketlink :
- Login / Logout / Registration : AG-Security offers all we need
- Roles and permissions : AG-Security offers a secures annotation that
can be used to protect the endpoints.
I know there are some concerns about this last points (Role escalation etc
...) and would like to have advice / feedback on what is acceptable /
doable for the 0.10.0 release (15/01).
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj