If you use the advanced registration forms, you can edit user data now. This was recently released as a premium feature (requiring a paid license; more info here).

More info on setting up the user data editing screen: https://fusionauth.io/docs/v1/tech/guides/advanced-registration-forms/#editing-user-data-in-the-admin-ui

We have users that have been successful in configuring with AD v2. We have not yet tested or updated the documentation.

This may be helpful. https://github.com/FusionAuth/fusionauth-issues/issues/855

This is configurable. Go to https://fusionauth.io/docs/v1/tech/core-concepts/tenants/#jwt (though the screencaps are a bit out of date) but you’ll go there in your instance.

You’ll see refresh token settings.

If you’re using a fixed expiration, then it never expires based on last usage, but just based upon time since it was issued.

If you’re using a sliding window expiration, then it will expire based upon the time since it was last used.

@jbradford Another option, is if you're on the login page, you can add &showPasswordField=true to the URL and that should render the login form with the option to add a password.

Related GitHub issue: https://github.com/FusionAuth/fusionauth-issues/issues/995

I get an email that does not correspond to the application that initiated

Can you provide the applicationId when you initiate the forgot password flow?

I will just toss out some thoughts I have on in-house solutions:

It will probably take about 8-12 months total to fully implement and test a custom IdP with OAuth, OIDC, SAML, etc. (plus ensuring it is FIPS or SOC2 compliant) You’ll have to pen test regularly You’ll probably need a security audit on it yearly You’ll need to engage security researchers to continuously audit your code, APIs, etc. (pen testers are fine but security researchers find things pen testers don’t) You’ll need to monitor CVEs and new exploits to ensure you are safe (at the network, server, and app levels) You’ll need to maintain it for as long as it is in use You’ll need to keep it compliant with new specifications and security standards

Undertaking these tasks can work for some teams, but walk into it with eyes wide open. Nobody likes to have their auth credentials stolen, and you need to spend time and money to prevent it.

More here: https://fusionauth.io/upgrade/from-homegrown/

Hi @curtis-ruck ,

I think this would be a couple of new features:

detecting need for password change (and informing the user) allowing the user to change their password in ldap through FusionAuth

Would you mind filing them here? https://github.com/fusionauth/fusionauth-issues/issues

Or, if you have a support plan, please file a ticket here: https://account.fusionauth.io/account/support/

Hiya,

I think we'd need a bit more information to help debug the situation. Useful info to share:

What you are trying to do, specific step by step of clicks you make, APIs you’ve called, configuration you have, things you’ve changed, etc. More information is better. For example, what you are seeing, specific panels in the UI, API status codes, errors, screenshots, etc. We want all of it. What you expected to see. Sometimes this is obvious, and sometimes it isn’t. Err on the side of over sharing. What you've tried already. Sometimes this can help us narrow down the issue more quickly. The version of FusionAuth you are using (this information is available on the admin screen in the lower left hand corner). The number of FusionAuth nodes you are running in your deployment. Information about supporting infrastructure such as the database and elasticsearch, including the version and architecture (is the database local, cloud managed, etc). All FusionAuth log files you can provide. Please don't provide snippets because often the issue won't be in the snippet but somewhere else in the logs. Providing us with complete log files upfront helps us track down issues faster. And you'll avoid getting replies like "please send the complete log files". Of course, please remove any sensitive information from the log files.

Yes, you can have FusionAuth simply federate identity and not hold anything permanent in its own datastore. SSO should work in that case.

Two options:

If your existing user store can speak SAML or OIDC, you should be able to use an identity provider https://fusionauth.io/docs/v1/tech/identity-providers/ You would need to modify the theme and you'd probably want to use a hint. If your existing user store can speak LDAP or a JSON API, you can use connectors without migrating (this is a feature for which you must buy at least a developer license, starting at 125/month, more here: https://fusionauth.io/pricing/ ). Here's more on connectors: https://fusionauth.io/docs/v1/tech/connectors/

In both these cases, FusionAuth communicates with your userstore through some kind of facade, not directly with the database. Such direct database access isn't supported.

I'm not sure how this will work for all aspects of FusionAuth (password expiration, passwordless, etc) but for the main login flows it should work great.

@dan Gotcha! Thanks for pointing that out in the docs. I think for now I will handle limiting the search in my app's business logic because I can't justify the Elasticsearch overhead just yet - but I'll keep the option in mind. Thank you!

Works perfectly. Much appreciated!

Hiya,

I'm not sure, haven't done much with k8s. From a quick google, it looks like you might use helm upgrade?

https://helm.sh/docs/helm/helm_upgrade/

For exporting changes, it depends on how you make the changes. There's a community supported terraform module, but it doesn't cover all the apis (PRs welcome!).

You could also script all your changes using the API and apply those scripts to different environments. We mostly see folks writing migration scripts that call the APIs. These are very similar to database migration scripts except they make REST calls instead of SQL. The scripts are run during upgrades of their app. (If you are using an app like rails, you could even leverage the existing migration framework and a client library.)

Kickstart works well for dev envts and CI, but doesn't handle changes (it assumes there is no data in fusionauth and won't run if it sees any).

Moved to q&a section.

Hmmm. I'm no gcloud expert. But here's where I'd start looking.

What version of FusionAuth are you running? Can you connect to the mysql database in gcloud directly? Are you seeing any errors in the FusionAuth log files? Can you connect to where FusionAuth is running and try to connect to the database directly? Is the issue the connection or that FusionAuth isn't running as a privileged user? If the latter is the case, silent mode might help. You can run the table create statements directly against your database and FusionAuth will notice that after starting up.

This looks like a bug. Can you file an issue here: https://github.com/fusionauth/fusionauth-issues/issues

With your browser details, version of FusionAuth, console messages (if any) and any replication steps?

Thanks for using FusionAuth!

If you want to skip calling FusionAuth for each of these validation events, you can validate the JWT on your end without a network call.

If you configure a key pair (public + private) to sign your JWT, then the public key will be available in the JWKS. Many libraries exist that will validate JWTs using JWKS.

https://fusionauth.io/docs/v1/tech/oauth/endpoints/#openid-configuration
https://fusionauth.io/docs/v1/tech/oauth/endpoints/#json-web-key-set-jwks

I'll also add, GitHub is not OpenID Connect compliant and may or may not work great.

It only "works" because of the documented configuration which allows us to work around their deficiency.

There is an open feature for Login with GitHub.
https://github.com/FusionAuth/fusionauth-issues/issues/33

The most ideal scenario is for GitHub to offer an OpenID Connect compliant login option so that standards based libraries and products like FusionAuth can properly support them without building one off implementations to adjust to their flavor.

Not sure if this helps, as we don't currently use different tenants at this point in time, but we do for sure enforce sending the tenant id to each call:

When you setup the OpenIdConnectOptions ---

private const string TenantIdParameterName = "tenantId"; ... options.Events.OnRedirectToIdentityProvider = context => { /* Fusion auth has the option for multiple tenants - when multiple tenants enabled, we have to ensure we hit the right one for user auth. */ context.ProtocolMessage.SetParameter(TenantIdParameterName, authSettings.TenantId.ToString()); } options.Events.OnRedirectToIdentityProviderForSignOut = context => { context.ProtocolMessage.ClientId = authSettings.ClientId.ToString(); context.ProtocolMessage.SetParameter(TenantIdParameterName, authSettings.TenantId.ToString()); return Task.CompletedTask; };

Not sure if that helps you - you will have to look at the current HttpContext to decide what you want to do.

Have you checked out this documentation?

https://fusionauth.io/docs/v1/tech/themes/

That should help you customize your theme.