[aerogear-dev] UPS User Management - Reloaded

[Sebastien Blanc]

On Tue, Dec 3, 2013 at 3:42 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:

>
> On Dec 3, 2013, at 6:21 AM, Bruno Oliveira <bruno at abstractj.org> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131204/ca7eaa14/attachment.html