[keycloak-dev] Using OIDC adapter with 3rd party IdPs

Marek Posolda mposolda at redhat.com
Tue Nov 13 15:36:09 EST 2018


Hi Dmitry,

AFAIK there is no plan to support our OIDC adapter with 3rd party OIDC 
identity providers.

It was needed to do this just for the SAML adapter and support it with 
3rd party SAML Idp. There were few reasons for this and one of them was 
that we wanted to provide compatibility for the users of Picketlink 
(legacy security framework, which is part of Wildfly).

One possibility to address this use-case for OIDC can be to use Keycloak 
server as proxy. You will basically configure your 3rd party OIDC as 
IdentityProvider in Keycloak. Keycloak OIDC adapter can delegate 
authentication to Keycloak server (possibly with kc_idp_hint parameter), 
which can directly redirect to 3rd party OIDC.

Marek

On 12/11/18 05:02, Dmitry Telegin wrote:
> Hello everyone,
>
> In this thread [1] Fabrizio has noted that while Keycloak SAML adapter can be easily used with 3rd party SAML IdPs, the some doesn't work with OIDC by some reason. The reason in fact is that we hardcode Keycloak-specific string templates:
>
> public interface ServiceUrlConstants {
>
>      public static final String AUTH_PATH = "/realms/{realm-name}/protocol/openid-connect/auth";
>      public static final String TOKEN_PATH = "/realms/{realm-name}/protocol/openid-connect/token";
>      public static final String TOKEN_SERVICE_LOGOUT_PATH = "/realms/{realm-name}/protocol/openid-connect/logout";
>      public static final String ACCOUNT_SERVICE_PATH = "/realms/{realm-name}/account";
>      public static final String REALM_INFO_PATH = "/realms/{realm-name}";
>      public static final String CLIENTS_MANAGEMENT_REGISTER_NODE_PATH = "/realms/{realm-name}/clients-managements/register-node";
>      public static final String CLIENTS_MANAGEMENT_UNREGISTER_NODE_PATH = "/realms/{realm-name}/clients-managements/unregister-node";
>      public static final String JWKS_URL = "/realms/{realm-name}/protocol/openid-connect/certs";
>
> }
>
> and then resolve them in KeycloakDeployment. While I've suggested to Fabrizio that he could use KeycloakConfigResolver to customize KeycloakDeployment and override resolveUrls(), I wonder could it be out of the box?
>
> I mean we could retrieve .well-known/openid-configuration from auth-server-url, or, in case of no backchannel, embed it into keycloak.json (keycloak-saml.xml style):
>
> {
>    "auth-server-url": "http://localhost:8080/auth",
>    "openid-configuration": {
>      "authorization_endpoint": "https://accounts.intuit.com/op/v1/ase",
>      "id_token_signing_alg_values_supported": [
>          "RS256"
>      ],
>      "issuer": "https://oauth.platform.intuit.com/op/v1",
>      "jwks_uri": "https://oauth.platform.intuit.com/op/v1/jwks",
>      "response_types_supported": [
>          "code"
>      ],
>      "revocation_endpoint": "https://oauth.platform.intuit.com/oauth2/v1/tokens/revoke",
>      "subject_types_supported": [
>          "public"
>      ],
>      "token_endpoint": "https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer",
>      "userinfo_endpoint": "https://accounts.platform.intuit.com/v1/openid_connect/userinfo"
>    },
>    "ssl-required": "external",
>    "resource": "test",
>    "public-client": true,
>    "confidential-port": 0
> }
>
> Seems like a valuable addition to Keycloak, but surprisingly I couldn't find any related JIRA issue. What do you think?
>
> [1] http://lists.jboss.org/pipermail/keycloak-user/2018-November/016193.html
>
> Cheers,
> Dmitry Telegin
> CTO, Acutus s.r.o.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev




More information about the keycloak-dev mailing list