4:06 p.m.
Great work Marko!
As we didn't have time to go through feedback let's use this thread for it.
Add your questions and comments here please.
4:47 p.m.
And if anyone wants to get their feet wet already:
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
Great work Marko!
As we didn't have time to go through feedback let's use this thread for
it. Add your questions and comments here please.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:04 p.m.
Looks good. Are we going to have similar CLI efforts to manage other
parts of the server?
On 7/21/16 10:47 AM, Marko Strukelj wrote:
And if anyone wants to get their feet wet already:
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
Great work Marko!
As we didn't have time to go through feedback let's use this
thread for it. Add your questions and comments here please.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:16 p.m.
Yes, I'll start working on Admin CLI soon.
I'll put together a design document for it first.
On Thu, Jul 21, 2016 at 5:04 PM, Bill Burke <bburke(a)redhat.com> wrote:
Looks good. Are we going to have similar CLI efforts to manage
other
parts of the server?
On 7/21/16 10:47 AM, Marko Strukelj wrote:
And if anyone wants to get their feet wet already:
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> Great work Marko!
>
> As we didn't have time to go through feedback let's use this thread for
> it. Add your questions and comments here please.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:15 p.m.
Nice work Marko! I had two (not big deal) questions. First, when you
specify the --cache parameters as you did for SAML, could the cache file be omitted?
For example: kcreg --cache -r saml-realm ...
I was thinking that once you specified the realm name, the API will just
look for ~/.keycloak/saml-realm.cache. It's just an idea.
Second question, is more like something to think if worth to take
into consideration. Most of the examples that I saw, make use of
username/password. But if the admin enables two factor authentication,
she might be unable to use our client-reg CLI, or enforce weaken security only
to make use of the CLI.
Is OTP support planned for further iterations?
On 2016-07-21, Marko Strukelj wrote:
And if anyone wants to get their feet wet already:
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> Great work Marko!
>
> As we didn't have time to go through feedback let's use this thread for
> it. Add your questions and comments here please.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
PGP: 0x84DC9914
9:26 a.m.
It should be fairly easy to add support for OTP as well as the direct grant
supports that. The user would have to specify to use OTP though.
On 21 July 2016 at 19:15, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Nice work Marko! I had two (not big deal) questions. First, when you
specify the --cache parameters as you did for SAML, could the cache file
be omitted?
For example: kcreg --cache -r saml-realm ...
I was thinking that once you specified the realm name, the API will just
look for ~/.keycloak/saml-realm.cache. It's just an idea.
Second question, is more like something to think if worth to take
into consideration. Most of the examples that I saw, make use of
username/password. But if the admin enables two factor authentication,
she might be unable to use our client-reg CLI, or enforce weaken security
only
to make use of the CLI.
Is OTP support planned for further iterations?
On 2016-07-21, Marko Strukelj wrote:
> And if anyone wants to get their feet wet already:
>
>
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
>
>
> On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
> > Great work Marko!
> >
> > As we didn't have time to go through feedback let's use this thread
for
> > it. Add your questions and comments here please.
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
PGP: 0x84DC9914
9:33 a.m.
A few questions from me:
* Is it possible to view the returned JSON when creating and updating a
client? This contains values filled in by the server, including the
registration access token.
* Should we not enable pretty print by default?
* --cache isn't the most intuitive name, I don't have a better suggestion
though
* Docs should be moved to Gitbook "Securing Clients and Applications guide"
* When creating clients and later updating them I assume it uses the
registration access token from the cache?
* A nice addition would be the ability to list attributes from
ClientRepresentation so it's easy to discover what attributes can be set
* What about setting/changing complex attributes, how does that look like?
Can we add/remove to an array? Add/remove elements to a complex object?
Something like JSON patch could be nice https://tools.ietf.org/html/rfc6902
On 22 July 2016 at 09:26, Stian Thorgersen <sthorger(a)redhat.com> wrote:
It should be fairly easy to add support for OTP as well as the
direct
grant supports that. The user would have to specify to use OTP though.
On 21 July 2016 at 19:15, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Nice work Marko! I had two (not big deal) questions. First, when you
> specify the --cache parameters as you did for SAML, could the cache file
> be omitted?
>
> For example: kcreg --cache -r saml-realm ...
>
> I was thinking that once you specified the realm name, the API will just
> look for ~/.keycloak/saml-realm.cache. It's just an idea.
>
> Second question, is more like something to think if worth to take
> into consideration. Most of the examples that I saw, make use of
> username/password. But if the admin enables two factor authentication,
> she might be unable to use our client-reg CLI, or enforce weaken security
> only
> to make use of the CLI.
>
> Is OTP support planned for further iterations?
>
>
> On 2016-07-21, Marko Strukelj wrote:
> > And if anyone wants to get their feet wet already:
> >
> >
>
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
> >
> >
> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger(a)redhat.com>
> > wrote:
> >
> > > Great work Marko!
> > >
> > > As we didn't have time to go through feedback let's use this
thread
> for
> > > it. Add your questions and comments here please.
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
>
9:40 a.m.
One more:
* How should we distribute it? I propose we just add kcreg.sh/kcreg.bat +
the JAR to the bin directory of the server
On 22 July 2016 at 09:33, Stian Thorgersen <sthorger(a)redhat.com> wrote:
A few questions from me:
* Is it possible to view the returned JSON when creating and updating a
client? This contains values filled in by the server, including the
registration access token.
* Should we not enable pretty print by default?
* --cache isn't the most intuitive name, I don't have a better suggestion
though
* Docs should be moved to Gitbook "Securing Clients and Applications guide"
* When creating clients and later updating them I assume it uses the
registration access token from the cache?
* A nice addition would be the ability to list attributes from
ClientRepresentation so it's easy to discover what attributes can be set
* What about setting/changing complex attributes, how does that look like?
Can we add/remove to an array? Add/remove elements to a complex object?
Something like JSON patch could be nice
https://tools.ietf.org/html/rfc6902
On 22 July 2016 at 09:26, Stian Thorgersen <sthorger(a)redhat.com> wrote:
> It should be fairly easy to add support for OTP as well as the direct
> grant supports that. The user would have to specify to use OTP though.
>
> On 21 July 2016 at 19:15, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>
>> Nice work Marko! I had two (not big deal) questions. First, when you
>> specify the --cache parameters as you did for SAML, could the cache file
>> be omitted?
>>
>> For example: kcreg --cache -r saml-realm ...
>>
>> I was thinking that once you specified the realm name, the API will just
>> look for ~/.keycloak/saml-realm.cache. It's just an idea.
>>
>> Second question, is more like something to think if worth to take
>> into consideration. Most of the examples that I saw, make use of
>> username/password. But if the admin enables two factor authentication,
>> she might be unable to use our client-reg CLI, or enforce weaken
>> security only
>> to make use of the CLI.
>>
>> Is OTP support planned for further iterations?
>>
>>
>> On 2016-07-21, Marko Strukelj wrote:
>> > And if anyone wants to get their feet wet already:
>> >
>> >
>>
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
>> >
>> >
>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger(a)redhat.com
>> >
>> > wrote:
>> >
>> > > Great work Marko!
>> > >
>> > > As we didn't have time to go through feedback let's use this
thread
>> for
>> > > it. Add your questions and comments here please.
>> > >
>> > > _______________________________________________
>> > > keycloak-dev mailing list
>> > > keycloak-dev(a)lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > >
>>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>>
>
>
11:37 a.m.
On Thu, Jul 21, 2016 at 7:15 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Second question, is more like something to think if worth to take
> On 2016-07-21, Marko Strukelj wrote:
> > And if anyone wants to get their feet wet already:
> > >
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
> > > > On Thu, Jul 21, 2016 at
4:06 PM, Stian Thorgersen <sthorger(a)redhat.com > >
wrote:
> > > > Great work Marko!
> > > > > As we didn't have
time to go through feedback let's use this thread for
> > > it. Add your questions and comments here please.
> > > > >
_______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> --
> abstractj
> PGP: 0x84DC9914
Nice work Marko!
I had two (not big deal) questions. First, when you
specify the --cache parameters as you did for SAML, could the cache
file
be omitted?
For example: kcreg --cache -r saml-realm ...
I was thinking that once you specified the realm name, the API will just
look for ~/.keycloak/saml-realm.cache. It's just an idea
We could maybe add this behaviour in addition to current behaviour. It's
not enough to just specify a realm though, since server can also be
different. For example:
# login as admin user in master realm on localhost using default cache
file (~/.keycloak/kcreg.cache)
kcreg login -s http://localhost:8080/auth -r master -u admin
# login as admin user in master realm on login.example.com using a
different cache file
kcreg --cache ~/.keycloak/example_com.cache login -s
http://login.example.com -r master -u admin
Using kcreg --cache -r master ... as above would default to the same file
(~/.keycloak/master.cache) unless we also include server_endpoint in the
file name e.g.: localhost_8080_auth_master.cache. But then - login command
gets the server specified by user. Not so with other commands.
The current mechanism reads the server from the specified cache file (the
server for current session it's stored inside a JSON):
kcreg --cache ~/.keycloak/localhost_8080_auth_master.cache get my_client
So your proposal is unable to determine the full name of the file - we need
to know the server already to compose the file name:
kcreg --cache -r master get my_client
The above can resolve to ~/.keycloak/master.cache but doesn't have enough
info to resolve to ~/.keycloak/localhost_8080_auth_master.cache.
If we also have to specify server the result is not worth the bother:
kcreg --cache -s http://localhost:8080/auth -r master get my_client
Another thing - if we want to also support current behavior (which allows
all the freedom and flexibility of choosing any location on the filesystem
for the cache file) we would then need to treat additional argument to
--cache as optional, which can quickly get tricky:
kcreg --cache login -r master ...
vs.
kcreg --cache /tmp/session.cache -x login ...
vs.
kcreg --cache -r master get ...
We could do that by checking if next argument begins with a '-' but that
would disable usage of any filename starting with '-'. And we would have to
treat it differently for login ...
The more I look at it, the more complex and tricky it gets to get it right.
One quite simple solution towards more ergonomic usage would be to simply
differentiate whether the specified path is absolute or relative, and if
relative we could default the directory to ~/.keycloak.
For example:
kcreg --cache master login -s http://localhost:8080/auth -r master -u admin
This would generate the following cache file: ~/.keycloak/master.cache, and
the folling command would use that file as well:
kcreg --cache master get my_client
The absolute names would be those starting with /, ~/ on unix, c:\, d:\ ...
on Windows
This behaviour is easy to add.
into consideration. Most of the examples that I saw, make use of
username/password. But if the admin enables two factor authentication,
she might be unable to use our client-reg CLI, or enforce weaken security
only
to make use of the CLI.
Is OTP support planned for further iterations?
I don't know how exactly OTP auth works under the hood, but if Stian says
it's no problem and it's easy to implement then that's your answer :)
12:02 p.m.
On Fri, Jul 22, 2016 at 9:33 AM, Stian Thorgersen <sthorger(a)redhat.com wrote:
The only doc currently is the README file, so I guess
that's the one you
mean. I'd wait a bit with adding it to docbook. The later I make a copy in
Gitbook the less double work will there be editing the changes.
> * When creating clients and later updating them I assume it uses the
> registration access token from the cache?
Yes. If it can't find one it uses bearer token from login.
> * A nice addition would be the ability to list attributes from
> ClientRepresentation so it's easy to discover what attributes can be set
That's trivial to add using reflection. But how would the
UI look? Ideally
we'd have tab completion for this at some point.
Something like this?
$ kcreg list-attrs
clientId String
redirectUris List<String baseUrl String
enabled Boolean
...
$ kcreg list-attrs -e oidc
redirect_uris List<String grant_types List<String
However if we want to be more specific, with some additional help on the
meaning, and possible values, then we would need to annotate Representation
classes with the necessary info, or simply have a help-style static text.
> * What about setting/changing complex attributes, how does that look like?
> Can we add/remove to an array? Add/remove elements to a complex object?
> Something like JSON patch could be nice
> https://tools.ietf.org/html/rfc6902
I haven't gone so far with this iteration. That's a
TODO.
> On 22 July 2016 at 09:26, Stian Thorgersen
<sthorger(a)redhat.com> wrote:
>> It should be fairly easy to add support for OTP as
well as the direct
>> grant supports that. The user would have to specify to use OTP though.
> >> On 21 July 2016 at 19:15, Bruno Oliveira
<bruno(a)abstractj.org> wrote:
> >>> Nice work Marko! I had two (not big deal)
questions. First, when you
>>> specify the --cache parameters as you did for SAML, could the cache file
>>> be omitted?
>> >>> For example: kcreg
--cache -r saml-realm ...
>> >>> I was thinking that
once you specified the realm name, the API will just
>>> look for ~/.keycloak/saml-realm.cache. It's just an idea.
>> >>> Second question, is
more like something to think if worth to take
>>> into consideration. Most of the examples that I saw, make use of
>>> username/password. But if the admin enables two factor authentication,
>>> she might be unable to use our client-reg CLI, or enforce weaken
>>> security only
>>> to make use of the CLI.
>> >>> Is OTP support planned
for further iterations?
>> >> >>> On 2016-07-21, Marko Strukelj wrote:
>>> > And if anyone wants to get their feet wet already:
>>> >>> >>>
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
>>> >>> >>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian
Thorgersen <sthorger(a)redhat.com
>>> >>> > wrote:
>>> >>> > > Great work
Marko!
>>> > >>> > > As we
didn't have time to go through feedback let's use this thread
>>> for
>>> > > it. Add your questions and comments here please.
>>> > >>> > >
_______________________________________________
>>> > > keycloak-dev mailing list
>>> > > keycloak-dev(a)lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > >> >>> >
_______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >>> --
>> >>> abstractj
>>> PGP: 0x84DC9914
>> > >
A few questions from me:
* Is it possible to view the returned JSON when creating and updating a
client? This contains values filled in by the server, including the
registration access token.
Not ATM. I can add an option e.g. -o, --output Display the new state
of client configuration.
* Should we not enable pretty print by default?
I suppose that would be more user friendly. Just don't know how to name the
switch -p, --pretty is so obvious ...
* --cache isn't the most intuitive name, I don't have a
better suggestion
though
OpenShift client uses the term configuration rather than cache, and uses
--config accordingly. We could do the same, and even add 'kcreg config'
command to inspect and edit the config file if we deem that necessary.
* Docs should be moved to Gitbook "Securing Clients and Applications guide"
12:05 p.m.
If changing the interface is going to be tricky, just ignore my idea. I haven't
played with it yet, so any suggestion will be really inaccurate :)
On 2016-07-22, Marko Strukelj wrote:
On Thu, Jul 21, 2016 at 7:15 PM, Bruno Oliveira
<bruno(a)abstractj.org> wrote:
> Nice work Marko!
I had two (not big deal) questions. First, when you
> specify the --cache parameters as you did for SAML, could the cache file
> be omitted?
>
> For example: kcreg --cache -r saml-realm ...
>
> I was thinking that once you specified the realm name, the API will just
> look for ~/.keycloak/saml-realm.cache. It's just an idea
We could maybe add this behaviour in addition to current behaviour. It's
not enough to just specify a realm though, since server can also be
different. For example:
# login as admin user in master realm on localhost using default cache
file (~/.keycloak/kcreg.cache)
kcreg login -s http://localhost:8080/auth -r master -u admin
# login as admin user in master realm on login.example.com using a
different cache file
kcreg --cache ~/.keycloak/example_com.cache login -s
http://login.example.com -r master -u admin
Using kcreg --cache -r master ... as above would default to the same file
(~/.keycloak/master.cache) unless we also include server_endpoint in the
file name e.g.: localhost_8080_auth_master.cache. But then - login command
gets the server specified by user. Not so with other commands.
The current mechanism reads the server from the specified cache file (the
server for current session it's stored inside a JSON):
kcreg --cache ~/.keycloak/localhost_8080_auth_master.cache get my_client
So your proposal is unable to determine the full name of the file - we need
to know the server already to compose the file name:
kcreg --cache -r master get my_client
The above can resolve to ~/.keycloak/master.cache but doesn't have enough
info to resolve to ~/.keycloak/localhost_8080_auth_master.cache.
If we also have to specify server the result is not worth the bother:
kcreg --cache -s http://localhost:8080/auth -r master get my_client
Another thing - if we want to also support current behavior (which allows
all the freedom and flexibility of choosing any location on the filesystem
for the cache file) we would then need to treat additional argument to
--cache as optional, which can quickly get tricky:
kcreg --cache login -r master ...
vs.
kcreg --cache /tmp/session.cache -x login ...
vs.
kcreg --cache -r master get ...
We could do that by checking if next argument begins with a '-' but that
would disable usage of any filename starting with '-'. And we would have to
treat it differently for login ...
The more I look at it, the more complex and tricky it gets to get it right.
One quite simple solution towards more ergonomic usage would be to simply
differentiate whether the specified path is absolute or relative, and if
relative we could default the directory to ~/.keycloak.
For example:
kcreg --cache master login -s http://localhost:8080/auth -r master -u admin
This would generate the following cache file: ~/.keycloak/master.cache, and
the folling command would use that file as well:
kcreg --cache master get my_client
The absolute names would be those starting with /, ~/ on unix, c:\, d:\ ...
on Windows
This behaviour is easy to add.
>
>
Second question, is more like something to think if worth to take
> into consideration. Most of the examples that I saw, make use of
> username/password. But if the admin enables two factor authentication,
> she might be unable to use our client-reg CLI, or enforce weaken security
> only
> to make use of the CLI.
>
> Is OTP support planned for further iterations?
I don't know how exactly OTP auth works under the hood, but if Stian says
it's no problem and it's easy to implement then that's your answer :)
>
> On 2016-07-21, Marko Strukelj wrote:
> > And if anyone wants to get their feet wet already:
> >
> >
>
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
> >
> >
> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger(a)redhat.com>
> > wrote:
> >
> > > Great work Marko!
> > >
> > > As we didn't have time to go through feedback let's use this
thread for
> > > it. Add your questions and comments here please.
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
>
--
abstractj
PGP: 0x84DC9914
12:11 p.m.
I don't have kcreg.bat yet ... contributions welcome :)
Making it part of keycloak server distro makes sense. OTOH I believe we
have some developers that just deal with HTML5 web apps who don't have
Keycloak Server installed locally. If that was the only way to get kcreg
they would have to download the whole server just to get the tool. For them
it makes sense to also have a separate CLI Tools download.
On Fri, Jul 22, 2016 at 9:40 AM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
One more:
* How should we distribute it? I propose we just add kcreg.sh/kcreg.bat +
the JAR to the bin directory of the server
On 22 July 2016 at 09:33, Stian Thorgersen <sthorger(a)redhat.com> wrote:
> A few questions from me:
>
> * Is it possible to view the returned JSON when creating and updating a
> client? This contains values filled in by the server, including the
> registration access token.
> * Should we not enable pretty print by default?
> * --cache isn't the most intuitive name, I don't have a better suggestion
> though
> * Docs should be moved to Gitbook "Securing Clients and Applications
> guide"
> * When creating clients and later updating them I assume it uses the
> registration access token from the cache?
> * A nice addition would be the ability to list attributes from
> ClientRepresentation so it's easy to discover what attributes can be set
> * What about setting/changing complex attributes, how does that look
> like? Can we add/remove to an array? Add/remove elements to a complex
> object? Something like JSON patch could be nice
> https://tools.ietf.org/html/rfc6902
>
> On 22 July 2016 at 09:26, Stian Thorgersen <sthorger(a)redhat.com> wrote:
>
>> It should be fairly easy to add support for OTP as well as the direct
>> grant supports that. The user would have to specify to use OTP though.
>>
>> On 21 July 2016 at 19:15, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>>
>>> Nice work Marko! I had two (not big deal) questions. First, when you
>>> specify the --cache parameters as you did for SAML, could the cache
>>> file be omitted?
>>>
>>> For example: kcreg --cache -r saml-realm ...
>>>
>>> I was thinking that once you specified the realm name, the API will just
>>> look for ~/.keycloak/saml-realm.cache. It's just an idea.
>>>
>>> Second question, is more like something to think if worth to take
>>> into consideration. Most of the examples that I saw, make use of
>>> username/password. But if the admin enables two factor authentication,
>>> she might be unable to use our client-reg CLI, or enforce weaken
>>> security only
>>> to make use of the CLI.
>>>
>>> Is OTP support planned for further iterations?
>>>
>>>
>>> On 2016-07-21, Marko Strukelj wrote:
>>> > And if anyone wants to get their feet wet already:
>>> >
>>> >
>>>
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
>>> >
>>> >
>>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <
>>> sthorger(a)redhat.com>
>>> > wrote:
>>> >
>>> > > Great work Marko!
>>> > >
>>> > > As we didn't have time to go through feedback let's use
this thread
>>> for
>>> > > it. Add your questions and comments here please.
>>> > >
>>> > > _______________________________________________
>>> > > keycloak-dev mailing list
>>> > > keycloak-dev(a)lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > >
>>>
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> --
>>>
>>> abstractj
>>> PGP: 0x84DC9914
>>>
>>
>>
>
12:12 p.m.
On 2016-07-22, Marko Strukelj wrote:
On Fri, Jul 22, 2016 at 9:33 AM, Stian Thorgersen
<sthorger(a)redhat.com>
wrote:
> A few questions from me:
>
> * Is it possible to view the returned JSON when creating and updating a
> client? This contains values filled in by the server, including the
> registration access token.
>
Not ATM. I can add an option e.g. -o, --output Display the new state
of client configuration.
> * Should we not enable pretty print by default?
>
I suppose that would be more user friendly. Just don't know how to name the
switch -p, --pretty is so obvious ...
Some command line interfaces use --format.
> * --cache isn't the most intuitive name, I don't have a better suggestion
> though
>
OpenShift client uses the term configuration rather than cache, and uses
--config accordingly. We could do the same, and even add 'kcreg config'
command to inspect and edit the config file if we deem that necessary.
* Docs should be moved to Gitbook "Securing Clients and Applications guide"
>
The only doc currently is the README file, so I guess that's the one you
mean. I'd wait a bit with adding it to docbook. The later I make a copy in
Gitbook the less double work will there be editing the changes.
> * When creating clients and later updating them I assume it uses the
> registration access token from the cache?
>
Yes. If it can't find one it uses bearer token from login.
> * A nice addition would be the ability to list attributes from
> ClientRepresentation so it's easy to discover what attributes can be set
>
That's trivial to add using reflection. But how would the UI look? Ideally
we'd have tab completion for this at some point.
Something like this?
$ kcreg list-attrs
clientId String
redirectUris List<String>
baseUrl String
enabled Boolean
...
$ kcreg list-attrs -e oidc
redirect_uris List<String>
grant_types List<String>
However if we want to be more specific, with some additional help on the
meaning, and possible values, then we would need to annotate Representation
classes with the necessary info, or simply have a help-style static text.
> * What about setting/changing complex attributes, how does that look like?
> Can we add/remove to an array? Add/remove elements to a complex object?
> Something like JSON patch could be nice
> https://tools.ietf.org/html/rfc6902
>
I haven't gone so far with this iteration. That's a TODO.
>
> On 22 July 2016 at 09:26, Stian Thorgersen <sthorger(a)redhat.com> wrote:
>
>> It should be fairly easy to add support for OTP as well as the direct
>> grant supports that. The user would have to specify to use OTP though.
>>
>> On 21 July 2016 at 19:15, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>>
>>> Nice work Marko! I had two (not big deal) questions. First, when you
>>> specify the --cache parameters as you did for SAML, could the cache file
>>> be omitted?
>>>
>>> For example: kcreg --cache -r saml-realm ...
>>>
>>> I was thinking that once you specified the realm name, the API will just
>>> look for ~/.keycloak/saml-realm.cache. It's just an idea.
>>>
>>> Second question, is more like something to think if worth to take
>>> into consideration. Most of the examples that I saw, make use of
>>> username/password. But if the admin enables two factor authentication,
>>> she might be unable to use our client-reg CLI, or enforce weaken
>>> security only
>>> to make use of the CLI.
>>>
>>> Is OTP support planned for further iterations?
>>>
>>>
>>> On 2016-07-21, Marko Strukelj wrote:
>>> > And if anyone wants to get their feet wet already:
>>> >
>>> >
>>>
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
>>> >
>>> >
>>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen
<sthorger(a)redhat.com
>>> >
>>> > wrote:
>>> >
>>> > > Great work Marko!
>>> > >
>>> > > As we didn't have time to go through feedback let's use
this thread
>>> for
>>> > > it. Add your questions and comments here please.
>>> > >
>>> > > _______________________________________________
>>> > > keycloak-dev mailing list
>>> > > keycloak-dev(a)lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > >
>>>
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> --
>>>
>>> abstractj
>>> PGP: 0x84DC9914
>>>
>>
>>
>
--
abstractj
PGP: 0x84DC9914
12:18 p.m.
That would work: -n, --no-format
Much better than -n, --no-pretty :)
On Fri, Jul 22, 2016 at 12:12 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
On 2016-07-22, Marko Strukelj wrote:
> On Fri, Jul 22, 2016 at 9:33 AM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
> > A few questions from me:
> >
> > * Is it possible to view the returned JSON when creating and updating a
> > client? This contains values filled in by the server, including the
> > registration access token.
> >
> Not ATM. I can add an option e.g. -o, --output Display the new state
> of client configuration.
>
>
> > * Should we not enable pretty print by default?
> >
> I suppose that would be more user friendly. Just don't know how to name
the
> switch -p, --pretty is so obvious ...
Some command line interfaces use --format.
>
>
> > * --cache isn't the most intuitive name, I don't have a better
suggestion
> > though
> >
> OpenShift client uses the term configuration rather than cache, and uses
> --config accordingly. We could do the same, and even add 'kcreg config'
> command to inspect and edit the config file if we deem that necessary.
>
> * Docs should be moved to Gitbook "Securing Clients and Applications
guide"
> >
> The only doc currently is the README file, so I guess that's the one you
> mean. I'd wait a bit with adding it to docbook. The later I make a copy
in
> Gitbook the less double work will there be editing the changes.
>
>
> > * When creating clients and later updating them I assume it uses the
> > registration access token from the cache?
> >
> Yes. If it can't find one it uses bearer token from login.
>
>
> > * A nice addition would be the ability to list attributes from
> > ClientRepresentation so it's easy to discover what attributes can be
set
> >
> That's trivial to add using reflection. But how would the UI look?
Ideally
> we'd have tab completion for this at some point.
>
> Something like this?
>
> $ kcreg list-attrs
> clientId String
> redirectUris List<String>
> baseUrl String
> enabled Boolean
> ...
>
> $ kcreg list-attrs -e oidc
> redirect_uris List<String>
> grant_types List<String>
>
>
> However if we want to be more specific, with some additional help on the
> meaning, and possible values, then we would need to annotate
Representation
> classes with the necessary info, or simply have a help-style static text.
>
>
>
> > * What about setting/changing complex attributes, how does that look
like?
> > Can we add/remove to an array? Add/remove elements to a complex object?
> > Something like JSON patch could be nice
> > https://tools.ietf.org/html/rfc6902
> >
> I haven't gone so far with this iteration. That's a TODO.
>
>
> >
> > On 22 July 2016 at 09:26, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> >
> >> It should be fairly easy to add support for OTP as well as the direct
> >> grant supports that. The user would have to specify to use OTP though.
> >>
> >> On 21 July 2016 at 19:15, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
> >>
> >>> Nice work Marko! I had two (not big deal) questions. First, when you
> >>> specify the --cache parameters as you did for SAML, could the cache
file
> >>> be omitted?
> >>>
> >>> For example: kcreg --cache -r saml-realm ...
> >>>
> >>> I was thinking that once you specified the realm name, the API will
just
> >>> look for ~/.keycloak/saml-realm.cache. It's just an idea.
> >>>
> >>> Second question, is more like something to think if worth to take
> >>> into consideration. Most of the examples that I saw, make use of
> >>> username/password. But if the admin enables two factor
authentication,
> >>> she might be unable to use our client-reg CLI, or enforce weaken
> >>> security only
> >>> to make use of the CLI.
> >>>
> >>> Is OTP support planned for further iterations?
> >>>
> >>>
> >>> On 2016-07-21, Marko Strukelj wrote:
> >>> > And if anyone wants to get their feet wet already:
> >>> >
> >>> >
> >>>
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
> >>> >
> >>> >
> >>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <
sthorger(a)redhat.com
> >>> >
> >>> > wrote:
> >>> >
> >>> > > Great work Marko!
> >>> > >
> >>> > > As we didn't have time to go through feedback let's
use this
thread
> >>> for
> >>> > > it. Add your questions and comments here please.
> >>> > >
> >>> > > _______________________________________________
> >>> > > keycloak-dev mailing list
> >>> > > keycloak-dev(a)lists.jboss.org
> >>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>> > >
> >>>
> >>> > _______________________________________________
> >>> > keycloak-dev mailing list
> >>> > keycloak-dev(a)lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>>
> >>> --
> >>>
> >>> abstractj
> >>> PGP: 0x84DC9914
> >>>
> >>
> >>
> >
--
abstractj
PGP: 0x84DC9914
12:20 p.m.
On 22 July 2016 at 12:02, Marko Strukelj <mstrukel(a)redhat.com> wrote:
On Fri, Jul 22, 2016 at 9:33 AM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> A few questions from me:
>
> * Is it possible to view the returned JSON when creating and updating a
> client? This contains values filled in by the server, including the
> registration access token.
>
Not ATM. I can add an option e.g. -o, --output Display the new state
of client configuration.
Please do
> * Should we not enable pretty print by default?
>
I suppose that would be more user friendly. Just don't know how to name
the switch -p, --pretty is so obvious ...
-u --ugly ;)
or a more serious suggestion
-c --compressed
> * --cache isn't the most intuitive name, I don't have a better suggestion
> though
>
OpenShift client uses the term configuration rather than cache, and uses
--config accordingly. We could do the same, and even add 'kcreg config'
command to inspect and edit the config file if we deem that necessary.
+1 --config is better - config would be nice as well
* Docs should be moved to Gitbook "Securing Clients and Applications guide"
>
The only doc currently is the README file, so I guess that's the one you
mean. I'd wait a bit with adding it to docbook. The later I make a copy in
Gitbook the less double work will there be editing the changes.
Sure, just remember to do it before moving on to Admin CLI
> * When creating clients and later updating them I assume it uses the
> registration access token from the cache?
>
Yes. If it can't find one it uses bearer token from login.
> * A nice addition would be the ability to list attributes from
> ClientRepresentation so it's easy to discover what attributes can be set
>
That's trivial to add using reflection. But how would the UI look? Ideally
we'd have tab completion for this at some point.
Something like this?
$ kcreg list-attrs
clientId String
redirectUris List<String>
baseUrl String
enabled Boolean
...
$ kcreg list-attrs -e oidc
redirect_uris List<String>
grant_types List<String>
That's fine and you only need it for our representation. I wouldn't use
Java names for types though, rather use JSON names
However if we want to be more specific, with some additional help on the
meaning, and possible values, then we would need to annotate Representation
classes with the necessary info, or simply have a help-style static text.
> * What about setting/changing complex attributes, how does that look
> like? Can we add/remove to an array? Add/remove elements to a complex
> object? Something like JSON patch could be nice
> https://tools.ietf.org/html/rfc6902
>
I haven't gone so far with this iteration. That's a TODO.
Ok, would nice to visit before we start on Admin CLI as it would be
incredibly useful there.
>
> On 22 July 2016 at 09:26, Stian Thorgersen <sthorger(a)redhat.com> wrote:
>
>> It should be fairly easy to add support for OTP as well as the direct
>> grant supports that. The user would have to specify to use OTP though.
>>
>> On 21 July 2016 at 19:15, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>>
>>> Nice work Marko! I had two (not big deal) questions. First, when you
>>> specify the --cache parameters as you did for SAML, could the cache
>>> file be omitted?
>>>
>>> For example: kcreg --cache -r saml-realm ...
>>>
>>> I was thinking that once you specified the realm name, the API will just
>>> look for ~/.keycloak/saml-realm.cache. It's just an idea.
>>>
>>> Second question, is more like something to think if worth to take
>>> into consideration. Most of the examples that I saw, make use of
>>> username/password. But if the admin enables two factor authentication,
>>> she might be unable to use our client-reg CLI, or enforce weaken
>>> security only
>>> to make use of the CLI.
>>>
>>> Is OTP support planned for further iterations?
>>>
>>>
>>> On 2016-07-21, Marko Strukelj wrote:
>>> > And if anyone wants to get their feet wet already:
>>> >
>>> >
>>>
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
>>> >
>>> >
>>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <
>>> sthorger(a)redhat.com>
>>> > wrote:
>>> >
>>> > > Great work Marko!
>>> > >
>>> > > As we didn't have time to go through feedback let's use
this thread
>>> for
>>> > > it. Add your questions and comments here please.
>>> > >
>>> > > _______________________________________________
>>> > > keycloak-dev mailing list
>>> > > keycloak-dev(a)lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > >
>>>
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> --
>>>
>>> abstractj
>>> PGP: 0x84DC9914
>>>
>>
>>
>
12:22 p.m.
Ok, so let's do both then - included with server + separate download. One
download for both cli reg and admin cli is probably sufficient right?
On 22 July 2016 at 12:11, Marko Strukelj <mstrukel(a)redhat.com> wrote:
I don't have kcreg.bat yet ... contributions welcome :)
Making it part of keycloak server distro makes sense. OTOH I believe we
have some developers that just deal with HTML5 web apps who don't have
Keycloak Server installed locally. If that was the only way to get kcreg
they would have to download the whole server just to get the tool. For them
it makes sense to also have a separate CLI Tools download.
On Fri, Jul 22, 2016 at 9:40 AM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> One more:
>
> * How should we distribute it? I propose we just add kcreg.sh/kcreg.bat
> + the JAR to the bin directory of the server
>
> On 22 July 2016 at 09:33, Stian Thorgersen <sthorger(a)redhat.com> wrote:
>
>> A few questions from me:
>>
>> * Is it possible to view the returned JSON when creating and updating a
>> client? This contains values filled in by the server, including the
>> registration access token.
>> * Should we not enable pretty print by default?
>> * --cache isn't the most intuitive name, I don't have a better
>> suggestion though
>> * Docs should be moved to Gitbook "Securing Clients and Applications
>> guide"
>> * When creating clients and later updating them I assume it uses the
>> registration access token from the cache?
>> * A nice addition would be the ability to list attributes from
>> ClientRepresentation so it's easy to discover what attributes can be set
>> * What about setting/changing complex attributes, how does that look
>> like? Can we add/remove to an array? Add/remove elements to a complex
>> object? Something like JSON patch could be nice
>> https://tools.ietf.org/html/rfc6902
>>
>> On 22 July 2016 at 09:26, Stian Thorgersen <sthorger(a)redhat.com> wrote:
>>
>>> It should be fairly easy to add support for OTP as well as the direct
>>> grant supports that. The user would have to specify to use OTP though.
>>>
>>> On 21 July 2016 at 19:15, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>>>
>>>> Nice work Marko! I had two (not big deal) questions. First, when you
>>>> specify the --cache parameters as you did for SAML, could the cache
>>>> file be omitted?
>>>>
>>>> For example: kcreg --cache -r saml-realm ...
>>>>
>>>> I was thinking that once you specified the realm name, the API will
>>>> just
>>>> look for ~/.keycloak/saml-realm.cache. It's just an idea.
>>>>
>>>> Second question, is more like something to think if worth to take
>>>> into consideration. Most of the examples that I saw, make use of
>>>> username/password. But if the admin enables two factor authentication,
>>>> she might be unable to use our client-reg CLI, or enforce weaken
>>>> security only
>>>> to make use of the CLI.
>>>>
>>>> Is OTP support planned for further iterations?
>>>>
>>>>
>>>> On 2016-07-21, Marko Strukelj wrote:
>>>> > And if anyone wants to get their feet wet already:
>>>> >
>>>> >
>>>>
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
>>>> >
>>>> >
>>>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <
>>>> sthorger(a)redhat.com>
>>>> > wrote:
>>>> >
>>>> > > Great work Marko!
>>>> > >
>>>> > > As we didn't have time to go through feedback let's use
this
>>>> thread for
>>>> > > it. Add your questions and comments here please.
>>>> > >
>>>> > > _______________________________________________
>>>> > > keycloak-dev mailing list
>>>> > > keycloak-dev(a)lists.jboss.org
>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> > >
>>>>
>>>> > _______________________________________________
>>>> > keycloak-dev mailing list
>>>> > keycloak-dev(a)lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>> --
>>>>
>>>> abstractj
>>>> PGP: 0x84DC9914
>>>>
>>>
>>>
>>
>
12:34 p.m.
+1
On Fri, Jul 22, 2016 at 12:22 PM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
Ok, so let's do both then - included with server + separate
download. One
download for both cli reg and admin cli is probably sufficient right?
On 22 July 2016 at 12:11, Marko Strukelj <mstrukel(a)redhat.com> wrote:
> I don't have kcreg.bat yet ... contributions welcome :)
>
> Making it part of keycloak server distro makes sense. OTOH I believe we
> have some developers that just deal with HTML5 web apps who don't have
> Keycloak Server installed locally. If that was the only way to get kcreg
> they would have to download the whole server just to get the tool. For them
> it makes sense to also have a separate CLI Tools download.
>
>
> On Fri, Jul 22, 2016 at 9:40 AM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
>> One more:
>>
>> * How should we distribute it? I propose we just add kcreg.sh/kcreg.bat
>> + the JAR to the bin directory of the server
>>
>> On 22 July 2016 at 09:33, Stian Thorgersen <sthorger(a)redhat.com> wrote:
>>
>>> A few questions from me:
>>>
>>> * Is it possible to view the returned JSON when creating and updating a
>>> client? This contains values filled in by the server, including the
>>> registration access token.
>>> * Should we not enable pretty print by default?
>>> * --cache isn't the most intuitive name, I don't have a better
>>> suggestion though
>>> * Docs should be moved to Gitbook "Securing Clients and Applications
>>> guide"
>>> * When creating clients and later updating them I assume it uses the
>>> registration access token from the cache?
>>> * A nice addition would be the ability to list attributes from
>>> ClientRepresentation so it's easy to discover what attributes can be set
>>> * What about setting/changing complex attributes, how does that look
>>> like? Can we add/remove to an array? Add/remove elements to a complex
>>> object? Something like JSON patch could be nice
>>> https://tools.ietf.org/html/rfc6902
>>>
>>> On 22 July 2016 at 09:26, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
>>>
>>>> It should be fairly easy to add support for OTP as well as the direct
>>>> grant supports that. The user would have to specify to use OTP though.
>>>>
>>>> On 21 July 2016 at 19:15, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
>>>>
>>>>> Nice work Marko! I had two (not big deal) questions. First, when you
>>>>> specify the --cache parameters as you did for SAML, could the cache
>>>>> file be omitted?
>>>>>
>>>>> For example: kcreg --cache -r saml-realm ...
>>>>>
>>>>> I was thinking that once you specified the realm name, the API will
>>>>> just
>>>>> look for ~/.keycloak/saml-realm.cache. It's just an idea.
>>>>>
>>>>> Second question, is more like something to think if worth to take
>>>>> into consideration. Most of the examples that I saw, make use of
>>>>> username/password. But if the admin enables two factor
authentication,
>>>>> she might be unable to use our client-reg CLI, or enforce weaken
>>>>> security only
>>>>> to make use of the CLI.
>>>>>
>>>>> Is OTP support planned for further iterations?
>>>>>
>>>>>
>>>>> On 2016-07-21, Marko Strukelj wrote:
>>>>> > And if anyone wants to get their feet wet already:
>>>>> >
>>>>> >
>>>>>
https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist...
>>>>> >
>>>>> >
>>>>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <
>>>>> sthorger(a)redhat.com>
>>>>> > wrote:
>>>>> >
>>>>> > > Great work Marko!
>>>>> > >
>>>>> > > As we didn't have time to go through feedback let's
use this
>>>>> thread for
>>>>> > > it. Add your questions and comments here please.
>>>>> > >
>>>>> > > _______________________________________________
>>>>> > > keycloak-dev mailing list
>>>>> > > keycloak-dev(a)lists.jboss.org
>>>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> > >
>>>>>
>>>>> > _______________________________________________
>>>>> > keycloak-dev mailing list
>>>>> > keycloak-dev(a)lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> abstractj
>>>>> PGP: 0x84DC9914
>>>>>
>>>>
>>>>
>>>
>>
>
2828
days inactive
2829
days old
16 comments
4 participants
participants (4)
-
Bill Burke -
Bruno Oliveira -
Marko Strukelj -
Stian Thorgersen