9:36 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev