8:25 a.m.
Hello James,
See my 2 cents inline..
----- Original Message -----
All--
After observing that the Google Social Identity Provider in Keycloak was
using a deprecated userprofile endpoint [
<https://issues.jboss.org/projects/KEYCLOAK/issues/KEYCLOAK-9179>
Keycloak-9179, <https://issues.jboss.org/browse/KEYCLOAK-9169>
Keycloak-9169], I wanted to propose the creation of an IdentityProvider that
will use the OIDC Discovery mechanism to dynamically build a config [
<https://issues.jboss.org/browse/KEYCLOAK-9194> Keycloak-9194].
I see a few decision points along the way that I wanted to ask about before
an implementation, since I'm very new to keycloak and just starting to
understand the codebase. In particular, I wondered if this group could share
insight into these couple issues so I can make a more informed design:
1. It looks to me like the actual IdentityProviders are instantiated just
as they're being used, but that the models are persisted in the RealmModel.
It's not clear to me where the separation of concerns is supposed to be
between the IdentityProvider and the IdentityProviderModel-in particular
since the GoogeIdentityProvider, say, immediately sets endpoints in its
constructor. Normatively, where *should* social identity providers' model
configuration be set (and, e.g., where are the models first added to the
RealmModel)?
Provider classes are being instantiated per transaction by their corresponding
ProviderFactories and then left to be garbage-collected after Provider.close() is called.
The Provider class is given its configuration (IdentityProviderModel in this case) by its
factory which I believe loads it from cache/jpa layer. Any class extending
AbstractIdentityProvider should then be able to access its config via getConfig() method
but I don't think it will be able to update/persist it back. The provider
configuration/model itself is managed by the IdentityProviderResource (REST endpoint
accessible via REST or admin console UI) in the keycloak/services module so I think the
auto-configuration logic would have to be placed somewhere there.
2. I see that there is logic to parse OIDC Discovery configuration as
part of configuring Keycloak itself as an OIDC provider / implementer of
OIDC protocol (including building and parsing the .well-known config
elements), but that logic seems not to be used in any setting currently as a
client. Should I plan to reuse, say, the OIDCConfigurationRepresentation and
OIDCWellKnownProvider classes for their logic in handling such configs?
Currently, I'm imagining something along the lines of extending
OIDCIdentityProvider with a new OIDCDiscoveryIdentityProvider that adds a
discoverConfig method which can be used by an implementing class (such as
GoogleIdentityProvider) to discover and cache endpoints such that they are
not hard-coded into the implementing class. Each implementing class would
then have a public static final DISCOVERY_URL that it passes to
discoverConfig.
My main hangup, as suggested above, is that to implement the caching, I want
to ensure that the model configuration is stored/set in the right place.
Thanks for bearing with me as I come up to speed on this!
James
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
Regards,
Tomas