Yes, you can put anything in the user object that is documented here: https://fusionauth.io/docs/v1/tech/connectors/generic-connector/#using-the-generic-connector

You can return registrations which contain roles as outlined in the sample JSON in the link above.

Hope that helps!

Is this the same as https://fusionauth.io/community/forum/topic/1317/error-after-updating-the-password ? or different?

Please share any logfiles you see (you can go to "System" -> "Logs" in the admin UI to view them).

Hi @saitulasiram94!

FusionAuth can act as both SP and IdP via SAML.

You may want to review how Gmail integrates via SAML. If Gmail (as Idp) supports an SP or IdP initiated login from FusionAuth, then you should be able to integrate.

I have included our relevant documentation below.

https://fusionauth.io/docs/v1/tech/identity-providers/samlv2-idp-initiated/ https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/

Thanks,
Josh

With advanced threat detection you can block access to applications via IP ranges (it's touched on briefly here: https://youtu.be/pjGxOXamVfk?t=1209 ).

Advanced threat detection requires an enterprise license. Currently you can't lock a certain user to an IP range, though.

Please feel free to file a feature request with details of this use case if you'd like to see this implemented.

Tested and verified this works. Feel free to use theme.data to your heart's content, @mmcnamara !

@joshua Thanks for confirming the behavior I am seeing. I will try using a library to validate the jwt instead.

In 1.28.0, FusionAuth introduced a linking strategy and a first class 'link' object. This is part of the community/free edition.

This is how I'd approach that. You'd have to get the user to login via their social account and get their unique user Id (for, say, Google). This could be done via a page in your application.

Then you'd take that Google user Id and create a link using the APIs: https://fusionauth.io/docs/v1/tech/apis/identity-providers/links/

Here's more on this: https://fusionauth.io/docs/v1/tech/identity-providers/#linking-strategies

After the link is created, the next time the user went to login, they could use either their old email/password creds or the linked social login.

@yb98

I think what you are looking for is OAuth's back-channel logout. This is under consideration under ticket 465.

https://github.com/FusionAuth/fusionauth-issues/issues/465

As a workaround, you would have to use a backend (or another environment that can appropriately hide credentials) and make a call to revoke the refresh token on a user.

I may be misunderstanding your workflow, but I believe the above should point at a possible solution.

Thanks,
Josh

@james-hudson

One thing to try would be to turn on email debugging/logging to see if you are offered any additional clues.

Additional information can be found on our troubleshooting page

https://site-local.fusionauth.io/docs/v1/tech/troubleshooting/#troubleshooting-email

Thanks,
Josh

The server that issues and signs the JWT is called the Authorization Server. This is what FusionAuth is, as we issue and sign the JWTs which are then presented to other servers via API calls.

The servers that are connected to resources that a user is trying to access by first authenticating with a JWT are called Resource Servers.

So, for example, if you have a ToDo app, where a user is trying to access a list of ToDo items, the user would first authenticate with the external IdP. Then the JWT is issued by that IdP, passed to the client, and then the client would present that JWT to the resource server to gain access to the ToDo items.

For what it's worth, in SAML the auth server coincides with the IdP, and the resource server coincides with the Relying Party.

thanks @joshua,

1361 seems about client secret rotation, not refresh tokens.

But the implications seem the same to me: if you rotate - whatever you rotate - you have the problem above and the need of a grace period.

I think my question is answered anyway, will look forward to adopt refresh token rotation when it's safer to do that in the face of clients that use parallel requests.

cheers
f

Hi @dan

If you require any more details or can give some suggestions kindly let me know I am still unable to figure out the error causing here

@cyrill-lippuner

Ah, ok the scope of the question/request makes sense to me.

With the disclaimer that I have not used the typescript library extensively (yet), when I search this library for "patch" it does appear that we do support PATCH.

Can you confirm that you see this as well (or possibly I am overlooking something)

https://github.com/FusionAuth/fusionauth-typescript-client/blob/master/src/FusionAuthClient.ts (this is the library I searched)

Thanks
Josh

We don’t currently resolve any environment variables in the themes, or anything other than what is documented here: https://fusionauth.io/docs/v1/tech/themes/template-variables/

But you can set variables in the Helpers template using assign that can be used in other templates. You could use a templating language like jinja to build the Helpers template at build time and then a script to load it during deploy. (Or even sed.)

You can also create different themes (a dev theme, a qa theme) and assign them via scripts to the different environments (unsure if you are using different tenants to represent environments or different FusionAuth instances, but the concept is the same).

@pleymor said in CORS error when posting to /oauth2/token:

Access to XMLHttpRequest at ... has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

The Same Origin Policy (SOP) is a security measure standardized among browsers. It is needed to prevent Cross-Site Request Forgery (CSRF). The "Origin" mostly refers to a "Domain". Same Origin Policy prevents different origins (domains) from interacting with each other, to prevent attacks such as CSRF (Cross Site Request Forgery) through such requests, like AJAX. In other words, the browser would not allow any site to make a request to any other site. Without Same Origin Policy , any web page would be able to access the DOM of other pages.

This SOP (Same Origin Policy) exists because it is too easy to inject a link to a javascript file that is on a different domain. This is actually a security risk ; you really only want code that comes from the site you are on to execute and not just any code that is out there.

If you want to bypass that restriction when fetching the contents with fetch API or XMLHttpRequest in javascript, you can use a proxy server so that it sets the header Access-Control-Allow-Origin to *.

If you need to enable CORS on the server in case of localhost, you need to have the following on request header.

Access-Control-Allow-Origin: http://localhost:9999

No worries @laurent-michel !

FYI, this isn't just for applications.

For every resource in FusionAuth during creation you can either provide a valid UUID to control the value, or leave the UUID off and let FusionAuth create one for you.

@dan, thanks for the directions.

It looks lik you have a way to make the SSO redirect work for their widget, but not for the portal version of their solution. The portal works with a "redirect" URL parameter that the authenticating party receives and needs to send back after authentication.

I don't think FA supports arbitrary URL parameter forwarding, so this is pretty much a no go directly out of the box.

I'll have a look at the widget, maybe that's a better solution for us anyway.

Ok this is how I fixed the post_logout_redirect_uri issue.

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

c99db979-5e36-4e07-8cbd-8ce25bd73775-image.png

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:

39f0427a-f30a-4e54-b719-1c6689476674-image.png

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

Thanks to all who tried to help out

Please also note - We are currently logging in with a custom UI that is not related to the FusionAuth instance. We're just utilizing the APIs to simulate that login.

You want to look at https://fusionauth.io/docs/v1/tech/lambdas/samlv2-response-populate/ This can update the email/nameId before it is sent over to the special SP.

You will want to create a separate application and set the Response Populate Lambda to the lambda which does this transformation. This can be done via the UI as illustrated here: https://fusionauth.io/docs/v1/tech/samlv2/