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

Tomas-- Thanks--it certainly seems close, you're right! It looks, however like an OIDC provider still uses a static configuration even though it loads it from the discovery URL--that is, once it's loaded at configuraiton time, it doesn't discover new changes, and there isn't an option to refresh/store that discovery endpoint outside of configuration. It's not clear to me how important that feature is--on one hand, it seems unlikely that we should expect frequent changes; on the other, in the short time since I started exploring this setup, I have encountered three changes in google's OIDC endpoints between what was hard-coded into keycloak, what is in their documentation, and what their current discovery endpoint provides. (And, the google docs specifically suggest refreshing from the endpoint periodically). Thoughts? James On Tue, Jan 15, 2019 at 10:31 AM Tomas Kyjovsky <tkyjovsk(a)redhat.com&gt; wrote: > Please disregard my previous message. > > Looking at the docs [1] and the Admin Console UI this should be already > possible with the OIDC identity provider. > When creating a OIDC identity provider in the Admin Console there is an > option at the bottom of the page to import OIDC configuration metadata from > URL. > > Does this cover your use case? > > > Regards, > Tomas > > [1] > https://www.keycloak.org/docs/latest/server_admin/index.html#openid-conne... > > > ----- Original Message ----- > > 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 > > > -- -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- / -... . / ..-. .. - 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev