Posts made by fred.fred

In our dashboard, we see people logging in but the Application has no name.

Where are these people logging in if not the applications we have people registered to or that they have access to where we do not have Require Registration ticked?

Yeah, something is definitely going on with 1.36.4, Nashorn (original engine), and JWT populate versus what 1.26 did

Very simple examples seem to work with like only a few lines of script.

But as the javascript gets longer, then things start breaking with a 502 error on FusionAuth (FA)

I wish there was better error logs but we are still getting next to nothing from STDOUT from the FA server.

I have spent hours today putting in little bits of script to see what errors

And the conditions seem random

Did 1.36.4 Nashorn get more strict, does it not like variables to be named certain things (even though I have checked against the list of reserved words ), or maybe we need to reindex the ElasticSearch against our users again?

One of the weirder bugs is, I'll have a ton of script that works and then I put in something as simple as:

jwt.dealer_number = "xxx";

And then I start erroring again, if I comment or delete this new script everything starts working again.

Does anyone have these issues with the lambdas since upgrading to 1.36.4 or going from a database user search to elastic search search?

Ok, now I think this a lambda error bug in 1.36.4

and nothing to do with id_token token

Still researching...

So I was able to get us 75% fixed by disabling the authentication token and keeping only the I'd token enabled on the FA application side.

But I still need to fix it to get the rest of the customers into the app.

Does anyone know a better way to diagnose or see what is causing the 502 errors?

I'm surprised the dev tools or FA logs have no other details.

Thanks

We recently upgraded our AKS instance of FusionAuth (FA) from Version 1.26 to 1.36.4 to use ElasticSearch user search.

This introduced errors with "response_type=id_token token" OIDC logins.

We did not update the receiving service provider or the FA application.

But now when we run the login to the service provider we get a 502 error when POST to https://zzz.com/oauth2/authorize after logging into FA:

I have been playing around with the

• Access Token signing key
• Id Token signing key

sections under JWT section of the FA application.

But I still get an error if I leave either setting in RS256 or RS256 - 4096 length

If I update the application to HS256 - I do not get a 502 error on login to the service provider, but now the token will not decode and the service provider will not load

If I change the response_type from "id_token token" to just "id_token" I do not get a 502 error on login to the service provider, but now the token will not decode and the service provider will not load

Did something change in how FA handles response_type "id_token token" and RS256 signing keys from V 1.26 to 1.36.4?

As I said the only difference now is that we upgraded FA.

Also, like in the Docker instructions we pipe standard out to AKS logging, so I can do kubectl logs to see the logs, but FA does not output anything meaningful:

Is there anyway to debug what is going on with the new version?

By just seeing a 502 error page after logging in and no meaningful logs in either FA AKS logs or browser developer tools means I am just trying many different things to figure out why we cannot log into this service provider anymore.

Thanks

@dan I'll take a look, but I thought those directions did not pertain to us because I want our FA instance to be the IDP that the user clicks a link from. For example, we have a page out on the internet, the user want to get to some SAML SP, which our FA is the IDP for, so they click this link:

https://myFAurl.com/samlv2/login/zzzz-222-111-000-yyy

As provided in the FA SAML v2 Integration details

But it looks like this is the only place to enter SP metadata info, correct?

We are on FA V1.26.1.

We are trying to do a demo for our business of FA as identity provider (IDP) to an external service provider (SP).

This is the SAML test we are using: https://samltest.id/

We are able to make the SP initiated SSO work.

But to make IDP initiated work, we need to upload the SP's metadata.

However, this post comment from @dan mentions that FA does not allow upload of metadata

So now how and where do we put the SP's metadata?

Is it a lambda? The application's SAML section does not seems to have a pop out or section to put the SP info in.

Thanks for any help.

@boniface we're using FA with SendGrid in our DEV environment.

We are using the SMTP server mode.

You will need to:

• Add you host and username from instructions in sendgrid. It is smtp.sendgrid.net and apikey for everyone

• Add the password from your instance under that Change Password flipper button in FA

• Make sure your default from address is registered in SendGrid as an actual domain and address that you can send from - I believe this is necessary for all SendGrid email, otherwise you could use them for SPAM

That's all we did and it worked for us.

Note since this is DEV, we are not using TLS or SSL security. But we will in QA and Production

@dan Is there any other way to assign a themed UI in the same tenant id if the client ids are different?

For example, we have the same user base from two different companies in our FusionAuth (FA) tenant.

Both companies can access the same applications that we host as defined in the applications section of FA.

However, one of the companies has a specific application that they host, which we restrict only to them by the client id of the application.

It would be nice to show a different logo on the oauth2/authorize screen when a specific clientId shows up in the querystring of oauth2/authorize

Is this possible?

We have three FusionAuth environments - Dev, QA, Production. Our UI dev is developing a custom theme in the Dev environment for us.

How do we DevOps or programmatically move her theme changes from Dev to QA then Production?

It looks like we can transport with the API using Theme Update Endpoints and sharing environment API keys so one environment can see the next environment to copy the themes over.

But is there a better way?

Thanks.

Ok this is how I fixed the post_logout_redirect_uri issue.

In my logoff method, I did this to remove the local cookies

Then because I could not use the Owin..OIDC..PostLogoutRedirectUri in the OpenIdConnectAuthenticationOptions to pass the client_id

At the end of the logoff method, I just did this:

This removed the FusionAuth session, does the log out, and redirects to my home page

Thanks to all who tried to help out

@alexander-schamne - if you don't pass the client_id it doesn't do anything but redirect to root

FusionAuth team, I think I see the issue.

On log out, my log out url string is this:

https://auth.apps-d.XXX.com/oauth2/logout?post_logout_redirect_uri=http%3A%2F%2Flocalhost%3A12620%26client_id%3D61c45c9a-XXX%26tenantId%3De1809405-YYY&x-client-SKU=ID_NET461&x-client-ver=5.3.0.0

If it runs like this, it just redirects to root:

Now if I url decode it to:

https://auth.apps-d.XXX.com/oauth2/logout?post_logout_redirect_uri=http%3A%2F%2Flocalhost%3A12620**&client_id=**61c45c9a-XXX%26tenantId%3De1809405-YYY&x-client-SKU=ID_NET461&x-client-ver=5.3.0.0

Where the ampersand, client id, and equal sign are now &client_id=, the log off and redirection works fine.

I think I can play with encoding, but is there a setting in FA for it to be able to parse an encoded &client_id= ?

@alexander-schamne thanks.

I tried your solution of adding the client id and the tenant id to the post_logout_redirect_uri and the redirection still did not work

This is how my post_logout_redirect_uri looks now:

https://auth.apps-d.XXX.com/oauth2/logout?
post_logout_redirect_uri=http://localhost:12620
&client_id=61c45c9a-XXX //My application's client id
&tenantId=e1809405-YYY //My FA tenant id
&x-client-SKU=ID_NET461&x-client-ver=5.3.0.0

It still redirects to the root - https://auth.apps-d.XXX.com/

To anyone on the FusionAuth team, how do we debug or fix this issue?

The FA debug log for the application only shows the login and not the log out.

BTW, I forgot to add in my post, this is how I am logging out the user:

This code block kills off the cookies and session for the FA login.

Note: If I add an explicit redirect to this code, such as:

I still redirect to the root of my FA instance.

@fred-fred said in post_logout_redirect_uri not working:

http://localhost:12620/

Note, we have also tried setting this localhost address as the Logout URL and we got the same redirect to the root of FusionAuth:

We are setting this post_logout_redirect_uri on our log off:

https://auth.apps-d.XXX.com/oauth2/logout?post_logout_redirect_uri=http%3A%2F%2Flocalhost%3A12620%2F&x-client-SKU=ID_NET461&x-client-ver=5.3.0.0

Which is http://localhost:12620/

However, FusionAuth is just redirecting to its own root url: https://auth.apps-d.XXX.com/ instead of the post_logout_redirect_uri

Referring to this post: https://fusionauth.io/community/forum/topic/35/is-there-a-way-to-have-a-user-who-logs-out-of-an-application-go-back-to-wherever-they-started-from-at-login

It says the logout redirect url must be an authorized redirect url, which it is:

However, FusionAuth is not redirecting as you can see from this debug session and is just going to root url instead of post_logout_redirect_uri

