On Mon, May 26, 2014 at 4:46 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
On 2014-05-26, Matthias Wessendorf wrote:
> On Mon, May 26, 2014 at 4:20 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
>
> > On 2014-05-26, Matthias Wessendorf wrote:
> > > On Mon, May 26, 2014 at 2:10 PM, Bruno Oliveira <bruno(a)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/ind...
,
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/3e118b1c75...
> > > >
> > > >
> > > > 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(a)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(a)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(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
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > abstractj
> > > > > > _______________________________________________
> > > > > > 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
> > > >
> > > >
> > > > --
> > > >
> > > > abstractj
> > > > _______________________________________________
> > > > 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
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > 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
--
abstractj
_______________________________________________
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