5:49 a.m.
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