4:15 a.m.
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
8:23 a.m.
As a general answer you are on the right path but the SPI you are using is
not public yet thus the warning you are seeing in logs.
You should probably review other implementations and base yours based on
them. As you mentioned, most of them are based on standards so the code
should be easy to follow.
On Tue, Oct 24, 2017 at 7:15 AM, Dominik Guhr <pinguwien(a)gmail.com> wrote:
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
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
9:44 a.m.
On 24/10/17 11:15, Dominik Guhr wrote:
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)
There is
documentation chapter about Identity Provider. You can also
take a look at the sources of existing Identity Provider
implementations. And eventually at the Keycloak sources to see from
which place are IdentityProvider methods called etc.
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)
This WARN can be ignored by you if you're aware about
the consequences.
Which is exactly what is mentioned in the WARN message. In other words,
IdentityProvider interface can be changed anytime, so if you update to
newer Keycloak version in the future (for example 3.5 or 4.0 etc), you
may need to change your implementation as well because of the change in
the IdentityProvider interface side.
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?
Yes, it's right mailing list. We have IRC
channel, but we highly prefer
mailing list due the:
- It's ASYNC and questions can be replied anytime
- Conversations are saved and someone can search for them in the future.
Marek
Would be great to hear from you!
Best regards,
Dominik
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2634
days inactive
2634
days old
2 comments
3 participants
participants (3)
-
Dominik Guhr -
Marek Posolda -
Pedro Igor Silva