How do we get FusionAuth to redirect to the passed post_logout_redirect_uri ??

Thanks.

We are integrating a vendor Electron app with OIDC and FusionAuth 1.26.

The redirect_url that the vendor wants to use is: file:///vendorname/auth/callback (note the three forward slashes)

If you try to save "file:///vendorname/auth/callback" in the Edit Application screen you get this error, "Authorized redirect URLs - Invalid URL"

We thought this was a UI only error, so we tried to add the same file url via the API on

applicationRequest.application.oauthConfiguration.authorizedRedirectURLs.Add(@"file:///vendorname/auth/callback");

but we got this back as a response from fusionAuthClient.UpdateApplicationAsync:

"Invalid URL [file:///vendorname/auth/callback] for property [application.oauthConfiguration.authorizedRedirectURLs]."

Is this a legit bug for the FusionAuth team? Is there any way around this?

I can save the url as file://vendorname/auth/callback (note two forward slashes), but the vendor is insisting it be three forward slashes.

Any help or workarounds here?

Thanks.

@dan said in Is there an example of how to authorize a user to an app and allow them to access after using the login API?:

The SSO functionality details are not something we expose, it's built into the hosted login pages.

@dan yeah that is what we figured, so we are working on option 2 now, which is to make a host portal site protected by FA login, which will issue the cookies and sessions, to allow access into protected, registered content, after successful login.

May I ask, why do you have /API/Login if all it really does is authenticate but not authenticate and authorize like the Login pages?

Thanks too @joshua

@joshua thanks for replying

Here are some answers to your questions:

I am a bit confused by your use case. What is the primary purpose of FusionAuth in this instance?

We want to use FusionAuth (FA) to authorize users to FA protected OIDC apps after we login to our current SSO, which uses forms auth.

We thought calling the FA /API/login API was the same thing? And that after we logged in there, we were authorized for FA protected apps the logged in user was registered to.

But it looks like FA /API/login API is just authentication, so I guess we need the authorization part that allows users to now get into FA OIDC protected apps, without having to login again.

Are you using an OIDC compliant SSO?

No, we have a custom SSO, based on forms auth, with some old Open Id 2.0 and custom "SSO" links behind it on a portal page. Once logged in, you click over to these sites from the portal page. We want to move from Open Id 2.0 to OIDC and SAML, where appropriate.

If you could elaborate a bit on your current implementation and the steps you would like to have occur, I may be able to offer a few more pointers.

Initial phase (6 months), we want to do something like this:

6 months will allow us to clean up our user base, finish evaluating FA custom registration forms, and get our FA custom themes done.

In the meantime, we still want our users to be able to use our custom SSO to get to their sites daily, with no drastic changes in the current, custom SSO site.

After 6 months, we want our login process to look like this:

We will basically strip the old SSO site of any SSO capability and give that to FA, which will turn it into a regular OIDC protected page, which requires login to styled FA login page to get authenticated and authorized to allowed apps.

Does this make make sense?

We are basically stuck on the SSO session part. We can login (authenticate) with FA, but now we need to authorize our users into to their registered OIDC sites without them having to login to FA again.

Thanks for any help.

Re: Can I add new functionality to the login page?

In the above post, we want to implement @dan example initially:
don't use our hosted login pages, instead build your own login pages (and all the other stuff like reset password, etc) using the Login API. You get total control of the login experience, at the cost of more custom code.

We already have a SSO that forms auth's our users with our own DB.

We have already loaded our users into FusionAuth (FA) as well.

What we want to do is have our users login to our SSO, then we will call FA's login API.

Then when they hit the portal page of our SSO, we want them to be able to click a tile which is linked to https://MY_FA_SITE/oauth2/authorize?client_id=SOME_CLIENT_ID&response_type=code&redirect_uri=https%3A%2F%2FMY_OIDC_SITE.COM%2Fcallback (I think this is the correct url?)

Which ends up sending them into https://MY_OIDC_SITE.COM/ without having to login to FA again.

Can someone point us towards resources that will allow us to do this in NET Core, NET framework, or pseudocode?

Or give us a hint as to what type of login flow this is?

Thanks.