SAML support? about apicurio-registry HOT 27 CLOSED

We were able to integrate Keycloak with a SAML backend "Identity Provider", with this as a starting point:
https://www.keycloak.org/docs/6.0/server_admin/#saml-v2-0-identity-providers

Had to add some attribute mapping to get autoprovisioning (first name, last name, email) going, but otherwise seems to work (superficially, in our P.O.C.).

from apicurio-registry.

I suspect the right way to do this is definitely to configure Keycloak to delegate/federate to your corporate security solution. What do you currently use for corporate auth? It's possible keycloak already supports it. Or you could configure keycloak to use LDAP or Active Directory if either of those is used as the user store. If you provide a bit more context I could look into this with the keycloak team.

from apicurio-registry.

We're using okta - https://www.okta.com/ leveraging SAML - which syncs with the corp directory (how I am not sure). Almost all of our corp apps are SAML based with Okta. This seems pretty typical for most corporations these days with Okta, ping and other solutions out there.

from apicurio-registry.

OK thanks - I know that Keycloak has a ton of federation options. I'm not a KC expert but I'll see what I can find out.

from apicurio-registry.

Thank you for reporting an issue!

Pinging @EricWittmann to respond or triage.

from apicurio-registry.

In the meantime, I did find this that might be exactly what you want:

https://ultimatesecurity.pro/post/okta-saml/

from apicurio-registry.

Cool I'll take a look. Meanwhile If you need anything else let me know. Happy to test this out more. I have tomcat -> okta working with opensaml but the jboss setup seems to have different security in it and overall the tool appears designed to work against keycloak so I tried to keep that path.

from apicurio-registry.

Unfortunately yeah - Apicurio has a pretty firm requirement on Keycloak right now. With a small amount of coding I could support other Auth mechanisms easily enough, but the Linked Accounts feature really does require a backing feature of Keycloak to work. Without KC, the linked accounts stuff would need a lot of OpenID Connect type stuff to work - which I'd rather avoid.

from apicurio-registry.

Makes sense to use it. For enterprises the linked accounts are useful, but even then maybe complex as we have SAML SSO for git as well. Hopefully can figure that out after corp login :)

Thanks for quick feedback. The app is really useful. My okta admin and I will give the above a try tomorrow.

from apicurio-registry.

I haven't heard back from the KC guys yet - did you make any progress on this?

from apicurio-registry.

Looks like we got it to work. Still need to get this up correctly as its a temp server and not fully tested yet but we're able to put keycloak in between okta and first tests look good.

from apicurio-registry.

Thanks for the update! If you get everything working it'd be great to have an article written about the configuration if you're willing to do that.

from apicurio-registry.

Hi can I know how to get work apicurio with OKTA ? I think we can use both SAML / OpenID to connect apps for okta

from apicurio-registry.

@atz
Were you able to put some write up on how you got this working with SAML or okta !!

from apicurio-registry.

I suspect that everyone who got it working didn't write up instructions for it. Would still be very happy to have an article contributed for this config!

from apicurio-registry.

I'm working in a company that already has a VERY large standardized SSO installation. I'm trying to get the registry stood up, but the lack of a readily/easily pluggable SSO provider capability that would allow the registry to readily leverage an existing provider is an utter show-stopper. Without going into the rabbit hole discussion of hard coding to a single provider, the above link to keycloak as a "starting point" is now broken, and I fail to locate any reference to configuring external SAML providers in the current KC docs (buried too deeply?). Are there any updated pointers/docs on this because I truly like the capabilities in this product. The lack of pluggable SSO adaptability is likely a coffin nail for every single medium to large enterprise as they already have a mature SSO functionality which their Security team has standards built upon.

from apicurio-registry.

@jadedfire You mention Registry although this issue is for Apicurio Studio. Can you confirm?

@carlesarnal Can you add any insight into the current status of non-Keycloak SSO support in registry?

from apicurio-registry.

@jadedfire You mention Registry although this issue is for Apicurio Studio. Can you confirm?

@carlesarnal Can you add any insight into the current status of non-Keycloak SSO support in registry?

If this issue is for Registry, we might be ready to add that capability this month, so please, if you can confirm that point that would be awesome.

from apicurio-registry.

@EricWittmann @carlesarnal I am not sure the appropriate answer for this. We are looking at the open source version of Apicurio and trying to stand up a POC that works in conjunction with our enterprise. That said, we hit the issue of tying the product into our in-house SSO provider so I began searching online for resources which landed me here on this issue. What is the difference between Studio and registry?

from apicurio-registry.

Apicurio is a community with multiple projects: https://www.apicur.io/

Apicurio Studio is an API designer and Apicurio Registry provides a runtime registry of API Designs and Schemas, often used with Kafka applications as a runtime registry of Avro schemas (for example).

So we're wondering which project you're trying to get working with your SSO.

from apicurio-registry.

Honestly, I would think anything needing authentication for access. Thus, the web UI as well as any service endpoints.

from apicurio-registry.

@carlesarnal I see issue number 743 on the registry repo, but it appears closed some time back. Based on your note above, it appears that generic support for any (standards based) SSO provider may be ready this month, and that would be great for our POC and adoption. If Studio is the designer for APIs that results in the artifacts that are then used to deploy to the registry, then it follows to me that it too would move in that direction since a company would likely leverage both as parts of an overall development and operational function, yes?

from apicurio-registry.

@jadedfire our current issue is really the UI more than the endpoints. The latter should be configurable to use any openid-connect provider (@carlesarnal can confirm). However we're using keycloak.js to secure our UIs. We've not been able to find an acceptable general purpose openid-connect client in the browser. So it's still a work in progress I'm afraid.

from apicurio-registry.

@jadedfire that support is ready, but the issue you're mentioning, as you said, lives in Registry, so I'm wondering which project are you trying to use.

from apicurio-registry.

@carlesarnal registry currently, but success on that front would expect to translate into leveraging other projects within the umbrella :)

from apicurio-registry.

Ok, that's what I though, I will transfer this issue to the proper project and we can continue the discussion there.

from apicurio-registry.

Closing as this has been implemented and the Registry standalone UI now supports using any other OIDC server.

from apicurio-registry.