There are many using FusionAuth in this manner, we don't currently offer any specific documentation on integrating with API Gateways.

I would love to have this documentation at some point, however as far as I know most if not all of the options I've seen have a fairly standard integration using a JWT.

Once you know what the Gateway such as Kong is looking for in the JWT to perform authorization you can use the JWT populate lambda to ensure the JWT has everything you need.

https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate
https://fusionauth.io/docs/v1/tech/oauth/tokens

Hope that helps!

Hi,

If you are just using OAuth, I'd follow this tutorial from Microsoft: https://docs.microsoft.com/en-us/aspnet/mvc/overview/older-versions/using-oauth-providers-with-mvc

You can use OAuth with FusionAuth without using the client libraries at all. It's only when you need to call APIs outside of OAuth that you'll need the API key and the client libraries.

Let me know if that helps!

So there are a number of ways to approach this, but they'll all require you to write some code.

I don't know your current system or skillset, but this is how I'd do it:

have someone sign up to create a club in an application in the default tenant. create the tenant, but no users in the tenant. You could set defaults as needed. verify they are a real club (in whatever way you desire) on verification, add an application and a user account based on the account in the default teannt. Notify the user via email that their club account is now available. users can then sign in to the created application in the new tenant.

If you need the ability to deactivate the tenant, I'd write a script that deactivates all applications within a tenant and possibly deactivates the user in the default tenant. Note that when a user can't log in to an application, you may have to check carefully for an HTTP status, see more here.

Is there a way to customize the login process to check other conditions besides the credentials, in this case the 'verified' attribute?

If you are using the login API, you can check any number of items on the user or other objects, but you have to build your own pages. If you are using the OAuth grants or the provided login pages, there are no customizations like you suggest available. Please feel free to file a github issue with details of how you'd like this feature to work.

Hope this helps.

Hiya,

I see a method that looks useful: ExchangeOAuthCodeForAccessToken in this file:

https://github.com/FusionAuth/fusionauth-csharp-client/blob/master/src/main/csharp/FusionAuthClient.cs

Looks like it was released in version 1.12.0. What version are you using?

At this point, after the login process, do I have to apply for the token again with username and password? if I want to access the token from API?

When you get the access token, you can then present it to whatever needs to verify the user is logged in. If you enable refresh tokens, you can store that off and present it for a new access token without the user logging in again. Check out this post about how the authorization code grant works for more details.

.net core doesn't work with older frameworks of asp.net(4.5.2.) installation error.

I filed an issue about that. Not sure we can fix it, since ASP.NET 4.5.2 is over 5 years old, but at least we can take a look.

@wwelchj is correct.

However, note that FusionAuth considers the sending of the password email to be a form of email verification. From the docs:

If you have also enabled email verification and do not select to skip verification using the skipVerification parameter, only the setup password email will be sent to the user. Setting up the password using the email sent during this user create operation will implicitly verify the User’s email if it is not already verified.

Hmmm. Can you share the token text, please?

We validate using RFC 5322 which defines the local part as a dot-atom;

“that is, it contains no characters other than atext characters or “.” surrounded by atext characters.

As far as I know the examples given are not valid email addresses. I think the only way you can begin or end an email address with a . is if it is quoted.

@dan yes this answers my question perfectly! I appreciate the detailed answer.

While we continue to improve FusionAuth (and will always have a free community edition), if you are interested in paying for a specific feature to be built, we're happy to chat. Please contact us and we'll be happy to discuss costs and timelines.

This may be useful if what you are trying to extract is in ElasticSearch (user data): https://elastalert.readthedocs.io/en/latest/

Doesn't help with other aspects of the system, but I believe we have some features planned.

Yes, any variable defined in kickstart can be used in any of the includes.

I can see we can create applications and add tenants to them, which can't be edited/changed later. Is it possible to Add multiple tenants to one application? And maybe change the tenant later.

Nope, applications are contained within tenants. Here's a blog post talking about multi tenant in FusionAuth.

Also, on the documentation, it can be seen that in order to support multi-tenant or offer services to more than one client.
In this scenario, it is suggested to maintain separate Users, Applications, and Groups for each of your clients.

Yes, you can think of a tenant as an entirely separate installation of FusionAuth. So you'd have to create users, applications and groups for each tenant. Another way of structuring this would be to have an application for each client. Which you choose depends on how much separation you need.

what is the purpose of multiple application and multiple tenants?

The main purpose of using tenants in the higher level of separation. If you want each client to have their own FusionAuth theme, API keys, and a separate user space, then you want multi tenant. If you don't care about the themes, tenant scoped API keys, or that someone with the same email address wil have the same password for the application of client A and client B (because both use the same FusionAuth and live in the same tenant, the user will have the same password for each application), then separate FusionAuth applications in the same tenant will work.

Hmmm. That seems to be a bug, because the aud claim should be absent from the authorization code grant, since the user isn't registered for that application.

I filed an issue: https://github.com/FusionAuth/fusionauth-issues/issues/713

Have you tried webhooks?

Nope, webhooks completely slipped my mind, that's actually even better or my use case 🙂

Thanks for the detailed answer!

Here's a contrib project where community members have added proxy configs: https://github.com/FusionAuth/fusionauth-contrib

Please check out https://fusionauth.io/docs/v1/tech/tutorials/setting-up-user-account-lockout which walks you through the steps to lock logins after a configurable number of attempts.

We don't support this functionality at this time.

Pulled over from https://github.com/FusionAuth/fusionauth-issues/issues/700

Apparently jackson + friends make assumptions when it comes to parsing raw -> ZonedDateTime. It appears that the ZonedDateTime for createInstant when deserializing timestamps are not being handled properly somehow, so you need custom code. We have our own Jackson serializer and deserializer for ZonedDateTime to ensure we always get milli in and milli out.

Here's the code (Apache2 license) and the maven repository links if it's helpful.

Yes, a refresh token has a configured time to live (TTL). It can be configured at the Tenant or Application level.
More here: https://fusionauth.io/docs/v1/tech/core-concepts/tenants#jwt

There are a few ways to do this.

This assumes that you are running elasticsearch on a different server than you are running the fusionauth instances. If they are on the same server, you should be fine, as that is the default configuration.

The first is at the network level, using a firewall or something like security groups on AWS. If you are doing this, you can configure the server that elasticsearch is installed on to accept requests only from the server that FusionAuth is installed on.

The second is to use basic authentication. That is, set fusionauth-search.servers in the fusionauth.properties file, or the FUSIONAUTH_SEARCH_SERVERS environment variable to include the basic username and password. https://user:password@example.com. And make sure to set up elastic to use basic auth, using whatever authentication source you'd like. (You could even go meta and have elasticsearch auth the user against the fusionauth instance 🙂 ).

Further discussion here.