[keycloak-dev] OIDC Discovery-enabled IdentityProvider

[Tomas Kyjovsky]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


Regards,
Tomas