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

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(a)abstractj.org&gt; 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(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

Matthias Wessendorf <mailto:matzew@apache.org> September 12, 2013 8:53 AM On Wed, Sep 4, 2013 at 5:31 PM, Sebastien Blanc <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote: On Wed, Sep 4, 2013 at 5:22 PM, Lucas Holmquist <lholmqui(a)redhat.com <mailto:lholmqui@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(a)abstractj.org <mailto:bruno@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(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > abstractj > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev Sebastien Blanc <mailto:scm.blanc@gmail.com> September 4, 2013 12:31 PM On Wed, Sep 4, 2013 at 5:22 PM, Lucas Holmquist <lholmqui(a)redhat.com <mailto:lholmqui@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(a)abstractj.org <mailto:bruno@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(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > abstractj > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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 Lucas Holmquist <mailto:lholmqui@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(a)abstractj.org&gt; 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(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 Bruno Oliveira <mailto:bruno@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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev Sebastien Blanc <mailto:scm.blanc@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira wrote: > Would be nice to have a 8 hands document on it who's going to start the pull request on it? it's SPECTIME! -- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Following the discussion on GitHub [1], here are some points to be discussed about the user management flow: - Does it make sense to add a role select field (admin, developer) on the enrollment page?

- Should we add an additional password field (password confirmation) on the enrollment page?

- I think that the current logged in user shouldn't be available for deletion

[1]: https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6 On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote: > A Jira has been created https://issues.jboss.org/browse/AGPUSH-351 > And draft structure has been created > here https://gist.github.com/sebastienblanc/6547605 that can be used > as base for the Pull Request. > > > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira > wrote: > > Would be nice to have a 8 hands document on it > > > who's going to start the pull request on it? it's SPECTIME! > > -- > qmx > _______________________________________________ > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

So for the next Unified Push Release (0.9) it would be nice if we could have some decent User Management, so I'm bumping this thread again. Some existing pointer : - this thread :) - https://issues.jboss.org/browse/AGPUSH-351 - https://gist.github.com/sebastienblanc/6547605 First point to define is : - What roles do we want ? And what can these Roles do ?

- How can these Roles be created (granted ...) - Design

Seb On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis <aemmanou(a)redhat.com&gt; wrote: Following the discussion on GitHub [1], here are some points to be discussed about the user management flow: - Does it make sense to add a role select field (admin, developer) on the enrollment page? hrm, and (perhaps later) a section where to define the roles ? I think it's a good point, but not sure we need all this 'now' :-) - Should we add an additional password field (password confirmation) on the enrollment page? yeah, would be nice - I think that the current logged in user shouldn't be available for deletion yep, I agree [1]: https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6 On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote: > A Jira has been created https://issues.jboss.org/browse/AGPUSH-351 > And draft structure has been created > here https://gist.github.com/sebastienblanc/6547605 that can be used > as base for the Pull Request. > > > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira > wrote: > > Would be nice to have a 8 hands document on it > > > who's going to start the pull request on it? it's SPECTIME! > > -- > qmx > _______________________________________________ > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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(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

On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > > On Oct 15, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > > So for the next Unified Push Release (0.9) it would be nice if we could > have some decent User Management, so I'm bumping this thread again. > Some existing pointer : > > - this thread :) > - https://issues.jboss.org/browse/AGPUSH-351 > - https://gist.github.com/sebastienblanc/6547605 > > First point to define is : > - What roles do we want ? And what can these Roles do ? > > > Admin - Can do all things including creating other users > Developer - can create apps and such. no access to the user management UI > User - read only - not sure if this one is needed > Yes, not sure also but why not ? Could be useful for a monitoring app/RHQ plugin that just want to retrieve the list of active pushapps ...

> - How can these Roles be created (granted ...) > - Design > > > I think we are still waiting on Hylke for this? not sure > > > Seb > > > > On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > >> >> >> >> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis < >> aemmanou(a)redhat.com&gt; wrote: >> >>> Following the discussion on GitHub [1], here are some points to be >>> discussed about the user management flow: >>> >>> - Does it make sense to add a role select field (admin, developer) on >>> the enrollment page? >>> >> >> hrm, and (perhaps later) a section where to define the roles ? I think >> it's a good point, but not sure we need all this 'now' :-) >> >> >>> - Should we add an additional password field (password confirmation) on >>> the enrollment page? >>> >> >> yeah, would be nice >> >> >>> - I think that the current logged in user shouldn't be available for >>> deletion >>> >> >> yep, I agree >> >>> >>> [1]: >>> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6 >>> >>> >>> >>> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote: >>> > A Jira has been created https://issues.jboss.org/browse/AGPUSH-351 >>> > And draft structure has been created >>> > here https://gist.github.com/sebastienblanc/6547605 that can be used >>> > as base for the Pull Request. >>> > >>> > >>> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >>> > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira >>> > wrote: >>> > > Would be nice to have a 8 hands document on it >>> > >>> > >>> > who's going to start the pull request on it? it's SPECTIME! >>> > >>> > -- >>> > qmx >>> > _______________________________________________ >>> > 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 >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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(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 > > > > _______________________________________________ > 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

Not sure about the role: user. What will be the use case for this one? One use case, I see is if the 'user' is a tester. If we had the feature to send push notification test via admin UI (as we discussed in [1] and [2]). ++ Corinne [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Push-Server-Admin-... [2] https://issues.jboss.org/browse/AGPUSH-38 On Oct 17, 2013, at 3:09 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Thu, Oct 17, 2013 at 2:54 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > On Oct 15, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> So for the next Unified Push Release (0.9) it would be nice if we could have some decent User Management, so I'm bumping this thread again. >> Some existing pointer : >> >> - this thread :) >> - https://issues.jboss.org/browse/AGPUSH-351 >> - https://gist.github.com/sebastienblanc/6547605 >> >> First point to define is : >> - What roles do we want ? And what can these Roles do ? > > Admin - Can do all things including creating other users > Developer - can create apps and such. no access to the user management UI > User - read only - not sure if this one is needed > Yes, not sure also but why not ? Could be useful for a monitoring app/RHQ plugin that just want to retrieve the list of active pushapps ... > > > +1 - I like these three different roles, including their rights > > > > >> - How can these Roles be created (granted ...) >> - Design > > I think we are still waiting on Hylke for this? not sure > >> >> Seb >> >> >> >> On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >> >> >> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis < aemmanou(a)redhat.com&gt; wrote: >> Following the discussion on GitHub [1], here are some points to be >> discussed about the user management flow: >> >> - Does it make sense to add a role select field (admin, developer) on >> the enrollment page? >> >> hrm, and (perhaps later) a section where to define the roles ? I think it's a good point, but not sure we need all this 'now' :-) >> >> - Should we add an additional password field (password confirmation) on >> the enrollment page? >> >> yeah, would be nice >> >> - I think that the current logged in user shouldn't be available for >> deletion >> >> yep, I agree >> >> [1]: >> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6 >> >> >> >> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote: >> > A Jira has been created https://issues.jboss.org/browse/AGPUSH-351 >> > And draft structure has been created >> > here https://gist.github.com/sebastienblanc/6547605 that can be used >> > as base for the Pull Request. >> > >> > >> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >> > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira >> > wrote: >> > > Would be nice to have a 8 hands document on it >> > >> > >> > who's going to start the pull request on it? it's SPECTIME! >> > >> > -- >> > qmx >> > _______________________________________________ >> > 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 >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(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 > > > _______________________________________________ > 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 > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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

Not closely related indeed. Could be another role 'tester' if we want to implement the test feature. Make more sense since you define 'user' as 'normal developer'.

++ Corinne On Oct 17, 2013, at 3:44 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > any corp. org. may want some with just read-only access; > The project lead is allowed to update the keys etc, but all the /normal/ developers can just see the IDs/secrets (so that they can use it in their server apps). > > I guess that's not really (at least for me) closely related to a 'test via admin ui' feature > > -M > > > On Thu, Oct 17, 2013 at 3:39 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > Not sure about the role: user. > > What will be the use case for this one? > One use case, I see is if the 'user' is a tester. If we had the feature to send push notification test via admin UI (as we discussed in [1] and [2]). > > ++ > Corinne > [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Push-Server-Admin-... > [2] https://issues.jboss.org/browse/AGPUSH-38 > > On Oct 17, 2013, at 3:09 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > > > > > > On Thu, Oct 17, 2013 at 2:54 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > > > > > On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > > > On Oct 15, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > >> So for the next Unified Push Release (0.9) it would be nice if we could have some decent User Management, so I'm bumping this thread again. > >> Some existing pointer : > >> > >> - this thread :) > >> - https://issues.jboss.org/browse/AGPUSH-351 > >> - https://gist.github.com/sebastienblanc/6547605 > >> > >> First point to define is : > >> - What roles do we want ? And what can these Roles do ? > > > > Admin - Can do all things including creating other users > > Developer - can create apps and such. no access to the user management UI > > User - read only - not sure if this one is needed > > Yes, not sure also but why not ? Could be useful for a monitoring app/RHQ plugin that just want to retrieve the list of active pushapps ... > > > > > > +1 - I like these three different roles, including their rights > > > > > > > > > >> - How can these Roles be created (granted ...) > >> - Design > > > > I think we are still waiting on Hylke for this? not sure > > > >> > >> Seb > >> > >> > >> > >> On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf < matzew(a)apache.org&gt; wrote: > >> > >> > >> > >> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis < aemmanou(a)redhat.com&gt; wrote: > >> Following the discussion on GitHub [1], here are some points to be > >> discussed about the user management flow: > >> > >> - Does it make sense to add a role select field (admin, developer) on > >> the enrollment page? > >> > >> hrm, and (perhaps later) a section where to define the roles ? I think it's a good point, but not sure we need all this 'now' :-) > >> > >> - Should we add an additional password field (password confirmation) on > >> the enrollment page? > >> > >> yeah, would be nice > >> > >> - I think that the current logged in user shouldn't be available for > >> deletion > >> > >> yep, I agree > >> > >> [1]: > >> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6 > >> > >> > >> > >> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote: > >> > A Jira has been created https://issues.jboss.org/browse/AGPUSH-351 > >> > And draft structure has been created > >> > here https://gist.github.com/sebastienblanc/6547605 that can be used > >> > as base for the Pull Request. > >> > > >> > > >> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > >> > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira > >> > wrote: > >> > > Would be nice to have a 8 hands document on it > >> > > >> > > >> > who's going to start the pull request on it? it's SPECTIME! > >> > > >> > -- > >> > qmx > >> > _______________________________________________ > >> > 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 > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)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(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 > > > > > > _______________________________________________ > > 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 > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > 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 > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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

On Thu, Oct 17, 2013 at 4:02 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: Not closely related indeed. Could be another role 'tester' if we want to implement the test feature. Make more sense since you define 'user' as 'normal developer'. I suck at names - But yeah 'super developer' is worse :-) Why not stick with dev and user (and admin) ?

-M ++ Corinne On Oct 17, 2013, at 3:44 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > any corp. org. may want some with just read-only access; > The project lead is allowed to update the keys etc, but all the /normal/ developers can just see the IDs/secrets (so that they can use it in their server apps). > > I guess that's not really (at least for me) closely related to a 'test via admin ui' feature > > -M > > > On Thu, Oct 17, 2013 at 3:39 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > Not sure about the role: user. > > What will be the use case for this one? > One use case, I see is if the 'user' is a tester. If we had the feature to send push notification test via admin UI (as we discussed in [1] and [2]). > > ++ > Corinne > [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Push-Server-Admin-... > [2] https://issues.jboss.org/browse/AGPUSH-38 > > On Oct 17, 2013, at 3:09 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > > > > > > On Thu, Oct 17, 2013 at 2:54 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > > > > > On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > > > On Oct 15, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > >> So for the next Unified Push Release (0.9) it would be nice if we could have some decent User Management, so I'm bumping this thread again. > >> Some existing pointer : > >> > >> - this thread :) > >> - https://issues.jboss.org/browse/AGPUSH-351 > >> - https://gist.github.com/sebastienblanc/6547605 > >> > >> First point to define is : > >> - What roles do we want ? And what can these Roles do ? > > > > Admin - Can do all things including creating other users > > Developer - can create apps and such. no access to the user management UI > > User - read only - not sure if this one is needed > > Yes, not sure also but why not ? Could be useful for a monitoring app/RHQ plugin that just want to retrieve the list of active pushapps ... > > > > > > +1 - I like these three different roles, including their rights > > > > > > > > > >> - How can these Roles be created (granted ...) > >> - Design > > > > I think we are still waiting on Hylke for this? not sure > > > >> > >> Seb > >> > >> > >> > >> On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> > >> > >> > >> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis <aemmanou(a)redhat.com&gt; wrote: > >> Following the discussion on GitHub [1], here are some points to be > >> discussed about the user management flow: > >> > >> - Does it make sense to add a role select field (admin, developer) on > >> the enrollment page? > >> > >> hrm, and (perhaps later) a section where to define the roles ? I think it's a good point, but not sure we need all this 'now' :-) > >> > >> - Should we add an additional password field (password confirmation) on > >> the enrollment page? > >> > >> yeah, would be nice > >> > >> - I think that the current logged in user shouldn't be available for > >> deletion > >> > >> yep, I agree > >> > >> [1]: > >> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6 > >> > >> > >> > >> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote: > >> > A Jira has been created https://issues.jboss.org/browse/AGPUSH-351 > >> > And draft structure has been created > >> > here https://gist.github.com/sebastienblanc/6547605 that can be used > >> > as base for the Pull Request. > >> > > >> > > >> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > >> > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira > >> > wrote: > >> > > Would be nice to have a 8 hands document on it > >> > > >> > > >> > who's going to start the pull request on it? it's SPECTIME! > >> > > >> > -- > >> > qmx > >> > _______________________________________________ > >> > 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 > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)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(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 > > > > > > _______________________________________________ > > 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 > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > 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 > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Oct 17, 2013 at 3:44 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > any corp. org. may want some with just read-only access; > The project lead is allowed to update the keys etc, but all the /normal/ > developers can just see the IDs/secrets (so that they can use it in their > server apps). > This is also an interesting point, at some point don't we want the "read" rights limited to a single/set of pushapps or even a level deeper based on variants ? Maybe in a big company, Bob the slacker intern has read access for his supracool push app but also has access to the Public Relation Push App keys ... > I guess that's not really (at least for me) closely related to a 'test > via admin ui' feature > > -M > > > On Thu, Oct 17, 2013 at 3:39 PM, Corinne Krych <corinnekrych(a)gmail.com&gt;wrote: > >> Not sure about the role: user. >> >> What will be the use case for this one? >> One use case, I see is if the 'user' is a tester. If we had the feature >> to send push notification test via admin UI (as we discussed in [1] and >> [2]). >> >> ++ >> Corinne >> [1] >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Push-Server-Admin-... >> [2] https://issues.jboss.org/browse/AGPUSH-38 >> >> On Oct 17, 2013, at 3:09 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> > >> > >> > >> > On Thu, Oct 17, 2013 at 2:54 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >> wrote: >> > >> > >> > >> > On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; >> wrote: >> > >> > On Oct 15, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >> wrote: >> > >> >> So for the next Unified Push Release (0.9) it would be nice if we >> could have some decent User Management, so I'm bumping this thread again. >> >> Some existing pointer : >> >> >> >> - this thread :) >> >> - https://issues.jboss.org/browse/AGPUSH-351 >> >> - https://gist.github.com/sebastienblanc/6547605 >> >> >> >> First point to define is : >> >> - What roles do we want ? And what can these Roles do ? >> > >> > Admin - Can do all things including creating other users >> > Developer - can create apps and such. no access to the user management >> UI >> > User - read only - not sure if this one is needed >> > Yes, not sure also but why not ? Could be useful for a monitoring >> app/RHQ plugin that just want to retrieve the list of active pushapps ... >> > >> > >> > +1 - I like these three different roles, including their rights >> > >> > >> > >> > >> >> - How can these Roles be created (granted ...) >> >> - Design >> > >> > I think we are still waiting on Hylke for this? not sure >> > >> >> >> >> Seb >> >> >> >> >> >> >> >> On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf < >> matzew(a)apache.org&gt; wrote: >> >> >> >> >> >> >> >> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis < >> aemmanou(a)redhat.com&gt; wrote: >> >> Following the discussion on GitHub [1], here are some points to be >> >> discussed about the user management flow: >> >> >> >> - Does it make sense to add a role select field (admin, developer) on >> >> the enrollment page? >> >> >> >> hrm, and (perhaps later) a section where to define the roles ? I >> think it's a good point, but not sure we need all this 'now' :-) >> >> >> >> - Should we add an additional password field (password confirmation) >> on >> >> the enrollment page? >> >> >> >> yeah, would be nice >> >> >> >> - I think that the current logged in user shouldn't be available for >> >> deletion >> >> >> >> yep, I agree >> >> >> >> [1]: >> >> >> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6 >> >> >> >> >> >> >> >> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote: >> >> > A Jira has been created https://issues.jboss.org/browse/AGPUSH-351 >> >> > And draft structure has been created >> >> > here https://gist.github.com/sebastienblanc/6547605 that can be >> used >> >> > as base for the Pull Request. >> >> > >> >> > >> >> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >> >> > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira >> >> > wrote: >> >> > > Would be nice to have a 8 hands document on it >> >> > >> >> > >> >> > who's going to start the pull request on it? it's SPECTIME! >> >> > >> >> > -- >> >> > qmx >> >> > _______________________________________________ >> >> > 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 >> >> >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev(a)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(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 >> > >> > >> > _______________________________________________ >> > 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 >> > >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> > _______________________________________________ >> > 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > 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

Well, yes now that you said that :) Security based on Grouping. On Thu, Oct 17, 2013 at 4:15 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: you mean grouping ? On Thu, Oct 17, 2013 at 4:13 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: On Thu, Oct 17, 2013 at 3:44 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: any corp. org. may want some with just read-only access; The project lead is allowed to update the keys etc, but all the /normal/ developers can just see the IDs/secrets (so that they can use it in their server apps). This is also an interesting point, at some point don't we want the "read" rights limited to a single/set of pushapps or even a level deeper based on variants ? Maybe in a big company, Bob the slacker intern has read access for his supracool push app but also has access to the Public Relation Push App keys ... I guess that's not really (at least for me) closely related to a 'test via admin ui' feature -M On Thu, Oct 17, 2013 at 3:39 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: Not sure about the role: user. What will be the use case for this one? One use case, I see is if the 'user' is a tester. If we had the feature to send push notification test via admin UI (as we discussed in [1] and [2]). ++ Corinne [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Push-Server-Admin-... [2] https://issues.jboss.org/browse/AGPUSH-38 On Oct 17, 2013, at 3:09 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Thu, Oct 17, 2013 at 2:54 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > On Oct 15, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> So for the next Unified Push Release (0.9) it would be nice if we could have some decent User Management, so I'm bumping this thread again. >> Some existing pointer : >> >> - this thread :) >> - https://issues.jboss.org/browse/AGPUSH-351 >> - https://gist.github.com/sebastienblanc/6547605 >> >> First point to define is : >> - What roles do we want ? And what can these Roles do ? > > Admin - Can do all things including creating other users > Developer - can create apps and such. no access to the user management UI > User - read only - not sure if this one is needed > Yes, not sure also but why not ? Could be useful for a monitoring app/RHQ plugin that just want to retrieve the list of active pushapps ... > > > +1 - I like these three different roles, including their rights > > > > >> - How can these Roles be created (granted ...) >> - Design > > I think we are still waiting on Hylke for this? not sure > >> >> Seb >> >> >> >> On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >> >> >> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis <aemmanou(a)redhat.com&gt; wrote: >> Following the discussion on GitHub [1], here are some points to be >> discussed about the user management flow: >> >> - Does it make sense to add a role select field (admin, developer) on >> the enrollment page? >> >> hrm, and (perhaps later) a section where to define the roles ? I think it's a good point, but not sure we need all this 'now' :-) >> >> - Should we add an additional password field (password confirmation) on >> the enrollment page? >> >> yeah, would be nice >> >> - I think that the current logged in user shouldn't be available for >> deletion >> >> yep, I agree >> >> [1]: >> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6 >> >> >> >> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote: >> > A Jira has been created https://issues.jboss.org/browse/AGPUSH-351 >> > And draft structure has been created >> > here https://gist.github.com/sebastienblanc/6547605 that can be used >> > as base for the Pull Request. >> > >> > >> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >> > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira >> > wrote: >> > > Would be nice to have a 8 hands document on it >> > >> > >> > who's going to start the pull request on it? it's SPECTIME! >> > >> > -- >> > qmx >> > _______________________________________________ >> > 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 >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(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 > > > _______________________________________________ > 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 > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ 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

Well, yes now that you said that :) Security based on Grouping. On Thu, Oct 17, 2013 at 4:15 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > you mean grouping ? > > > On Thu, Oct 17, 2013 at 4:13 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > >> >> >> >> On Thu, Oct 17, 2013 at 3:44 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >> >>> any corp. org. may want some with just read-only access; >>> The project lead is allowed to update the keys etc, but all the >>> /normal/ developers can just see the IDs/secrets (so that they can use it >>> in their server apps). >>> >> >> This is also an interesting point, at some point don't we want the >> "read" rights limited to a single/set of pushapps or even a level deeper >> based on variants ? >> Maybe in a big company, Bob the slacker intern has read access for his >> supracool push app but also has access to the Public Relation Push App >> keys ... >> >> >> >>> I guess that's not really (at least for me) closely related to a 'test >>> via admin ui' feature >>> >>> -M >>> >>> >>> On Thu, Oct 17, 2013 at 3:39 PM, Corinne Krych <corinnekrych(a)gmail.com&gt;wrote: >>> >>>> Not sure about the role: user. >>>> >>>> What will be the use case for this one? >>>> One use case, I see is if the 'user' is a tester. If we had the >>>> feature to send push notification test via admin UI (as we discussed in [1] >>>> and [2]). >>>> >>>> ++ >>>> Corinne >>>> [1] >>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Push-Server-Admin-... >>>> [2] https://issues.jboss.org/browse/AGPUSH-38 >>>> >>>> On Oct 17, 2013, at 3:09 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>> wrote: >>>> >>>> > >>>> > >>>> > >>>> > On Thu, Oct 17, 2013 at 2:54 PM, Sebastien Blanc < >>>> scm.blanc(a)gmail.com&gt; wrote: >>>> > >>>> > >>>> > >>>> > On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist < >>>> lholmqui(a)redhat.com&gt; wrote: >>>> > >>>> > On Oct 15, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>> wrote: >>>> > >>>> >> So for the next Unified Push Release (0.9) it would be nice if we >>>> could have some decent User Management, so I'm bumping this thread again. >>>> >> Some existing pointer : >>>> >> >>>> >> - this thread :) >>>> >> - https://issues.jboss.org/browse/AGPUSH-351 >>>> >> - https://gist.github.com/sebastienblanc/6547605 >>>> >> >>>> >> First point to define is : >>>> >> - What roles do we want ? And what can these Roles do ? >>>> > >>>> > Admin - Can do all things including creating other users >>>> > Developer - can create apps and such. no access to the user >>>> management UI >>>> > User - read only - not sure if this one is needed >>>> > Yes, not sure also but why not ? Could be useful for a monitoring >>>> app/RHQ plugin that just want to retrieve the list of active pushapps ... >>>> > >>>> > >>>> > +1 - I like these three different roles, including their rights >>>> > >>>> > >>>> > >>>> > >>>> >> - How can these Roles be created (granted ...) >>>> >> - Design >>>> > >>>> > I think we are still waiting on Hylke for this? not sure >>>> > >>>> >> >>>> >> Seb >>>> >> >>>> >> >>>> >> >>>> >> On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf < >>>> matzew(a)apache.org&gt; wrote: >>>> >> >>>> >> >>>> >> >>>> >> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis < >>>> aemmanou(a)redhat.com&gt; wrote: >>>> >> Following the discussion on GitHub [1], here are some points to be >>>> >> discussed about the user management flow: >>>> >> >>>> >> - Does it make sense to add a role select field (admin, developer) >>>> on >>>> >> the enrollment page? >>>> >> >>>> >> hrm, and (perhaps later) a section where to define the roles ? I >>>> think it's a good point, but not sure we need all this 'now' :-) >>>> >> >>>> >> - Should we add an additional password field (password >>>> confirmation) on >>>> >> the enrollment page? >>>> >> >>>> >> yeah, would be nice >>>> >> >>>> >> - I think that the current logged in user shouldn't be available for >>>> >> deletion >>>> >> >>>> >> yep, I agree >>>> >> >>>> >> [1]: >>>> >> >>>> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6 >>>> >> >>>> >> >>>> >> >>>> >> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote: >>>> >> > A Jira has been created >>>> https://issues.jboss.org/browse/AGPUSH-351 >>>> >> > And draft structure has been created >>>> >> > here https://gist.github.com/sebastienblanc/6547605 that can be >>>> used >>>> >> > as base for the Pull Request. >>>> >> > >>>> >> > >>>> >> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me&gt; >>>> wrote: >>>> >> > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira >>>> >> > wrote: >>>> >> > > Would be nice to have a 8 hands document on it >>>> >> > >>>> >> > >>>> >> > who's going to start the pull request on it? it's >>>> SPECTIME! >>>> >> > >>>> >> > -- >>>> >> > qmx >>>> >> > _______________________________________________ >>>> >> > 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 >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> aerogear-dev mailing list >>>> >> aerogear-dev(a)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(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 >>>> > >>>> > >>>> > _______________________________________________ >>>> > 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 >>>> > >>>> > >>>> > >>>> > -- >>>> > Matthias Wessendorf >>>> > >>>> > blog: http://matthiaswessendorf.wordpress.com/ >>>> > sessions: http://www.slideshare.net/mwessendorf >>>> > twitter: http://twitter.com/mwessendorf >>>> > _______________________________________________ >>>> > 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 >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > 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

If it can be made for the next release I would say let's keep it simple for now, 3 roles : -admin : can do all the CRUD operations + creating/deleting users -developer: can do all the CRUD operations -simple: can just do read operations

The default user (admin/123) should have the "admin" role. Users created by the admin can have the role developer or simple Users created by the admin will have the default 123 password to be changed the first time they log in. But ! The big questions remains around design, how to design that ?

Seb On Tue, Nov 5, 2013 at 4:09 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: What's the plan moving forward here ? -Matthias On Thu, Oct 17, 2013 at 4:17 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: Well, yes now that you said that :) Security based on Grouping. On Thu, Oct 17, 2013 at 4:15 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: you mean grouping ? On Thu, Oct 17, 2013 at 4:13 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: On Thu, Oct 17, 2013 at 3:44 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: any corp. org. may want some with just read-only access; The project lead is allowed to update the keys etc, but all the /normal/ developers can just see the IDs/secrets (so that they can use it in their server apps). This is also an interesting point, at some point don't we want the "read" rights limited to a single/set of pushapps or even a level deeper based on variants ? Maybe in a big company, Bob the slacker intern has read access for his supracool push app but also has access to the Public Relation Push App keys ... I guess that's not really (at least for me) closely related to a 'test via admin ui' feature -M On Thu, Oct 17, 2013 at 3:39 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: Not sure about the role: user. What will be the use case for this one? One use case, I see is if the 'user' is a tester. If we had the feature to send push notification test via admin UI (as we discussed in [1] and [2]). ++ Corinne [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Push-Server-Admin-... [2] https://issues.jboss.org/browse/AGPUSH-38 On Oct 17, 2013, at 3:09 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Thu, Oct 17, 2013 at 2:54 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > On Oct 15, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> So for the next Unified Push Release (0.9) it would be nice if we could have some decent User Management, so I'm bumping this thread again. >> Some existing pointer : >> >> - this thread :) >> - https://issues.jboss.org/browse/AGPUSH-351 >> - https://gist.github.com/sebastienblanc/6547605 >> >> First point to define is : >> - What roles do we want ? And what can these Roles do ? > > Admin - Can do all things including creating other users > Developer - can create apps and such. no access to the user management UI > User - read only - not sure if this one is needed > Yes, not sure also but why not ? Could be useful for a monitoring app/RHQ plugin that just want to retrieve the list of active pushapps ... > > > +1 - I like these three different roles, including their rights > > > > >> - How can these Roles be created (granted ...) >> - Design > > I think we are still waiting on Hylke for this? not sure > >> >> Seb >> >> >> >> On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >> >> >> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis <aemmanou(a)redhat.com&gt; wrote: >> Following the discussion on GitHub [1], here are some points to be >> discussed about the user management flow: >> >> - Does it make sense to add a role select field (admin, developer) on >> the enrollment page? >> >> hrm, and (perhaps later) a section where to define the roles ? I think it's a good point, but not sure we need all this 'now' :-) >> >> - Should we add an additional password field (password confirmation) on >> the enrollment page? >> >> yeah, would be nice >> >> - I think that the current logged in user shouldn't be available for >> deletion >> >> yep, I agree >> >> [1]: >> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6 >> >> >> >> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote: >> > A Jira has been created https://issues.jboss.org/browse/AGPUSH-351 >> > And draft structure has been created >> > here https://gist.github.com/sebastienblanc/6547605 that can be used >> > as base for the Pull Request. >> > >> > >> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: >> > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira >> > wrote: >> > > Would be nice to have a 8 hands document on it >> > >> > >> > who's going to start the pull request on it? it's SPECTIME! >> > >> > -- >> > qmx >> > _______________________________________________ >> > 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 >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(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 > > > _______________________________________________ > 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 > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ 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

If it can be made for the next release I would say let's keep it simple for now, 3 roles : -admin : can do all the CRUD operations + creating/deleting users -developer: can do all the CRUD operations -simple: can just do read operations

The default user (admin/123) should have the "admin" role. Users created by the admin can have the role developer or simple

Users created by the admin will have the default 123 password to be changed the first time they log in.

But ! The big questions remains around design, how to design that ?

Seb

On Tue, Nov 5, 2013 at 5:46 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > > > Matthias Wessendorf wrote: > > If it can be made for the next release I would say let's keep it > > simple for now, 3 roles : > > > > -admin : can do all the CRUD operations + creating/deleting users > > -developer: can do all the CRUD operations > > -simple: can just do read operations > +1 and oversimplifying here I would remove "simple". If people only can > read send to them a PDF :) > > > > The default user (admin/123) should have the "admin" role. > > > > Users created by the admin can have the role developer or simple > Probably if the server is still using the interceptor, it must support > multiple roles. What should I do into the following situations? > > - Delete ALL the things Endpoint annotated with developer and simple: > Logged in user has only the simple role and is not a developer. Should I > allow them to delete? > I think no delete here, since a 'simple' can only read (a PDF :-)

> > > > Users created by the admin will have the default 123 password to be > > changed the first time they log in. > I think it was already solved on unified push server, no? > > > > But ! > > > > The big questions remains around design, how to design that ? > Push the code and we refactor/improve/change it. > > > > Seb > > -- > abstractj > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

Well, I was thinking of annotating methods, so delete all the thing will be only for "developer" and "admin"

Sorry I don't get your example, why should destroyEverything() also have "simple" annotated?

On Tue, Nov 5, 2013 at 6:03 PM, Bruno Oliveira <bruno(a)abstractj.org&gt;wrote: > But if you are supporting multiple roles, you can't avoid such issue. > > For example: > > @Secure({"developer", "simple"}) > public void destroyEverything(){ > // access the nuclear reactor > } > > So the interceptor will look into this method and say "geez we have > simple role here" and bang! > > What would be the solution for such problem? > > Sebastien Blanc wrote: > > Well, I was thinking of annotating methods, so delete all the thing > > will be only for "developer" and "admin" > > -- > 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

On Tue, Nov 5, 2013 at 6:07 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Sorry I don't get your example, why should destroyEverything() also have > "simple" annotated? > yep - that endpoint would be never annotated w/ "simple"; I think the problem if the annotation contains "incorrect" roles or not is not a problem on the UPS. It's more an issue w/ the underlying security framework: E.g. how can I specify that someone with the role "simple" NEVER is able to (deep in the stack) can call entityManger.delete();

> > > > On Tue, Nov 5, 2013 at 6:03 PM, Bruno Oliveira <bruno(a)abstractj.org&gt;wrote: > >> But if you are supporting multiple roles, you can't avoid such issue. >> >> For example: >> >> @Secure({"developer", "simple"}) >> public void destroyEverything(){ >> // access the nuclear reactor >> } >> >> So the interceptor will look into this method and say "geez we have >> simple role here" and bang! >> >> What would be the solution for such problem? >> >> Sebastien Blanc wrote: >> > Well, I was thinking of annotating methods, so delete all the thing >> > will be only for "developer" and "admin" >> >> -- >> 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 >

Because you allowed the developer to do it. When we talk about insert multiple roles into the interceptor we are not talking about UPS only, but something more broader which might affect other projects. Keep in mind that I'm not against it, but we must think carefully before we change the rules.

Sebastien Blanc wrote: > Sorry I don't get your example, why should destroyEverything() also > have "simple" annotated? -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

As far as I recall (because we discussed it a long time ago). But I think you are talking about the following piece of code, right? I think the method below is still handy. /** * Role validation against the IDM * * @param roles roles to be checked * @return returns true if the current logged in has roles at the IDM, false otherwise */ @Override public boolean hasRoles(Set<String> roles) { if (identity.isLoggedIn()) { for (String role : roles) { Role retrievedRole = BasicModel.getRole(identityManager, role); if (retrievedRole != null && BasicModel.hasRole(partitionManager.createRelationshipManager(), identity.getAccount(), retrievedRole)) { return true; } } } return false; } Speaking about the interceptor, here comes some criticism about what I did: private void authorize(Set<String> roles) { boolean hasRoles = identityManagement.hasRoles(roles); if (!hasRoles) throw new AeroGearSecurityException(HttpStatus.CREDENTIAL_NOT_AUTHORIZED); } The code above doesn't open a security flaw, but being completely paranoid that should be refactored to authorize accept a single role (I can be wrong). But think about the following scenario (out of the UPS box). If the developer mistakenly add "simple", "admin" to the some method (is not impossible) which does some sensitive operation, this might be a problem.

