I’ve been working on how to support our use case o...
# gooddata-cn
I’ve been working on how to support our use case of having client authentication to see only their dashboards while using Google Auth for our analysts and staff to get in and create insights and dashboards. After chatting with our customer success rep, it became clear that each GoodData Cloud org could only have one source of authentication. I’ve been working on a PoC of having an e-mail/password authenticated portal for our clients and in my first attempt I realized that even after doing this, if you use WebComponents to do an embed it once again tries to authenticate you using the oidc configured for your organization. I also found this: https://sdk.gooddata.com/gooddata-ui/docs/cloudnative_authentication.html#functions-related-to-authentication but it’s unclear if at the end of this you still end up limited to whatever SSO provider you configured on your organization, or if you can use this to point at a different authentication source. After this effort ran me into a deadend I thought I’d ask for some direction before throwing a ton more time down other paths: 1. Is there a way to do embeds that doesn’t get me blocked by the organization-tied SSO dependency present on the WebComponent method 2. How was the user experience here achieved: https://gdui-examples.herokuapp.com/dashboard/simple. It’s a dashboard embed with no forced sso auth to view the visual. Sample code is present, but leaves out the configuration info that might enlighten how access was handled.
Hello @Kevin Taylor! Thank you for your questions. I'll do my best to answer both: 1. There is another way of authentication for Web Components besides SSO: via authentication token (also called personal access token). Please see the code snippet at https://sdk.gooddata.com/gooddata-ui/docs/webcomponents_authentication.html#programmatic-authentication — it would be exactly the same, except you would replace
. You can manage your personal access tokens on the Settings page as seen in the attached screenshot. 2. You are correct that there is no forced authentication. We do not officially offer such solution as you can see in our community thread at https://community.gooddata.com/dashboards-and-reports-56/gooddata-embedded-analytics-on-public-web-212. However, I can tell you how we do it so that you can replicate the same behavior on your side if you want to. We do it internally by deploying a proxy. The proxy forwards requests from the frontend that come unauthorized. The proxy has hardcoded credentials, it authenticates with the platform, serves the request, and then it returns the response to the user. I hope this helps. Please let us know how it works for you!
😇 1
Hi Jiri, appreciate the insights, it gave me some ideas to consider for our use case. I’m going to do a bit of poking at these and see if something usable for our use case can be prototyped. Thanks for your insight here, I’m glad I asked before chasing some of the other ideas I had at the end of the day!
👍 1
@Jiri Zajic was able to help me find a path on this which will work for our use case - for anyone who comes across this later, the approach for our use case may not work for your use case, but the GoodData team and @Jiri Zajic in specific got us something that did the trick for us (once we done some automation and process documentation). Shout out to Jiri for being the man!
🤗 1
🎉 New note created.