Hi Team, Do we have any GoodData UI component to show the complete Analyze window? We don't want to consume embedded iframe for insight configuration as the same needs one time authentication. Regards

At the moment there is no way to embed AD with GD.UI. The iframe is the only option. As for authentication, in theory, there should not be a second login if the SSO is set up correctly (i.e. the embedded iframe is loaded from the same server as GD.UI is authenticated to). Possibly like the scenario mentioned here: https://help.gooddata.com/doc/enterprise/en/expand-your-gooddata-platform/gooddata-in[…]on/set-up-user-authentication-and-sso/saml-sso-with-gooddata

Thanks @Joseph Heun. However, we are using Gooddata CN and as per my understanding SSO login with Gooddata CN is not possible. Kindly guide me through if there's any possibility.

GoodData.CN supports OAuth 2.0 Authorization code grant flow only, via OpenID Connect (OIDC). See https://www.gooddata.com/developers/cloud-native/doc/latest/administration/auth/external-oidc/ for details.

Hi @Prashant Sharma, there’s a nice Embed dashboard with a silent login via Okta SSO article in the GoodData Community Portal. Even this article is for embedding dashboard, it should work in the same way for the AD. Also, the article relates to the specific Okta SSO provider, so I’m not sure if this is possible using other providers. Hopefully this will at least help as an inspiration.

Hi Team, We are having an extra refresh occurring on browser after Gooddata silent authentication with Auth0. Below are the network call that we see: 1. User visit our app domain 2. N/w call made to:: <https//G|https//><GDCN URL>/appLogin?redirectTo=https://<our app domain> 3. After that n/w call made to :: <https//G|https//><GDCN URL><https://gooddata-cn.primary.k8.irc-glb-dev.gcp.cwan.cloud/oauth2/authorization/gooddata-cn.primary.k8.irc-glb-dev.gcp.cwan.cloud%7C/oauth2/authorization/&lt;GDCN URL>> 4. Then auth0 silent authentication call is made 5. After that n/w call made to (redirect url of auth0 call):: <https//G|https//><GDCN URL><https://gooddata-cn.primary.k8.irc-glb-dev.gcp.cwan.cloud/login/oauth2/code/gooddata-cn.primary.k8.irc-glb-dev.gcp.cwan.cloud%7C/login/oauth2/code/&lt;GDCN URL>> 6. After that n/w call made to:: <https//G|https//><GDCN URL>/https://<https://gooddata-cn.primary.k8.irc-glb-dev.gcp.cwan.cloud/appLogin?redirectTo=%3Cour%7C&lt;our> app domain>. 7. Extra refresh on our app domain occurs now. Is there a way to avoid this extra refresh? Regards,

@Prashant Sharma the step 6 in your network call list seems weird to me:

6. After that n/w call made to:: <https//G|https//><GDCN URL>/<https://gooddata-cn.primary.k8.irc-glb-dev.gcp.cwan.cloud/appLogin?redirectTo=%3Cour%7C&lt;our> app domain>.

What is the value of the

SPRING_REDIRECT_URI

cookie, e.g. in the step 5? Does it contain something like

https://<our app domain>

? I’m asking because the last redirect (that one in the step 6) should be made to

<our app domain>

instead of

https://<GDCN URL>/<our app domain>

. Well, I consider that

<our app domain>

is a separate domain, not something which is really hosted by

https://<GDCN URL>

domain.

@Peter Plochan In which yaml this variable (SPRING_REDIRECT_URI) will be set. The variable we see is SPRING_SECURITY_OAUTH2_CLIENT_APPLOGIN_ALLOW_REDIRECT which is set to https://<app-domain>>

@Prashant Sharma no, I meant the HTTP cookie which should be part of the HTTP request made to

https://<GDCN URL>/login/oauth2/code/<GDCN URL>

(redirect url of auth0 call). I’m just curious if this cookie contains

https://<app-domain>

or

<app-domain>

without the protocol. Also, the value within this particular HTTP cookie should correspond to the

redirectTo

query parameter from the

https://<GDCN URL>/appLogin?redirectTo=<our app domain>

call (step 2 in your network calls list).

@Peter Plochan made slight correction in step 2 and step 6. The app domain contains https:// in the redirect url.

Thanks @Prashant Sharma. This looks like a bug in our authentication mechanism. The step 6 should be the call made to

https://<our app domain>

instead of

https://<GDCN URL>/https://<our app domain>

. cc @Ondrej Macek