As I told you guys, I'm not against it, but my job is to be picky and raise some concerns. AG Sec is not the holy grail of security and must be improved. Sebastien Blanc wrote: > But that is already something that we can do with AG PL , adding > multiple roles to the secure annotation. You said we should maybe > remove this from ag-pl ? -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

From the implementation point of view to have the idea:

Sorry I don't get your example, why should destroyEverything() also have "simple" annotated?

On Tue, Nov 5, 2013 at 6:03 PM, Bruno Oliveira < bruno(a)abstractj.org > wrote:

> But if you are supporting multiple roles, you can't avoid such issue.

> For example:

> @Secure({"developer", "simple"}) > public void destroyEverything(){ > // access the nuclear reactor > }

> So the interceptor will look into this method and say "geez we have > simple role here" and bang!

> What would be the solution for such problem?

> Sebastien Blanc wrote: > > Well, I was thinking of annotating methods, so delete all the thing > > will be only for "developer" and "admin"

> -- > 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

excuse me, but how does that related to the roles and structure that we discuss in THIS thead ? On Thu, Nov 7, 2013 at 1:33 PM, Stefan Miklosovic <smikloso(a)redhat.com&gt;wrote: > Hello, > > when I was doing some REST endpoints and I was trying to test that with APE > and Arquillian, I would like to see this one in the action: > > Given: > > I have this class > > @Secure( { "admin" }) > public class SomeClass { > > public void theFirstMethod() { > } > > @Secure({ "developer" }) > public void theSecondMethod() { > } > } > > When: > > I am logged in with "developer" role > > Then: > > I can call theSecondMethod but I can not call theFirstMethod. > > Right now, the implementation logic assumes that class level @Secure takes > it all, I would expect that class level scope is used when there is not any > annotation present on some particular method, otherwise that one on the > method level is used. > > From the implementation point of view to have the idea: > > @AroundInvoke > public Object invoke(InvocationContext ctx) throws Exception { > > Class clazz = ctx.getTarget().getClass(); > Method method = ctx.getMethod(); > > // this will be added > > // method beats the class > if (clazz.isAnnotationPresent(Secure.class) && > method.isAnnotationPresent(Secure.class)) { > authorize(methodMetadata(ctx)); > } > > // end of adding things > > if (clazz.isAnnotationPresent(Secure.class)) { > authorize(clazzMetadata(ctx)); > } > > Method method = ctx.getMethod(); > > if (method.isAnnotationPresent(Secure.class)) { > authorize(methodMetadata(ctx)); > } > return ctx.proceed(); > > However it is rather unknow how this fits into your perspective but I have > to say that I personally do not like the way how it is done right now. > > Regards > > Stefan Miklosovic > Red Hat Brno - JBoss Mobile Platform > > e-mail: smikloso(a)redhat.com > irc: smikloso > > ------------------------------ > > Sorry I don't get your example, why should destroyEverything() also have > "simple" annotated? > > > > On Tue, Nov 5, 2013 at 6:03 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; > wrote: > >> But if you are supporting multiple roles, you can't avoid such issue. >> >> For example: >> >> @Secure({"developer", "simple"}) >> public void destroyEverything(){ >> // access the nuclear reactor >> } >> >> So the interceptor will look into this method and say "geez we have >> simple role here" and bang! >> >> What would be the solution for such problem? >> >> Sebastien Blanc wrote: >> > Well, I was thinking of annotating methods, so delete all the thing >> > will be only for "developer" and "admin" >> >> -- >> 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 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

On Tue, Nov 5, 2013 at 4:35 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > > On Nov 5, 2013, at 10:34 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > If it can be made for the next release I would say let's keep it simple > for now, 3 roles : > > next ==> 0.9.0 (aka Nov. release) or after that ?

> > -admin : can do all the CRUD operations + creating/deleting users > -developer: can do all the CRUD operations > -simple: can just do read operations > > > +1 > +1 on these three roles > > > The default user (admin/123) should have the "admin" role. > > Users created by the admin can have the role developer or simple > > Users created by the admin will have the default 123 password to be > changed the first time they log in. > > But ! > > The big questions remains around design, how to design that ? > > +11 > > Seb > > > > > > > On Tue, Nov 5, 2013 at 4:09 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > >> What's the plan moving forward here ? >> -Matthias >> >> >> >> On Thu, Oct 17, 2013 at 4:17 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: >> >>> Well, yes now that you said that :) Security based on Grouping. >>> >>> >>> On Thu, Oct 17, 2013 at 4:15 PM, Matthias Wessendorf <matzew(a)apache.org >>> > wrote: >>> >>>> you mean grouping ? >>>> >>>> >>>> On Thu, Oct 17, 2013 at 4:13 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Oct 17, 2013 at 3:44 PM, Matthias Wessendorf < >>>>> matzew(a)apache.org&gt; wrote: >>>>> >>>>>> any corp. org. may want some with just read-only access; >>>>>> The project lead is allowed to update the keys etc, but all the >>>>>> /normal/ developers can just see the IDs/secrets (so that they can use it >>>>>> in their server apps). >>>>>> >>>>> >>>>> This is also an interesting point, at some point don't we want the >>>>> "read" rights limited to a single/set of pushapps or even a level deeper >>>>> based on variants ? >>>>> Maybe in a big company, Bob the slacker intern has read access for >>>>> his supracool push app but also has access to the Public Relation Push App >>>>> keys ... >>>>> >>>>> >>>>> >>>>>> I guess that's not really (at least for me) closely related to a >>>>>> 'test via admin ui' feature >>>>>> >>>>>> -M >>>>>> >>>>>> >>>>>> On Thu, Oct 17, 2013 at 3:39 PM, Corinne Krych < >>>>>> corinnekrych(a)gmail.com&gt; wrote: >>>>>> >>>>>>> Not sure about the role: user. >>>>>>> >>>>>>> What will be the use case for this one? >>>>>>> One use case, I see is if the 'user' is a tester. If we had the >>>>>>> feature to send push notification test via admin UI (as we discussed in [1] >>>>>>> and [2]). >>>>>>> >>>>>>> ++ >>>>>>> Corinne >>>>>>> [1] >>>>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Push-Server-Admin-... >>>>>>> [2] https://issues.jboss.org/browse/AGPUSH-38 >>>>>>> >>>>>>> On Oct 17, 2013, at 3:09 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>>>>> wrote: >>>>>>> >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On Thu, Oct 17, 2013 at 2:54 PM, Sebastien Blanc < >>>>>>> scm.blanc(a)gmail.com&gt; wrote: >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist < >>>>>>> lholmqui(a)redhat.com&gt; wrote: >>>>>>> > >>>>>>> > On Oct 15, 2013, at 11:14 AM, Sebastien Blanc < >>>>>>> scm.blanc(a)gmail.com&gt; wrote: >>>>>>> > >>>>>>> >> So for the next Unified Push Release (0.9) it would be nice if >>>>>>> we could have some decent User Management, so I'm bumping this thread again. >>>>>>> >> Some existing pointer : >>>>>>> >> >>>>>>> >> - this thread :) >>>>>>> >> - https://issues.jboss.org/browse/AGPUSH-351 >>>>>>> >> - https://gist.github.com/sebastienblanc/6547605 >>>>>>> >> >>>>>>> >> First point to define is : >>>>>>> >> - What roles do we want ? And what can these Roles do ? >>>>>>> > >>>>>>> > Admin - Can do all things including creating other users >>>>>>> > Developer - can create apps and such. no access to the user >>>>>>> management UI >>>>>>> > User - read only - not sure if this one is needed >>>>>>> > Yes, not sure also but why not ? Could be useful for a monitoring >>>>>>> app/RHQ plugin that just want to retrieve the list of active pushapps ... >>>>>>> > >>>>>>> > >>>>>>> > +1 - I like these three different roles, including their rights >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> >> - How can these Roles be created (granted ...) >>>>>>> >> - Design >>>>>>> > >>>>>>> > I think we are still waiting on Hylke for this? not sure >>>>>>> > >>>>>>> >> >>>>>>> >> Seb >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf < >>>>>>> matzew(a)apache.org&gt; wrote: >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis < >>>>>>> aemmanou(a)redhat.com&gt; wrote: >>>>>>> >> Following the discussion on GitHub [1], here are some points to >>>>>>> be >>>>>>> >> discussed about the user management flow: >>>>>>> >> >>>>>>> >> - Does it make sense to add a role select field (admin, >>>>>>> developer) on >>>>>>> >> the enrollment page? >>>>>>> >> >>>>>>> >> hrm, and (perhaps later) a section where to define the roles ? I >>>>>>> think it's a good point, but not sure we need all this 'now' :-) >>>>>>> >> >>>>>>> >> - Should we add an additional password field (password >>>>>>> confirmation) on >>>>>>> >> the enrollment page? >>>>>>> >> >>>>>>> >> yeah, would be nice >>>>>>> >> >>>>>>> >> - I think that the current logged in user shouldn't be available >>>>>>> for >>>>>>> >> deletion >>>>>>> >> >>>>>>> >> yep, I agree >>>>>>> >> >>>>>>> >> [1]: >>>>>>> >> >>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6 >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote: >>>>>>> >> > A Jira has been created >>>>>>> https://issues.jboss.org/browse/AGPUSH-351 >>>>>>> >> > And draft structure has been created >>>>>>> >> > here https://gist.github.com/sebastienblanc/6547605 that can >>>>>>> be used >>>>>>> >> > as base for the Pull Request. >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me&gt; >>>>>>> wrote: >>>>>>> >> > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno >>>>>>> Oliveira >>>>>>> >> > wrote: >>>>>>> >> > > Would be nice to have a 8 hands document on it >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > who's going to start the pull request on it? it's >>>>>>> SPECTIME! >>>>>>> >> > >>>>>>> >> > -- >>>>>>> >> > qmx >>>>>>> >> > _______________________________________________ >>>>>>> >> > 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 >>>>>>> >> >>>>>>> >> >>>>>>> >> _______________________________________________ >>>>>>> >> aerogear-dev mailing list >>>>>>> >> aerogear-dev(a)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(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 >>>>>>> > >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > 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 >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > Matthias Wessendorf >>>>>>> > >>>>>>> > blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> > sessions: http://www.slideshare.net/mwessendorf >>>>>>> > twitter: http://twitter.com/mwessendorf >>>>>>> > _______________________________________________ >>>>>>> > 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

In general, it is very hard to detect an improperly protected REST endpoint. Using least privilege principles could improve the control. Regarding the roles, how could someone create a new admin user? Having one and only one admin user with all access rights is a security vulnerability itself. If the same admin credentials are shared between several people/administrators it will be almost impossible to detect which one is the compromise. In conclusion my opinion is that: 1. Logging the endpoint accessibility is a must: e.g DateTime: User [admin] with roles [admin] accessed createUser endpoint 2. Roles should be based on delegation of duties. "developer" or "simple" roles do not reflect any duties and it's hard to guess their duties without reading the documentation. Of course, delegation of duties (e.g having a UserManagement role and the ability to assign it) will make the role based access management part of AeroGear Unified Push Server much more complex. However this will spread the risk of having a single admin user with all rights. On Tue, 2013-11-05 at 16:34 +0100, Sebastien Blanc wrote: > -admin : can do all the CRUD operations + creating/deleting users > The default user (admin/123) should have the "admin" role > Users created by the admin can have the role developer or simple _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev