Re: [aerogear-dev] UPS User Management - Reloaded

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(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 > > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev