[aerogear-dev] [Unified Push Server] Roles structure & password management

Bruno Oliveira bruno at abstractj.org
Thu Sep 12 08:39:28 EDT 2013


Would be nice to have a 8 hands document on it

> Matthias Wessendorf <mailto:matzew at apache.org>
> September 12, 2013 8:53 AM
>
>
>
> On Wed, Sep 4, 2013 at 5:31 PM, Sebastien Blanc <scm.blanc at gmail.com
> <mailto:scm.blanc at gmail.com>> wrote:
>
>
>
>
>     On Wed, Sep 4, 2013 at 5:22 PM, Lucas Holmquist
>     <lholmqui at redhat.com <mailto:lholmqui at redhat.com>> wrote:
>
>         Currently i think "Apps" are associated with a specific user,
>          so if we introduce new users, then those new users won't be
>         able to see any of the existing apps,  even if they have the
>         same roles.
>
>
>     That's a interesting point : I assume the relation between user
>     and apps is now 1-1 but do we want n-1 (multiple users could
>     manage an app) in the future ? so after creating a user we could
>     affect him to an app.
>
>
> I do like (for the long run) the idea of 'grouping'
>
> -M
>  
>
>      
>
>
>         this should probably change to be more role based,  example:
>
>         Admin role:
>                 All CRUD on Apps and CRUD user management
>         Developer:
>                 CRUD on Apps
>         User:
>                 just READ Apps
>
>
>
>         On Sep 4, 2013, at 11:06 AM, Bruno Oliveira
>         <bruno at abstractj.org <mailto:bruno at abstractj.org>> wrote:
>
>         >
>         >
>         > Sebastien Blanc wrote:
>         >> Hi,
>         >> Start point is this jira
>         https://issues.jboss.org/browse/AGPUSH-282 for
>         >> allowing the creation of additional users/developers.
>         >> In the current situation we have just one role :
>         "developer" , so the
>         >> first question is :
>         >>
>         >> - Should a user with the role "developer" be able to create
>         another user ?
>         >
>         > It depends, I think is a matter of rules inside AGPUSH.
>         Maybe we should
>         > have a role hierarchy definition? Would be nice.
>         >
>         >> - Should we introduce a "admin" role that can manage users
>         (create,
>         >> reset password, delete) ?
>         >
>         > Makes sense.
>         >
>         >> - A mix of permissions ? (a developer can create other
>         users but not
>         >> remove them nor reset (except its own) password )
>         >
>         > The hierarchy should be clear users/roles and levels, we can
>         start a
>         > simple gist on it.
>         >>
>         >> From there the second question regarding password management :
>         >> In the current situation, our default user (called "admin"
>         , yeah a bit
>         >> confusing :) ) has a temporary password that must be
>         changed the first
>         >> time he logs in.
>         >>
>         >> - Do we want to keep this ?
>         >
>         > That is a old request from my side and violates CWE-798
>         > (http://cwe.mitre.org/data/definitions/798.html)
>         >>
>         >> - Shall we move to a script that creates a user(s) ?
>         >
>         > +1 for provide a script like "sample-db.sql" or whatever out
>         of the box.
>         +1
>         >>
>         >> - When we add a user through the admin UI, should we
>         provide a password
>         >> or should it be generated and changed on first login ?
>         >
>         > In theory we should send the password reset instructions
>         with the url to
>         > change it like:
>         >
>         > http://admin-ui.org/changeme/424242424242424 (Using the
>         SecureRandom
>         > entropy from Java)
>         >
>         >>
>         >> In other words, I think we must concretely spec out the
>         user management
>         >> for the UPS and we could use this thread to discuss that !
>         >
>         > +1 I'm all for it
>         >
>         >>
>         >> _______________________________________________
>         >> aerogear-dev mailing list
>         >> aerogear-dev at lists.jboss.org
>         <mailto: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
>         <mailto:aerogear-dev at lists.jboss.org>
>         > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>         _______________________________________________
>         aerogear-dev mailing list
>         aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> -- 
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> Sebastien Blanc <mailto:scm.blanc at gmail.com>
> September 4, 2013 12:31 PM
>
>
>
> On Wed, Sep 4, 2013 at 5:22 PM, Lucas Holmquist <lholmqui at redhat.com
> <mailto:lholmqui at redhat.com>> wrote:
>
>     Currently i think "Apps" are associated with a specific user,  so
>     if we introduce new users, then those new users won't be able to
>     see any of the existing apps,  even if they have the same roles.
>
>
> That's a interesting point : I assume the relation between user and
> apps is now 1-1 but do we want n-1 (multiple users could manage an
> app) in the future ? so after creating a user we could affect him to
> an app.
>  
>
>
>     this should probably change to be more role based,  example:
>
>     Admin role:
>             All CRUD on Apps and CRUD user management
>     Developer:
>             CRUD on Apps
>     User:
>             just READ Apps
>
>
>
>     On Sep 4, 2013, at 11:06 AM, Bruno Oliveira <bruno at abstractj.org
>     <mailto:bruno at abstractj.org>> wrote:
>
>     >
>     >
>     > Sebastien Blanc wrote:
>     >> Hi,
>     >> Start point is this jira
>     https://issues.jboss.org/browse/AGPUSH-282 for
>     >> allowing the creation of additional users/developers.
>     >> In the current situation we have just one role : "developer" ,
>     so the
>     >> first question is :
>     >>
>     >> - Should a user with the role "developer" be able to create
>     another user ?
>     >
>     > It depends, I think is a matter of rules inside AGPUSH. Maybe we
>     should
>     > have a role hierarchy definition? Would be nice.
>     >
>     >> - Should we introduce a "admin" role that can manage users (create,
>     >> reset password, delete) ?
>     >
>     > Makes sense.
>     >
>     >> - A mix of permissions ? (a developer can create other users
>     but not
>     >> remove them nor reset (except its own) password )
>     >
>     > The hierarchy should be clear users/roles and levels, we can start a
>     > simple gist on it.
>     >>
>     >> From there the second question regarding password management :
>     >> In the current situation, our default user (called "admin" ,
>     yeah a bit
>     >> confusing :) ) has a temporary password that must be changed
>     the first
>     >> time he logs in.
>     >>
>     >> - Do we want to keep this ?
>     >
>     > That is a old request from my side and violates CWE-798
>     > (http://cwe.mitre.org/data/definitions/798.html)
>     >>
>     >> - Shall we move to a script that creates a user(s) ?
>     >
>     > +1 for provide a script like "sample-db.sql" or whatever out of
>     the box.
>     +1
>     >>
>     >> - When we add a user through the admin UI, should we provide a
>     password
>     >> or should it be generated and changed on first login ?
>     >
>     > In theory we should send the password reset instructions with
>     the url to
>     > change it like:
>     >
>     > http://admin-ui.org/changeme/424242424242424 (Using the SecureRandom
>     > entropy from Java)
>     >
>     >>
>     >> In other words, I think we must concretely spec out the user
>     management
>     >> for the UPS and we could use this thread to discuss that !
>     >
>     > +1 I'm all for it
>     >
>     >>
>     >> _______________________________________________
>     >> aerogear-dev mailing list
>     >> aerogear-dev at lists.jboss.org <mailto: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 <mailto:aerogear-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto: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
> Lucas Holmquist <mailto:lholmqui at redhat.com>
> September 4, 2013 12:22 PM
> Currently i think "Apps" are associated with a specific user,  so if we introduce new users, then those new users won't be able to see any of the existing apps,  even if they have the same roles.
>
> this should probably change to be more role based,  example:
>
> Admin role:
> 	All CRUD on Apps and CRUD user management
> Developer:
> 	CRUD on Apps
> User:
> 	just READ Apps
>
>
>
> On Sep 4, 2013, at 11:06 AM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> Sebastien Blanc wrote:
>>> Hi,
>>> Start point is this jira https://issues.jboss.org/browse/AGPUSH-282 for
>>> allowing the creation of additional users/developers.
>>> In the current situation we have just one role : "developer" , so the
>>> first question is :
>>>
>>> - Should a user with the role "developer" be able to create another user ?
>> It depends, I think is a matter of rules inside AGPUSH. Maybe we should
>> have a role hierarchy definition? Would be nice.
>>
>>> - Should we introduce a "admin" role that can manage users (create,
>>> reset password, delete) ? 
>> Makes sense.
>>
>>> - A mix of permissions ? (a developer can create other users but not
>>> remove them nor reset (except its own) password ) 
>> The hierarchy should be clear users/roles and levels, we can start a
>> simple gist on it.
>>> From there the second question regarding password management : 
>>> In the current situation, our default user (called "admin" , yeah a bit
>>> confusing :) ) has a temporary password that must be changed the first
>>> time he logs in.
>>>
>>> - Do we want to keep this ?
>> That is a old request from my side and violates CWE-798
>> (http://cwe.mitre.org/data/definitions/798.html)
>>> - Shall we move to a script that creates a user(s) ?
>> +1 for provide a script like "sample-db.sql" or whatever out of the box.
> +1
>>> - When we add a user through the admin UI, should we provide a password
>>> or should it be generated and changed on first login ?
>> In theory we should send the password reset instructions with the url to
>> change it like:
>>
>> http://admin-ui.org/changeme/424242424242424 (Using the SecureRandom
>> entropy from Java)
>>
>>> In other words, I think we must concretely spec out the user management
>>> for the UPS and we could use this thread to discuss that !
>> +1 I'm all for it
>>
>>> _______________________________________________
>>> 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
> Bruno Oliveira <mailto:bruno at abstractj.org>
> September 4, 2013 12:06 PM
> Sebastien Blanc wrote:
>> Hi,
>> Start point is this jira https://issues.jboss.org/browse/AGPUSH-282 for
>> allowing the creation of additional users/developers.
>> In the current situation we have just one role : "developer" , so the
>> first question is :
>>
>> - Should a user with the role "developer" be able to create another user ?
>
> It depends, I think is a matter of rules inside AGPUSH. Maybe we should
> have a role hierarchy definition? Would be nice.
>
>> - Should we introduce a "admin" role that can manage users (create,
>> reset password, delete) ? 
>
> Makes sense.
>
>> - A mix of permissions ? (a developer can create other users but not
>> remove them nor reset (except its own) password ) 
>
> The hierarchy should be clear users/roles and levels, we can start a
> simple gist on it.
>> From there the second question regarding password management : 
>> In the current situation, our default user (called "admin" , yeah a bit
>> confusing :) ) has a temporary password that must be changed the first
>> time he logs in.
>>
>>  - Do we want to keep this ?
>
> That is a old request from my side and violates CWE-798
> (http://cwe.mitre.org/data/definitions/798.html)
>>  
>> - Shall we move to a script that creates a user(s) ?
>
> +1 for provide a script like "sample-db.sql" or whatever out of the box.
>> - When we add a user through the admin UI, should we provide a password
>> or should it be generated and changed on first login ?
>
> In theory we should send the password reset instructions with the url to
> change it like:
>
> http://admin-ui.org/changeme/424242424242424 (Using the SecureRandom
> entropy from Java)
>
>> In other words, I think we must concretely spec out the user management
>> for the UPS and we could use this thread to discuss that !
>
> +1 I'm all for it
>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> Sebastien Blanc <mailto:scm.blanc at gmail.com>
> September 4, 2013 11:34 AM
> Hi,
> Start point is this jira https://issues.jboss.org/browse/AGPUSH-282
> for allowing the creation of additional users/developers.
> In the current situation we have just one role : "developer" , so the
> first question is :
>
> - Should a user with the role "developer" be able to create another user ?
> - Should we introduce a "admin" role that can manage users (create,
> reset password, delete) ? 
> - A mix of permissions ? (a developer can create other users but not
> remove them nor reset (except its own) password ) 
>
> From there the second question regarding password management : 
> In the current situation, our default user (called "admin" , yeah a
> bit confusing :) ) has a temporary password that must be changed the
> first time he logs in.
>
>  - Do we want to keep this ?
>  
> - Shall we move to a script that creates a user(s) ?
>
> - When we add a user through the admin UI, should we provide a
> password or should it be generated and changed on first login ?
>
> In other words, I think we must concretely spec out the user
> management for the UPS and we could use this thread to discuss that !
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- 
abstractj


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130912/8157c6bd/attachment-0001.bin 


More information about the aerogear-dev mailing list