[aerogear-dev] UPS User Management - Reloaded

[Bruno Oliveira]

I’m on it and will send a basic idea soon, cryptobox doesn’t make too much sense into this scenario, because we must use one-way hash.

On December 4, 2013 at 12:09:21 PM, Sebastien Blanc (scm.blanc at gmail.com) wrote:
>
>On Tue, Dec 3, 2013 at 3:42 PM, Lucas Holmquist wrote:
>
>>
>> On Dec 3, 2013, at 6:21 AM, Bruno Oliveira wrote:
>>
>> > Hi Sebi, few comments inline.
>> >
>> > On December 3, 2013 at 8:54:22 AM, Sebastien Blanc (scm.blanc at 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/java/org/jboss/aerogear/crypto/CryptoBoxTest.java#L111
>
>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 at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> > --
>> > abstractj
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>_______________________________________________
>aerogear-dev mailing list
>aerogear-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/aerogear-dev  

-- 
abstractj