On Mon, May 26, 2014 at 4:46 PM, Bruno Oliveira <bruno@abstractj.org> wrote:
On 2014-05-26, Matthias Wessendorf wrote:
> On Mon, May 26, 2014 at 4:20 PM, Bruno Oliveira <bruno@abstractj.org> wrote:
>
> > On 2014-05-26, Matthias Wessendorf wrote:
> > > On Mon, May 26, 2014 at 2:10 PM, Bruno Oliveira <bruno@abstractj.org>
> > wrote:
> > >
> > > >
> > > > Good morning peeps, after the latest change[1] correct me if I'm
> > wrong. But
> > > > I think KC and UPS will do pretty much what we need.
> > > >
> > > > We have a push admin and the super user on KC side enabled. Let me know
> > > > if that is what you need and I will take a look at viewer role.
> > > >
> > >
> > > One thing that I noticed: when I login as 'admin', I don't see the
> > > applications created by 'user'
> > > I think with that change, the 'admin' is the overall Keycloak-Admin.
> >
> > With the recent changes we have 2 admins:
> >
> > - KC admin
> > - UPS admin
> >
> > I think the UPS admin should have the visibility of all applications
> > created, right? I will look at this.
> >
>
> * super-user: in charge of managing the UPS realm (including users); can
> see _ALL_ push applications  (that's the 'admin' in Sebi's older gist)
> * PushAdmin: Someone that can manage applications and variants, but is not
> able to add new users; he also sees only his applications/variants etc
> (that's the 'developer' in sebisolder  gist)

You already said it in the previous e-mail, not necessary to say it
again. I think the point of confusion here is:

KC admin can't see your application/variants or whatever you want,
because it doesn't belong to KC. If you look at
http://docs.jboss.org/keycloak/docs/1.0-alpha-3/userguide/html_single/index.html#d4e311,
you will notice that KC is very good on managing application, but knows
nothing about UPS, which is correct.

yes, that's correct and makes sense.
 

>From my understanding we have 2 admins: KC and UPS. So when you say
super user, I can see into this way:

- super user: KC admin to manage realms, configurations, revoke clients,
  manage users...etc. 0 visibility of UPS domain, into other words this
  admin can't manage variants or applications.

- admin: UPS admin. This user can't manage realms, configuration, revoke
  clients, manage users...etc. But has full visibility of UPS domain,
  into other words manage variants or applications etc.


Let's see. We need a KC-Admin to manage the UPS-realm, but just that realm; Since we don't plan on shipping a 'full' Keycloak server, 
the option to create new realms etc should be disabled (e.g. according to Stian by removing the AdminRole)

For UPS, we might need two different roles:
* Super-User 
* Push-Admin

So, that the Super-User see the all five applications (for instance):
* two from PushAdmin_1
* three from PushAdmin_2

 


>
>
>
> >
> > >
> > >
> > > I had a chat w/ Stian in the past, for the above mentioned
> > > "super-user" (which is leveraging the Keycloak realm) Stian and I were
> > > thinking of a "Super User", that simply has not all permissions. For
> > > instance, it would have:
> > > * AdminRoles.VIEW_USERS
> > > * AdminRoles.MANAGE_USERS
> > >
> > > But it would not have the "AdminRoles.ADMIN" role. As we don't need to
> > have
> > > that guy/super-user being able to create realms or other applications,
> > just
> > > the "user access" items.
> > >
> > > I guess that's why we did see the 'remove()' before
> >
> > I understand the permission scope restriction for KC admin
> > (aka super-user). But if we remove the admin, how could you login to manage
> > users/roles?
> >
>
> The "super-admin" would be still able to manage the realm, but he would be
> no longer a 'real' KC admin, by removing the 'AdminRoles.ADMIN' role,
> that's what Stian and I were talking in the past.
> Perhaps he can say a bit more

Change permissions, I understand. But I don't understand why we need to
remove the user. Either way I will talk with Stian, thank you.

sounds good

 

>
>
>
>
> >
> > >
> > > -Matthias
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > > [1] -
> > > >
> > > >
> > https://github.com/aerogear/aerogear-unifiedpush-server/commit/3e118b1c758493942ef2a00e1541302a03e5519c
> > > >
> > > >
> > > > On 2014-05-21, Matthias Wessendorf wrote:
> > > > > Just a thought... regarding those two roles 'PushAdmin' and
> > 'Super-User',
> > > > > IMO the Super-user should be able to see all apps (and their
> > variants,
> > > > > including registered devices).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, May 21, 2014 at 2:55 PM, Bruno Oliveira <bruno@abstractj.org
> > >
> > > > wrote:
> > > > >
> > > > > > Thank you Matthias, I will look at it and return back with more
> > > > > > questions if necessary.
> > > > > >
> > > > > > On 2014-05-21, Matthias Wessendorf wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > yes - the handling is done by Keycloak itself; Last time we
> > looked at
> > > > > > user
> > > > > > > management, we had the following in terms of roles:
> > > > > > >
> > > > > > > https://gist.github.com/sebastienblanc/6547605
> > > > > > >
> > > > > > > Not sure the names of these roles are great.... let's see
> > > > > > >
> > > > > > > Basically I think the role definition in the gist still addresses
> > > > most of
> > > > > > > what we want to archive:
> > > > > > > * super-user: in charge of managing the UPS realm (including
> > users);
> > > > can
> > > > > > > see _ALL_ push applications  (that's the admin in Sebi's gist)
> > > > > > > * PushAdmin: Someone that can manage applications and variants,
> > but
> > > > is
> > > > > > not
> > > > > > > able to add new users; he also sees only his
> > applications/variants
> > > > etc
> > > > > > > (that's the developer in sebis gist)
> > > > > > >
> > > > > > > The gist also contains a 'Viewer' role - At this point I am not
> > sure
> > > > we
> > > > > > do
> > > > > > > really need this. My impression is that if we have PushAdmins
> > for our
> > > > > > 1.0.0
> > > > > > > community release that will be enough.
> > > > > > >
> > > > > > > -Matthias
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, May 20, 2014 at 10:02 PM, Bruno Oliveira <
> > > > bruno@abstractj.org
> > > > > > >wrote:
> > > > > > >
> > > > > > > > Good morning peeps,
> > > > > > > >
> > > > > > > > Before I jump in https://issues.jboss.org/browse/AGPUSH-639. I
> > > > would
> > > > > > > > like to understand what do you guys want say with this issue.
> > > > > > > >
> > > > > > > > Currently Keycloak already has its own user/roles managements.
> > > > What do
> > > > > > > > you guys are looking for? Any specific requirements?
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > abstractj
> > > > > > > > _______________________________________________
> > > > > > > > aerogear-dev mailing list
> > > > > > > > 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@lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > abstractj
> > > > > > _______________________________________________
> > > > > > aerogear-dev mailing list
> > > > > > 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@lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > --
> > > >
> > > > abstractj
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > 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@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
_______________________________________________
aerogear-dev mailing list
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