----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Sent: Monday, February 23, 2015 3:30:53 PM
Subject: Re: [keycloak-dev] How to do default claim mappings?
On 2/23/2015 3:07 AM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Friday, February 20, 2015 4:47:39 PM
>> Subject: [keycloak-dev] How to do default claim mappings?
>> Per realm and per protocol (saml or OIDC), I'm going to need to register
>> a set of default claim mappers into storage. ProviderFactorys are
>> loaded at boot time and each of their init() methods is invoked. I'm
>> thinking of adding a new method to ProviderFactory
>> void preprocess(KeycloakSessionFactory sessionFactory);
>> This would be called after all providers have been loaded. This would
>> allow the OIDC and SAML providers to browser every realm to make sure
>> the appropriate built in claim mappers have been registered.
>> I'm also thinking of adding a RealmCreationListener registration method
>> on RealmProvider. Within ProviderFactory.preprocess() components could
>> register themselves with the RealmProvider for realm creation events so
>> that they could add additional metadata specific to their plugin.
> preprocess is fine, except it adds a method that most providers won't use
> and also the name is a bit confusing.
> RealmCreationListener is fine, but what if we add more and more "events"
> providers can listen to. We'll get a lot of methods and listener types.
> What about adding a general purpose event listener framework for providers?
> We can add
> * ProviderEventListener ProviderFactory.getProviderEventListener()
> The bootstrapping process would after calling init on all ProviderFactory,
> call getProviderEventListener. If it returns null it won't register it,
> but otherwise it'll add it to the list of listeners.
> ProviderEventListener would have the following method:
> * void onEvent(ProviderEvent event)
> ProviderEvent would have:
> * EventType type
> * Map<String, String> details
You're right. Probably shouldn't be so specific and should leave some
room for more event types.
You can't really have KeycloakSessionFactory control a generic listener
framework. Otherwise the KeycloakSessionFactory is going to have to
know about every event type and which provider they must be registered
with. Also, you don't need an EventType or Map of details. Just do
instanceof/typecast to the specific event type.
I was thinking all events would be passed to all listeners, they would have to filter
themselves. Event types should probably be part of core, rather than something that's
introduced by providers themselves.
JBoss, a division of Red Hat