2:31 p.m.
Hi Juca,
For the dev environment, it looks like the keycloak appliance is used. Does it use an
embedded h2 database or something similar? Will realms, user, and other auth info be
persisted across restarts?
What are the steps for creating realms/users? I am thinking about after I do whatever is
necessary to install/start the appliance and after I start the metrics server.
Is there a way to easily disable the authentication/authorization? While it is not
critical, I am thinking it might be nice if we could do that in situations where we are
debugging test failures for instance.
On Jan 14, 2015, at 9:00 AM, Juraci Paixão Kröhling
<jpkroehling(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have collected some thoughts on this work created an "article" on
the RHQ.next space.
If there are more details needed/wanted, I can expand it. I didn't
want to put all the details there, otherwise "tl;dr" :-)
https://developer.jboss.org/wiki/KeycloakIntegration
- - Juca.
On 01/08/2015 03:33 PM, Juraci Paixão Kröhling wrote:
> On 01/08/2015 12:40 PM, Heiko W.Rupp wrote:
>> Also keep in mind that in the longer run we need to have a way
>> of granting some access rights to GET /tenants/foo/metrics/bla
>> from a user of tenant=acme.
>
> This is pretty much the only part which is not done yet on the PR.
> I can think of some solutions for that, but I'd wait until the
> initial version is merged.
>
> - Juca.
>
> _______________________________________________ rhq-devel mailing
> list rhq-devel(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUtnZtAAoJECKM1e+fkPrXJzQH/isLKuqKwG9XgO9MWO8hcxmz
fbc1EpBbloifJOuQfN67SzrQ2lOrFyV3LB9q9o/vLHakhGGhM0eZIbadChKta60k
MI02vppahpEp+pdW9aDnyr1dCyIbuecWikqPeyNPxCwfuhzYmAsFpUOwX3gUvtXN
/s0qDXrJ1yOsMzW3fGnjOCLWs6BtXERCxxklfbTbxtPn0Y8YV5Bv2Z4oV9C+syIs
kuGFMK3eTNA0OEQsqdQsAO2Tjd43I9Z0/9zpiaVtgRvIAm109Y/sBcOjS+AwNH2b
rhCOm+7Rh9NNgIXAkVMPWXLXX4yWaxWtpzhm/6/jYw5t6Xmg/vHpYdWgqAfd2Z8=
=SbsT
-----END PGP SIGNATURE-----
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel 
1:24 a.m.
New subject: Keycloak integration
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/20/2015 09:31 PM, John Sanda wrote:
For the dev environment, it looks like the keycloak appliance is
used. Does it use an embedded h2 database or something similar?
Will realms, user, and other auth info be persisted across
restarts?
Yes, it uses an embedded database and data is persisted across restarts.
What are the steps for creating realms/users? I am thinking about
after I do whatever is necessary to install/start the appliance and
after I start the metrics server.
The usual way to create a realm is by logging in as admin on the
Keycloak console (/auth) and creating a realm from there. It's also
possible to import a realm during the server startup by passing a
system property pointing to the realm's JSON file (which is what we do
in the start.sh).
To create a regular user, you can just self-register. Once you access
the Hawkular's web console, you'll be redirected to a login screen. On
this screen, there's a "register" link. You can use it to register
yourself. To change the roles, you'll need to login to the Keycloak
web console as admin and add roles to your user.
Is there a way to easily disable the authentication/authorization?
While it is not critical, I am thinking it might be nice if we
could do that in situations where we are debugging test failures
for instance.
Yes: just remove the authentication parts on the web.xml . Everything
should work fine. Not sure, though, what would happen if you try to
call a resource that is protected by the container via @RolesAllowed.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUv1Q7AAoJECKM1e+fkPrXfFYIAJu06+Tg8suTU0pSWKbp8b1o
+ISU8htC3HXMMvXoE9dDqA3wQHPrChlN8sOwBciaQyLkv6RvM0EPfbxYQc6G6f25
2Ln0NM6tc7QVVgQYYcW+nIkbzWrX7cRpooPsqqM7KrWv7a5RUinhQWqNqky6VIPJ
oJQiwRUlpqzmeKMGhKtxWJwcEwyezKvVnwUp+c4VL1rSNxFJqqOItWfliWfxkS1s
Jzh/4WQt8QkoYtiuGxO3LwDsPNkfv/EQ3pYzWLYYNKKHmCzJNP8n+W+4P9QDZzLi
4MEBjcrwyRTi50x8mOUoPZKHdf3nh2MjVoHKdZaU36qnXejkf+i7zd372R+nogA=
=nkOZ
-----END PGP SIGNATURE-----
5:20 a.m.
New subject: Keycloak integration
Le 21/01/2015 08:24, Juraci Paixão Kröhling a écrit :
> Is there a way to easily disable the
authentication/authorization?
> >While it is not critical, I am thinking it might be nice if we
> >could do that in situations where we are debugging test failures
> >for instance.
Yes: just remove the authentication parts on the web.xml . Everything
should work fine. Not sure, though, what would happen if you try to
call a resource that is protected by the container via @RolesAllowed.
What does the KC team recommend to do for such problems (which are most
probably shared across users)?
7:32 a.m.
New subject: Keycloak integration
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/21/2015 12:20 PM, Thomas Segismont wrote:
Le 21/01/2015 08:24, Juraci Paixão Kröhling a écrit :
>> Is there a way to easily disable the
>> authentication/authorization?
>>> While it is not critical, I am thinking it might be nice if
>>> we could do that in situations where we are debugging test
>>> failures for instance.
> Yes: just remove the authentication parts on the web.xml .
> Everything should work fine. Not sure, though, what would happen
> if you try to call a resource that is protected by the container
> via @RolesAllowed.
What does the KC team recommend to do for such problems (which are
most probably shared across users)?
Just had a quick chat with Marek about it and he suggested something
similar: to disable it via web.xml . There's no flag or special setup
that would allow an application otherwise protected by Keycloak to
bypass it, as it could be viewed as an attack vector.
One interesting thought that he shared was: if the application were to
be protected by any other JAAS provider, the auth would also have to
be disabled on web.xml . In that sense, I think that auth could be
counted on something that is part of the environment, like the
application server itself.
If we face a situation where disabling the auth is indeed valuable,
I'll try to come up with the flag that would accomplish that and see
if the Keycloak team would accept a PR.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUv6pTAAoJECKM1e+fkPrXUxUH/1i0naSA6XfYavsCyINLlfR4
C3vB3IWpDtMkEX4lsbt6J7EI0EKpZty7Up5OeaQhngHueIUyVqPRVBUn/PZmCdqD
PdmraLzv9+3aPtcPavT3uVZqpMgeJ9l+BjQW+z/ouj/VMwTkz/X6u2/Eim6ZzX4B
364R5KWxnZkLIftgOreACqTRlVLn5ErPTP1jSE58o7cXjbAb5EARXareXVWHOtdE
2SjtBBdO9xYVfPm37+CD7FnRl/s00e+DHFaDHWDqHm1D+uuCTR6zm81KO8Dcg855
e5hFtybRYaSStmjwOJFDJ+D7wtPJXzjgtpjAoM3PhDx6VjslVXoJJjkfVJPft20=
=fKcB
-----END PGP SIGNATURE-----
3579
days inactive
3580
days old
3 comments
3 participants
participants (3)
-
John Sanda -
Juraci Paixão Kröhling -
Thomas Segismont