[keycloak-dev] Keycloak Operator - Use of extensions

Bruno Oliveira bruno at abstractj.org
Thu Sep 19 11:20:08 EDT 2019


The following Jira was created with all the details:
https://issues.jboss.org/browse/INTLY-3606

On Thu, Sep 19, 2019 at 11:40 AM Bruno Oliveira <bruno at abstractj.org> wrote:
>
> Yes, that's correct. I will file a Jira with the proper description
> about this, if you think it makes sense I can also add to the Operator
> design proposal.
>
> On Wed, Sep 18, 2019 at 1:45 PM Stian Thorgersen <sthorger at redhat.com> wrote:
> >
> > List of extensions by URL makes sense to me. Extension can be a jar or an ear though.
> >
> > I assume the mention of GitHub releases page is just an example and that the URL will be any valid Https URL?
> >
> > On Wed, 18 Sep 2019, 15:53 Bruno Oliveira, <bruno at abstractj.org> wrote:
> >>
> >> Good afternoon,
> >>
> >> Today we had a meeting to discuss how to handle Keycloak extensions
> >> inside the Operator. And let me try to summarize what we discussed.
> >>
> >> At the moment we bundle all the desired extensions inside a Docker
> >> image[1]. That works, but it comes at a price, because we need to
> >> maintain the builds for these extensions, or at least make sure they
> >> work.
> >>
> >> During our meeting today we concluded that the desired
> >> state would be to fetch the Jar files from the GitHub releases page. For
> >> example: https://github.com/Doccrazy/keycloak-protocol-cas/releases. And
> >> also let people provide the URL for their custom extension.
> >>
> >> To accomplish this, all the extensions contributions must
> >> distribute a Jar file. Otherwise, they won't be able to use their
> >> extension with the Keycloak Operator.
> >>
> >> Does it make sense?
> >>
> >> [1] - https://github.com/integr8ly/sso_plugins_init
> >>
> >> --
> >>
> >> abstractj
>
>
>
> --
> - abstractj



-- 
- abstractj


More information about the keycloak-dev mailing list