<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 4, 2013 at 5:22 PM, Lucas Holmquist <span dir="ltr">&lt;<a href="mailto:lholmqui@redhat.com" target="_blank">lholmqui@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently i think &quot;Apps&quot; are associated with a specific user,  so if we introduce new users, then those new users won&#39;t be able to see any of the existing apps,  even if they have the same roles.<br>
</blockquote><div><br></div><div style>That&#39;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.</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
this should probably change to be more role based,  example:<br>
<br>
Admin role:<br>
        All CRUD on Apps and CRUD user management<br>
Developer:<br>
        CRUD on Apps<br>
User:<br>
        just READ Apps<br>
<div><div class="h5"><br>
<br>
<br>
On Sep 4, 2013, at 11:06 AM, Bruno Oliveira &lt;<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt; Sebastien Blanc wrote:<br>
&gt;&gt; Hi,<br>
&gt;&gt; Start point is this jira <a href="https://issues.jboss.org/browse/AGPUSH-282" target="_blank">https://issues.jboss.org/browse/AGPUSH-282</a> for<br>
&gt;&gt; allowing the creation of additional users/developers.<br>
&gt;&gt; In the current situation we have just one role : &quot;developer&quot; , so the<br>
&gt;&gt; first question is :<br>
&gt;&gt;<br>
&gt;&gt; - Should a user with the role &quot;developer&quot; be able to create another user ?<br>
&gt;<br>
&gt; It depends, I think is a matter of rules inside AGPUSH. Maybe we should<br>
&gt; have a role hierarchy definition? Would be nice.<br>
&gt;<br>
&gt;&gt; - Should we introduce a &quot;admin&quot; role that can manage users (create,<br>
&gt;&gt; reset password, delete) ?<br>
&gt;<br>
&gt; Makes sense.<br>
&gt;<br>
&gt;&gt; - A mix of permissions ? (a developer can create other users but not<br>
&gt;&gt; remove them nor reset (except its own) password )<br>
&gt;<br>
&gt; The hierarchy should be clear users/roles and levels, we can start a<br>
&gt; simple gist on it.<br>
&gt;&gt;<br>
&gt;&gt; From there the second question regarding password management :<br>
&gt;&gt; In the current situation, our default user (called &quot;admin&quot; , yeah a bit<br>
&gt;&gt; confusing :) ) has a temporary password that must be changed the first<br>
&gt;&gt; time he logs in.<br>
&gt;&gt;<br>
&gt;&gt; - Do we want to keep this ?<br>
&gt;<br>
&gt; That is a old request from my side and violates CWE-798<br>
&gt; (<a href="http://cwe.mitre.org/data/definitions/798.html" target="_blank">http://cwe.mitre.org/data/definitions/798.html</a>)<br>
&gt;&gt;<br>
&gt;&gt; - Shall we move to a script that creates a user(s) ?<br>
&gt;<br>
&gt; +1 for provide a script like &quot;sample-db.sql&quot; or whatever out of the box.<br>
</div></div>+1<br>
<div class="HOEnZb"><div class="h5">&gt;&gt;<br>
&gt;&gt; - When we add a user through the admin UI, should we provide a password<br>
&gt;&gt; or should it be generated and changed on first login ?<br>
&gt;<br>
&gt; In theory we should send the password reset instructions with the url to<br>
&gt; change it like:<br>
&gt;<br>
&gt; <a href="http://admin-ui.org/changeme/424242424242424" target="_blank">http://admin-ui.org/changeme/424242424242424</a> (Using the SecureRandom<br>
&gt; entropy from Java)<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; In other words, I think we must concretely spec out the user management<br>
&gt;&gt; for the UPS and we could use this thread to discuss that !<br>
&gt;<br>
&gt; +1 I&#39;m all for it<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; aerogear-dev mailing list<br>
&gt;&gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
&gt;<br>
&gt; --<br>
&gt; abstractj<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; aerogear-dev mailing list<br>
&gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br></div></div>