On 1 February 2018 at 08:43, Francis Pouatcha <fpo(a)adorsys.de> wrote:
PSD2 does not define any client registration process. But after
last release of the RTS (Regulatory Technical Standard), we have the
following plan for a reference implementation:
1- Certificate based Dynamic Client Registration
The EBA (European Banking Association) requires each TPP (Thirs Party
Provider) to have a digital certificate issued by their country authority.
Based on the RTS (Regulatory Technical Standard) released so far, the flow
we are modelling plans some sort of Certificate Based Dynamic Client
Having certificate based authentication for dynamic client registration
seems like a sensible idea and I'd think we could accept a contribution
around that to allow you to use the dynamic client registration
capabilities already in Keycloak.
2- Activity and Fraud Reporting
PSD2 requires ASPSP (Account Servicing Payment Service Provider) to report
irregular activity on a regular basis. Many banks will extend existing
fraud reporting systems to fulfill this requirement. Most of these system
will store more information on the client than required by the identity
Clients in Keycloak already have attributes that can store any key-value
3- Managing the Client Life Cycle
For same reasons (like fraud management), managing the life cycle of TPPs
(Keycloack Clients, including temporary suspensions) shall be delegated to
the PSD2 specific backend.
Not sure what specifically this involves, but I could certainly see us
adding more smarts into Keycloak on managing life cycle of clients.
4- Adding TPP Specific Information to the Access Token
I hope the "Client Attributes Map" will help pass over some client specific
information to the OIDCProtocoMapper so we can add this to the access
We just miss a client attribute mapper here right?
On Tue, Jan 30, 2018 at 12:49 PM, Stian Thorgersen <sthorger(a)redhat.com>
> Could you elaborate on what PSD2 requires in addition to what Keycloak
> clients provide today? It may make sense to rather extend what the
> 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:
>> 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
>> On Mon, Jan 29, 2018 at 8:57 PM, Stian Thorgersen <sthorger(a)redhat.com>
>>> 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
>>> admin endpoints in the background when users change client config in
>>> 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>
>>> > > 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
>>> > > 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
>>> > > through REST API or realm import.
>>> > > * Basically it will be bare bones to support Openshift
>>> > >
>>> > > My plan is that Openshift support will be distributed as an
>>> > > to our base image and/or, it will be a template realm.json import
>>> > > that users can edit. I just don't want to expose an
>>> > >
>>> > > 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 mailing list