1:34 a.m.
At times there are extensions and examples that we don't want to include in
the main repository. This could be for several reasons, including:
* We don't have the resources to maintain and support it
* We don't believe it's generic enough
* Examples that are to complex
However, these can still be useful for some people. So I'm thinking about
how we can provide community maintained extensions and examples.
A very simple idea would be to add a page on our website that links to the
relevant repository and documentation. To contribute you would setup your
own Github repository, documentation and also a download if you want. Then
you'd send a PR to the website to add your extension or example.
Thoughts?
4:31 p.m.
Hi,
Though I'm not a Keycloak dev, I hope the community member's 2¢ will be
useful nevertheless.
To me that sounds like a great initiative, I myself will be happy to
contribute BeerCloak, an example of how to build complete admin realm
resources while the corresponding SPI is not (yet) implemented.
Off the top of my head, I think we'll need some sort of separation
between examples and extensions because of their (generally) different
use cases. For examples, it's "check it out and hack on it"; for
extensions, "install & use it" (preferably skipping the "checkout"
and
"build" phases).
Ideally, there should be something like Atlassian Marketplace, a
registry/repository of extensions (including commercial ones) with one-
click installation. I clearly understand that wouldn't be a top
priority - just sharing my vision.
BTW, speaking about commercial extensions, can we hope on our products
being mentioned somewhere too? I think such a disclosure can make
Keycloak/RHSSO look more valuable in the eyes of potential users and
customers. Our flagship product provides Keycloak support for hardware
OTP tokens with full lifecycle, like bulk import, enrollment,
revocation, audit etc.
The other stuff being developed is:
* HRM integration (sync Keycloak with employee database from HRMs);
* advanced monitoring (collect different Keycloak-specific metrics and
expose them as DMR/JMX);
* OpenID 2.0 (legacy) support;
* identity brokering for VK social network (this and the previous one
most likely will be opensourced).
There are even thoughts on integrating PKI functionality into Keycloak,
which becomes highly topical with the introduction of x509 client cert
auth (thanks Peter!)
Cheers,
Dmitry Telegin
CTO, CargoSoft LLC
http://cargosoft.ru/en/rm/about/
В Wed, 28/06/2017 в 08:34 +0200, Stian Thorgersen пишет:
At times there are extensions and examples that we don't want to
include in
the main repository. This could be for several reasons, including:
* We don't have the resources to maintain and support it
* We don't believe it's generic enough
* Examples that are to complex
However, these can still be useful for some people. So I'm thinking
about
how we can provide community maintained extensions and examples.
A very simple idea would be to add a page on our website that links
to the
relevant repository and documentation. To contribute you would setup
your
own Github repository, documentation and also a download if you want.
Then
you'd send a PR to the website to add your extension or example.
Thoughts?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:40 a.m.
On Wed, Jun 28, 2017 at 11:31 PM, Dmitry Telegin <mitya(a)cargosoft.ru> wrote:
Hi,
Though I'm not a Keycloak dev, I hope the community member's 2¢ will be
useful nevertheless.
To me that sounds like a great initiative, I myself will be happy to
contribute BeerCloak, an example of how to build complete admin realm
resources while the corresponding SPI is not (yet) implemented.
Off the top of my head, I think we'll need some sort of separation
between examples and extensions because of their (generally) different
use cases. For examples, it's "check it out and hack on it"; for
extensions, "install & use it" (preferably skipping the
"checkout" and
"build" phases).
Ideally, there should be something like Atlassian Marketplace, a
registry/repository of extensions (including commercial ones) with one-
click installation. I clearly understand that wouldn't be a top
priority - just sharing my vision.
Putting the commercial extensions aside, I like the concept of a
"Marketplace", in fact I like what Forge does for its addons :
https://forge.jboss.org/addons . Each Extension should start with the same
"blueprint" and yes it would be nice to have a :
- A registry.
- A standard way of installing them.
BTW, speaking about commercial extensions, can we hope on our products
being mentioned somewhere too? I think such a disclosure can make
Keycloak/RHSSO look more valuable in the eyes of potential users and
customers. Our flagship product provides Keycloak support for hardware
OTP tokens with full lifecycle, like bulk import, enrollment,
revocation, audit etc.
The other stuff being developed is:
* HRM integration (sync Keycloak with employee database from HRMs);
* advanced monitoring (collect different Keycloak-specific metrics and
expose them as DMR/JMX);
* OpenID 2.0 (legacy) support;
* identity brokering for VK social network (this and the previous one
most likely will be opensourced).
There are even thoughts on integrating PKI functionality into Keycloak,
which becomes highly topical with the introduction of x509 client cert
auth (thanks Peter!)
Cheers,
Dmitry Telegin
CTO, CargoSoft LLC
http://cargosoft.ru/en/rm/about/
В Wed, 28/06/2017 в 08:34 +0200, Stian Thorgersen пишет:
> At times there are extensions and examples that we don't want to
> include in
> the main repository. This could be for several reasons, including:
>
> * We don't have the resources to maintain and support it
> * We don't believe it's generic enough
> * Examples that are to complex
>
> However, these can still be useful for some people. So I'm thinking
> about
> how we can provide community maintained extensions and examples.
>
> A very simple idea would be to add a page on our website that links
> to the
> relevant repository and documentation. To contribute you would setup
> your
> own Github repository, documentation and also a download if you want.
> Then
> you'd send a PR to the website to add your extension or example.
>
> Thoughts?
> _______________________________________________
> 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
2:06 a.m.
Extensions can already be easy to install on Keycloak. Just download and
drop into standalone/deployments. It's just a matter of having a page like
that where folks can discover things.
Then there's also community maintained adapters, blogs, examples, etc. we
could link to as well.
On 30 June 2017 at 08:40, Sebastien Blanc <sblanc(a)redhat.com> wrote:
On Wed, Jun 28, 2017 at 11:31 PM, Dmitry Telegin <mitya(a)cargosoft.ru>
wrote:
> Hi,
>
> Though I'm not a Keycloak dev, I hope the community member's 2¢ will be
> useful nevertheless.
>
> To me that sounds like a great initiative, I myself will be happy to
> contribute BeerCloak, an example of how to build complete admin realm
> resources while the corresponding SPI is not (yet) implemented.
>
> Off the top of my head, I think we'll need some sort of separation
> between examples and extensions because of their (generally) different
> use cases. For examples, it's "check it out and hack on it"; for
> extensions, "install & use it" (preferably skipping the
"checkout" and
> "build" phases).
>
> Ideally, there should be something like Atlassian Marketplace, a
> registry/repository of extensions (including commercial ones) with one-
> click installation. I clearly understand that wouldn't be a top
> priority - just sharing my vision.
>
Putting the commercial extensions aside, I like the concept of a
"Marketplace", in fact I like what Forge does for its addons :
https://forge.jboss.org/addons . Each Extension should start with the
same "blueprint" and yes it would be nice to have a :
- A registry.
- A standard way of installing them.
>
> BTW, speaking about commercial extensions, can we hope on our products
> being mentioned somewhere too? I think such a disclosure can make
> Keycloak/RHSSO look more valuable in the eyes of potential users and
> customers. Our flagship product provides Keycloak support for hardware
> OTP tokens with full lifecycle, like bulk import, enrollment,
> revocation, audit etc.
>
> The other stuff being developed is:
> * HRM integration (sync Keycloak with employee database from HRMs);
> * advanced monitoring (collect different Keycloak-specific metrics and
> expose them as DMR/JMX);
> * OpenID 2.0 (legacy) support;
> * identity brokering for VK social network (this and the previous one
> most likely will be opensourced).
>
> There are even thoughts on integrating PKI functionality into Keycloak,
> which becomes highly topical with the introduction of x509 client cert
> auth (thanks Peter!)
>
> Cheers,
> Dmitry Telegin
> CTO, CargoSoft LLC
> http://cargosoft.ru/en/rm/about/
>
> В Wed, 28/06/2017 в 08:34 +0200, Stian Thorgersen пишет:
> > At times there are extensions and examples that we don't want to
> > include in
> > the main repository. This could be for several reasons, including:
> >
> > * We don't have the resources to maintain and support it
> > * We don't believe it's generic enough
> > * Examples that are to complex
> >
> > However, these can still be useful for some people. So I'm thinking
> > about
> > how we can provide community maintained extensions and examples.
> >
> > A very simple idea would be to add a page on our website that links
> > to the
> > relevant repository and documentation. To contribute you would setup
> > your
> > own Github repository, documentation and also a download if you want.
> > Then
> > you'd send a PR to the website to add your extension or example.
> >
> > Thoughts?
> > _______________________________________________
> > 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
>
1:15 a.m.
This is a worthwhile discussion, and one I've been thinking about starting.
I'm working with Keycloak on two different projects at the moment. While
doing so, I've written mechanisms for:
1. A REST based storage provider
2. A client-certificate authentication provider, where SSL is terminated at
a reverse proxy and the certificate is provided in a user header. This
differs from the X/509 Validate Username Provider in that it supports an
'optional' mode whereby a user can still login without having provided a
certificate, but is not MFA'ed, and is prompted using a 'required action'.
3. A backup-codes mechanism (integrated with a lot of LDAP stuff that's
organisation specific, but my design have been well received by end users)
4. extensions to the profile application for (2) and (3)
Now, the problem is, in addition to my usual work, I don't have the time to
get involved in the Keycloak project and re-engineer these components so
that they are suitable for inclusion in the main project. However, feedback
from within my organisation and from our customers has led me to conclude
that my ideas are sound.
With a little work from an experienced contributor, I suspect that part of
these providers could be included in the main project. It would be great to
have some place to put these up where they could be given some exposure
and, potentially, scheduled for further work and inclusion by those of you
close to the project.
Regards,
LM
On Wed, Jun 28, 2017 at 4:34 PM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
At times there are extensions and examples that we don't want to
include in
the main repository. This could be for several reasons, including:
* We don't have the resources to maintain and support it
* We don't believe it's generic enough
* Examples that are to complex
However, these can still be useful for some people. So I'm thinking about
how we can provide community maintained extensions and examples.
A very simple idea would be to add a page on our website that links to the
relevant repository and documentation. To contribute you would setup your
own Github repository, documentation and also a download if you want. Then
you'd send a PR to the website to add your extension or example.
Thoughts?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:44 a.m.
+1 that would be great
On 2017-06-28, Stian Thorgersen wrote:
At times there are extensions and examples that we don't want to
include in
the main repository. This could be for several reasons, including:
* We don't have the resources to maintain and support it
* We don't believe it's generic enough
* Examples that are to complex
However, these can still be useful for some people. So I'm thinking about
how we can provide community maintained extensions and examples.
A very simple idea would be to add a page on our website that links to the
relevant repository and documentation. To contribute you would setup your
own Github repository, documentation and also a download if you want. Then
you'd send a PR to the website to add your extension or example.
Thoughts?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
4:45 p.m.
-1000. But you've already done this with the quickstarts against my
wishes. You know why, but I'll rehash anyways:
* Examples will get out of sync
* Examples will end up not working
* Examples need to be tied to a specific release as APIs and SPIs change
* Users won't know they exist
* Examples won't pick up IDE refactorings of our SPIs and APIs because
people will forget to include them.
There's really no good reason to have quickstarts and examples in a
separate repo and a separate build other than "Wildlfy does it."
On 6/29/17 5:44 AM, Bruno Oliveira wrote:
+1 that would be great
On 2017-06-28, Stian Thorgersen wrote:
> At times there are extensions and examples that we don't want to include in
> the main repository. This could be for several reasons, including:
>
> * We don't have the resources to maintain and support it
> * We don't believe it's generic enough
> * Examples that are to complex
>
> However, these can still be useful for some people. So I'm thinking about
> how we can provide community maintained extensions and examples.
>
> A very simple idea would be to add a page on our website that links to the
> relevant repository and documentation. To contribute you would setup your
> own Github repository, documentation and also a download if you want. Then
> you'd send a PR to the website to add your extension or example.
>
> Thoughts?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:50 p.m.
One more thing:
Broken examples are akin to documentation that is incorrect. It pisses
people off and makes Keycloak look bad. Moving examples to a different
repo that is only maintained by community won't get maintained. That's
a fact.
On 6/29/17 5:45 PM, Bill Burke wrote:
-1000. But you've already done this with the quickstarts against
my
wishes. You know why, but I'll rehash anyways:
* Examples will get out of sync
* Examples will end up not working
* Examples need to be tied to a specific release as APIs and SPIs change
* Users won't know they exist
* Examples won't pick up IDE refactorings of our SPIs and APIs because
people will forget to include them.
There's really no good reason to have quickstarts and examples in a
separate repo and a separate build other than "Wildlfy does it."
On 6/29/17 5:44 AM, Bruno Oliveira wrote:
> +1 that would be great
>
> On 2017-06-28, Stian Thorgersen wrote:
>> At times there are extensions and examples that we don't want to
>> include in
>> the main repository. This could be for several reasons, including:
>>
>> * We don't have the resources to maintain and support it
>> * We don't believe it's generic enough
>> * Examples that are to complex
>>
>> However, these can still be useful for some people. So I'm thinking
>> about
>> how we can provide community maintained extensions and examples.
>>
>> A very simple idea would be to add a page on our website that links
>> to the
>> relevant repository and documentation. To contribute you would setup
>> your
>> own Github repository, documentation and also a download if you
>> want. Then
>> you'd send a PR to the website to add your extension or example.
>>
>> Thoughts?
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:55 p.m.
Broken examples have nothing to do with where they are. It's down to lack
of automated tests. The examples in the same repo have been broken
countless amount of times in the past and we used to manually test it. The
new quickstarts have full automated testing and as part of a release we are
setting up CI jobs that check the quickstarts against the latests Keycloak.
Examples should not be tied to a specific API we need to be backwards
compatible. In fact moving to a separate repo makes it more obvious when we
break API compatibility. That might be awkward for us, but it's a good
thing for our users.
Whether or not users find them or not has also nothing to do with them
being in the same repo. There's a download for the examples of the website
and it doesn't matter what repository that comes from.
We also where required to have quickstarts in a separate repo for product.
So we would have had to have separate examples for Keycloak and RH-SSO if
they where going to be in the same repo.
That's a completely different thing to what this discussion was about
though. This discussion was purely about extensions and examples that we
are not able to maintain so we can't accept them to the main repo.
On 29 June 2017 at 23:50, Bill Burke <bburke(a)redhat.com> wrote:
One more thing:
Broken examples are akin to documentation that is incorrect. It pisses
people off and makes Keycloak look bad. Moving examples to a different
repo that is only maintained by community won't get maintained. That's
a fact.
On 6/29/17 5:45 PM, Bill Burke wrote:
> -1000. But you've already done this with the quickstarts against my
> wishes. You know why, but I'll rehash anyways:
>
> * Examples will get out of sync
>
> * Examples will end up not working
>
> * Examples need to be tied to a specific release as APIs and SPIs change
>
> * Users won't know they exist
>
> * Examples won't pick up IDE refactorings of our SPIs and APIs because
> people will forget to include them.
>
> There's really no good reason to have quickstarts and examples in a
> separate repo and a separate build other than "Wildlfy does it."
>
>
> On 6/29/17 5:44 AM, Bruno Oliveira wrote:
>> +1 that would be great
>>
>> On 2017-06-28, Stian Thorgersen wrote:
>>> At times there are extensions and examples that we don't want to
>>> include in
>>> the main repository. This could be for several reasons, including:
>>>
>>> * We don't have the resources to maintain and support it
>>> * We don't believe it's generic enough
>>> * Examples that are to complex
>>>
>>> However, these can still be useful for some people. So I'm thinking
>>> about
>>> how we can provide community maintained extensions and examples.
>>>
>>> A very simple idea would be to add a page on our website that links
>>> to the
>>> relevant repository and documentation. To contribute you would setup
>>> your
>>> own Github repository, documentation and also a download if you
>>> want. Then
>>> you'd send a PR to the website to add your extension or example.
>>>
>>> Thoughts?
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> --
>>
>> abstractj
>> _______________________________________________
>> 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
2736
days inactive
2738
days old
8 comments
6 participants
participants (6)
-
Bill Burke -
Bruno Oliveira -
Dmitry Telegin -
Liam Maruff -
Sebastien Blanc -
Stian Thorgersen