Thanks @Peter Plochan. Let us know once the issue is resolved.

Well, I think you have 2 possibilities: • Trying to use relative URIs (e.g.

/some/path/in/your/custom/app

), but this needs having your custom application and GD.CN in the same domain. In this case you just need to configure proper routing. Don’t forget that API paths must not collide with the GD.CN. • Redirect to GD.CN endpoint instead calling redirect to the whole domain (but I’m not sure if this will work). E.g: a. Application calls

/appLogin?redirectTo=/api/profile

b. The authentication flow proceeds with all redirects and in the last step, the browser will be redirected to the

https://<GDCN URL>/api/profile

c. Your application then reads (or does noop with) the response of

/api/profile

d. After last step in

c.

, your application should be able to call other GD.CN API endpoints because the whole flow saves proper OAuth2 session cookies into the browser.

@Peter Plochan, how can we change redirectTo value? I believe it is taking the originator by default.

@Prashant Sharma if you use the Embedding mentioned in the article I posted before, it should take the last URL just before the authentication flow starts (I’m not sure if it’s the same as the “originator” you’ve mentioned). Please, would you be able to provide us a code snippet, where you are calling the

<http://GD.CN|GD.CN>

from your custom app or where the CN authentication flow starts? Thanks. In the meanwhile, we will continue trying to simulate the issue. Sorry for inconveniences.

@Peter Plochan Our flow is: 1. User opens our app login url https://login.cwan.com. Authentication occurs with auth0 here. 2. Once authenticated, user is redirected to app https://reports.cwan.com (react app) 3. Here gooddata.cn url is called https://gooddata.cwan.com (silent auth occurs here) 4. Once silent auth is successful in step#3, user is redirected again to https://reports.cwan.com (extra refresh occurring here)

Hello @Prashant Kumar, we were not reproduce your problem but I created step by step tutorial how to Embed dashboard with a silent login via Auth0. Please check it and let us know if it helped!

i think you tagged wrong prashant, @Prashant Sharma its for you i think

Hi, @Prashant Kumar. Sorry! Thanks for correction

Hi @Patrik Braborec, here the use case is different for us. User is already auth0 authenticated using different flow (Not with GD.CN flow) and then tries GD.CN login, then the user is having an extra refresh.

@Prashant Sharma It means that the user authenticates in a different application that also uses auth0 and then goes to GD.CN?

Yes @Patrik Braborec. You are correct.

Hello @Prashant Sharma, as we are still trying to reproduce the issue - may we ask you for additional details? Please can you enable preserve logs in DevTools in a browser, then to reproduce the issue with all steps you are doing/going through and finally provide us HAR file exported from DevTools? As this would be helpful for us to continue with the investigation, thank you in advance.

Hi @Lubos Hilse, once the user is logged in using auth0, there's a profile request going with 401 response after which an extra refresh is occurring. Please note that we are already auth0 authenticated using a different application and then we are trying for Gooddata login using auth0.

Hello @Prashant Sharma, thanks for your reply. Would it be possible to attach any video/screenshots that shows us - what exactly is happening? I understand that we are talking about 401 and extra refresh but if we would see more details it will help us to move forward. Thank you

Hi @Lubos Hilse, Due to the confidentiality of the data, sharing screenshots would not be possible. However, the flow is as follows: 1. Users visit our app domain (say a.com) and Auth0 authentication occurs here. 2. The user is redirected to another app domain, say b.com (silent authentication call with auth0 occurs here as well). Inside b.com, connectivity with GoodData is established. 3. Now, N/w call made to:: https://<GDCN URL>/appLogin?redirectTo=https://b.com 4. After that n/w call made to :: https://<GDCN URL>/oauth2/authorization/<GDCN URL> 5. Then auth0 silent authentication call is made initiated by gooddata. 6. After that n/w call made to (redirect url of auth0 call):: https://<GDCN URL>/login/oauth2/code/<GDCN URL> 7. After that n/w call is made to:: <https://GDCN|https://<GDCN> URL>/appLogin?redirectTo=https://b.com 8. Now the user is again redirected to b.com. This way, an Extra refresh is occurring on our app domain i.e. b.com. I hope that's helpful. Regards, Prashant

Thank you @Prashant Sharma, 7. After that n/w call is made to:: https://<GDCN URL>/https://b.com. we are wondering about this step. Which response do you receive on this? Also secondary, what is your GoodData.CN version please? Thank you, Regards Lubos

Hi @Lubos Hilse, I have updated step 7 and the response for the same is

302.