On Tue, Dec 3, 2013 at 3:42 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
On Dec 3, 2013, at 6:21 AM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> 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.
i'm not sure we should put the email functionality in the UPS, but we
could have a "create a secure link" option that the admin can then email out
Stop me if I'm completely wrong but could we use our own cryptobox for
this, I was thinking of this :
https://github.com/aerogear/aerogear-crypto-java/blob/master/src/test/jav...
Which could be (again pardon my newbiness) :
//when generating the link
CryptoBox cryptoBox = new CryptoBox(new PrivateKey(UPS_SECRET_KEY));
byte[] IV = HEX.decode(CRYPTOBOX_IV);
byte[] cipherText = cryptoBox.encrypt(IV, loginName.getBytes());
return "http://blabla/ag-push/register?" + cipherText;
//when the link is called
CryptoBox pandora = new CryptoBox(new PrivateKey(UPS_SECRET_KEY));
byte[] message = pandora.decrypt(IV, cipherText);
String loginName = RAW.encode(message);
//Do stuff with the loginName
Then the question is about the private key, how do I store it / generate
it ? Should I use the Java Keystore class
http://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html ?
>
>> 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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev