keycloak-documentation translation
by Hiroyuki Wada
Hello,
We have a plan to translate keycloak-documentation to Japanese for the
community at our company.
Because there is no place to manage the translation resources in
keycloak-documentation repository,
we are planning to put the resources into own repository and publish
the built documents to our corporate site.
Do you have any concerns?
Of course, we can contribute it if there are any plans to translate it
officially.
Best Regards,
--
Hiroyuki Wada,
Nomura Research Institute, Ltd.
5 years, 4 months
make sending a request object mandatory for certain clients
by Aron Bustya
Hi!
I have a use case where the server must accept authorization requests only
when they contain a signed request object (should be configurable per
client).
I have found a way to make the signing of the request object mandatory by
specifying a 'request.object.signature.alg' attribute on the client, but
this only applies if a request object exists in the first place.
I would like to propose a pull request: It defines a new client attribute
'request.object.required'. If this is set to 'true', the client must send a
request object when initiating an authorization request.
Current code can be checked here:
https://github.com/abustya/keycloak/commit/476912906a3ad0d290220a1f54abee...
What do you think?
Regards,
Áron Bustya
5 years, 6 months
Re: [keycloak-dev] Initial Client Storage SPI
by Stian Thorgersen
Could you elaborate on what PSD2 requires in addition to what Keycloak
clients provide today? It may make sense to rather extend what the clients
do today than to require using a custom SPI to store clients externally.
On 29 January 2018 at 22:19, Francis Pouatcha <fpo(a)adorsys.de> wrote:
> Bill,
>
> in Europe we are working on implementing the PSD2 regulation (Second
> European Payment Service Directive). Implementation involves a lot of
> interaction between API gateways and IdP and banking systems. Correct
> implementation of PSD2 requires more than what the keycloak client
> functionality exposes today. Therefore:
> - having a Client Storage SPI is a great idea.
> - making it read-only good for now
> - making it public SPI might though be very helpful
>
>
> /Francis
>
> On Mon, Jan 29, 2018 at 8:57 PM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
>> All makes sense to me. Would probably make sense to also add a JIRA to
>> include what would be needed to make it into a fully supported feature.
>>
>> FIY 3Scale was also interested in this as they currently have clients
>> created through their UI and then have to create/manage clients through
>> the
>> admin endpoints in the background when users change client config in their
>> UI.
>>
>> On 26 January 2018 at 20:02, Bill Burke <bburke(a)redhat.com> wrote:
>>
>> > A few more things:
>> >
>> > * Its implemented very similarly to UserStorage SPI.
>> > * It will not support client roles
>> > * It will not support node registration.
>> >
>> >
>> > On Fri, Jan 26, 2018 at 1:30 PM, Bill Burke <bburke(a)redhat.com> wrote:
>> > > As part of Openshift integration, I needed to implement a Client
>> > > Storage SPI. Here are my plans for it:
>> > >
>> > > * It is a private SPI
>> > > * Only read only support.
>> > > * Only lookup support to facilitate client login and grants and stuff.
>> > > Listing all clients will not show up in admin conosle
>> > > * There will be no admin console support. This means, no admin
>> > > console support for provider config. Providers can only be configured
>> > > through REST API or realm import.
>> > > * Basically it will be bare bones to support Openshift integration
>> only.
>> > >
>> > > My plan is that Openshift support will be distributed as an extension
>> > > to our base image and/or, it will be a template realm.json import file
>> > > that users can edit. I just don't want to expose an unfinished SPI.
>> > >
>> > > I'll probably have a PR for review early next week.
>> > >
>> > > --
>> > > Bill Burke
>> > > Red Hat
>> >
>> >
>> >
>> > --
>> > Bill Burke
>> > Red Hat
>> > _______________________________________________
>> > 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
>>
>
>
>
> --
>
> Francis Pouatcha
>
> Co-Founder and Technical Lead
>
> Email: fpo(a)adorsys.de
> Cell USA: +1 770 329 7026 <(770)%20329-7026>
> Cell Germany: +49 172 18 16 074 <+49%20172%201816074>
>
> adorsys GmbH & Co. KG
> Bartholomäusstrasse 26c
> <https://maps.google.com/?q=Bartholom%C3%A4usstrasse+26c+90489+N%C3%BCrnbe...>
> 90489 Nürnberg
> <https://maps.google.com/?q=Bartholom%C3%A4usstrasse+26c+90489+N%C3%BCrnbe...>
>
> Tel: 0911 360698-0
> Fax: 0911 360698-10
> E-Mail: info(a)adorsys.de
> Internet: www.adorsys.de
>
> Geschäftsführer: Francis Pouatcha, Stefan Hamm
> HR A 15855, AG Nürnberg
>
> Komplementär:
> adorsys Verwaltungs GmbH
> HR B 27343, AG Nürnberg
>
5 years, 8 months
Initial Client Storage SPI
by Bill Burke
As part of Openshift integration, I needed to implement a Client
Storage SPI. Here are my plans for it:
* It is a private SPI
* Only read only support.
* Only lookup support to facilitate client login and grants and stuff.
Listing all clients will not show up in admin conosle
* There will be no admin console support. This means, no admin
console support for provider config. Providers can only be configured
through REST API or realm import.
* Basically it will be bare bones to support Openshift integration only.
My plan is that Openshift support will be distributed as an extension
to our base image and/or, it will be a template realm.json import file
that users can edit. I just don't want to expose an unfinished SPI.
I'll probably have a PR for review early next week.
--
Bill Burke
Red Hat
5 years, 8 months
A lot of unneeded files in themes common
by Stian Thorgersen
I took a stab at cleaning up the node_modules (not for account2) by adding
a new profile to themes that can download packages from NPM. Then
copy/filter these to the directory used to build the server.
Benefits here:
* Removes unneeded files from dist
* Files included when running KeycloakServer is the same as in the dist
(filtered)
* All files/sources still checked in for RH-SSO
* Folks don't have to run this to build
You can try it out here:
https://github.com/stianst/keycloak/tree/KEYCLOAK-6378
cd themes
mvn -Pnpm-update clean install
Unless you change the package.json you shouldn't see any files to commit
afterwards. If you do there may be something with line encodings on Linux
vs Windows that we need to address (we should be able to tweak that by
adding a custom .gitattributes file in the node_modules dir).
Login, account and admin seems to work just fine with all these files
removed. There's probably more we can remove, but I think this is
sufficient at least for now.
5 years, 8 months
Release cadence
by Stian Thorgersen
Up until now we've released Keycloak roughly every 6 weeks. We're now
switching to 3 week sprints, which opens up the possibility to change how
frequently we release Keycloak.
We could keep it at 6 weeks (release every other sprint), do a release
every 3 weeks or release less frequently (9 weeks perhaps).
Thoughts?
5 years, 8 months
proof-of-possession
by Frederik Libert
Hi,
Are there any plans to support pop accesTokens where some kind of proof-of-possession is introduced to have a higher degree of security?As far as I know, there isn't yet a final standard (RFC) for this, only expired drafts, such as:- https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08- ht...
- https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
Would you consider implementing any of this or would you wait until a RFC is finally accepted as standard?
Kind regards,
Frederik
5 years, 8 months
