[keycloak-dev] Initial Client Storage SPI

[Stian Thorgersen]

On 1 February 2018 at 08:43, Francis Pouatcha <fpo at adorsys.de> wrote:

> PSD2 does not define any client registration process. But after reading the
> 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
> registration.
>

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
> provider.
>

Clients in Keycloak already have attributes that can store any key-value
pair.


>
> 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
> token.
>

We just miss a client attribute mapper here right?


>
> On Tue, Jan 30, 2018 at 12:49 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
> > 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 at 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 at 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 at 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 at 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 at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>> >
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>