[keycloak-user] Implementing a non-standard, custom IDP used for identity brokering

[Dominik Guhr]

Hi everyone,

I've a Problem creating a custom Identity Provider which I want to use 
for identity Brokering (using kc version 3.2.1) and hope you could help:

** My Scenario:

There's a legacy, non-standard, xml-based "SSO" Protocol which I want to 
broker to enrich it with roles etc. and provide it as an option in my 
realm beneath ither options such as a brokered IDP using SAML, social 
login, etc.

** What I've tried so far:

Writing a project and provisioning it to the wildfly as a module with 
following structure:

//IDP class
public class MyIdentityProvider implements 
IdentityProvider<MyIdentityProviderConfig> {
     //overridden methods (not implemented)
}

//Factory
public class MyIdentityProviderFactory implements 
IdentityProviderFactory<MyIdentityProvider> {
     //overridden methods (just implemented getId -> "MyIDP" and getName 
"My IDP" so far)
}

//config
public class MyIdentityProviderConfig extends IdentityProviderModel {
	//empty so far.
}

Plus the org.keycloak.broker.provider.IdentityProviderFactory in 
META-INF pointing to com.my.MyIdentityProviderFactory

Outcome is, when I'm publishing this to keycloak, I've got a new field 
on the identity provider dropdown (which is unclickable, yet, expectedly).

**My Problems/Questions:

1. All IDPs I see implemented are using standards such as oauth2, but I 
am missing a more general architectural advice for custom 
implementations, such as "you have to override this, that and that 
method and you definitely need this, that and thus property / process to 
be compatible to keycloak with your custom SSO

So, question: Which methods and interfaces do I definitely have to 
implement to get my custom idp going? Is there something like an 
architectural overview? (considering I am on the right track here)


2. I get this warning starting keycloak:

WARN  [org.keycloak.services] (ServerService Thread Pool -- 50) 
KC-SERVICES0047: My IDP (com.my.MyIdentityProviderFactory) is 
implementing the internal SPI identity_provider. This SPI is internal 
and may change without notice

So, this leads me to the second question: Am I missing something? Am I 
on the wrong track, perhaps? Is there another, better way to implement 
this? (I am fairly new)

And last but not least, a very general question:
3. am I on the right mailinglist for this kind of question, or is this 
more for the dev-list? Or do u guys have a slackchannel or something 
like that where I could join?

Would be great to hear from you!

Best regards,
Dominik