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/
Hey folks, I think I spoke too soon with my response 14 days ago. I misunderstood and assumed the id_token was available. There is a token on the reconcile lambda, but it is the access_token, not the id_token. My apologies.
That said, there is some work happening on issue 323 that you probably want to track: https://github.com/FusionAuth/fusionauth-issues/issues/323 (a comment or two way at the bottom). It's not finished yet, but we're looking at ways to make the id_token available to the open id connect reconcile lambda.
So I read the docs and this is what it looks like to me:
user visits canny but encounters a configured login redirect and is sent to FusionAuth
FusionAuth authenticates the user and sends the the authorization code to your app
Your app exchanges the authorization code for a token.
You send that token to canny.
Now, FusionAuth can help you generate the token in the proper format with the following claims:
And FusionAuth can take care of signing the JWT correctly, you'd just need to import the secret key (what they call the 'private key') to Key Master (or using the keys API: https://fusionauth.io/docs/v1/tech/apis/keys/ ) and configure your FusionAuth application config to sign the access token with the correct key so that when your app exchanges the authorization code for a token, it is all set to be sent to Canny.
You are asking if there is a way for the client to somehow know the user's account on the server has been modified and therefore refresh the JWT? I suppose you could have the server somehow push info to the client using something like websockets.
My advice would be further database tuning and configuration management for any managed database that is not performing as expected. You might want to try and shorten the max life even more on the connection pools in FusionAuth (HikariCP) (Think 5 seconds for a connection pool to be active).
For instance, you can review the Hikari Connection Pool Timeouts (FusionAuth side) and set them to a shorter duration than the "timeouts" on DigitalOcean's managed database (in other words, if Hikiri keeps DB connections open for 10 mins and DigitalOcean's managed DB kills DB connections after 8mins, then you will want to adjust Hikari connections to 7mins. You will incur a performance cost, however (restarting and killing connection pools is costly from a performance perspective).
Adding one or more managed domains for this configuration will cause this provider not to be displayed as a button on your login page. Instead of a button the login form will first ask the user for their email address. If the user’s email address matches one of the configured domains the user will then be redirected to this login provider to complete authentication. If the user’s email address does not match one of the configured domains, the user will be prompted for a password and they will be authenticated using FusionAuth.
Hey Dan. It has been a long time! I just can't get past the passwordless problem I have with fusionAuth. Your help has been stellar but I really need to hire someone to get me over the "hump". Seems like there are not too many people out there that have a working knowledge of FA. I have tried to find one! Can't hire help and can't get community help leaves me with no options.
I really like the diagram which shows the message flows in it. Is there a document, just like oauth-authorization-code-grant-sessions but for passwordless? That diagram, but for passwordless, would definately help.
Welcome! I have passed this along to our sales development team for a reach-out and introduction. FusionAuth can be used in a number of ways to meet various use cases. Our core concepts section offers a review of some of the basic functionality within FusionAuth, as well as our Five Minute setup guide to get you up and running quickly.
It seems this is working as expected as @egis described. FusionAuth needs to find an email claim in the response from the userinfo endpoint (or username, depending on the linking method) before running the reconcile lambda. I confirmed this by linking on username instead and setting preferred_username to sub and was able to confirm that the reconcile lambda executed. I had mistakenly thought that the lambda ran before linking occurred and could be used to populate email.
In my case, the issue is that my IDP (AzureAD) does not return email from the userinfo endpoint. AzureAD is very restricted in what it returns from the userinfo endpoint and allows not customization or claim mapping. It seems AzureAD populates the email claim with Primary SMTP email address, which is reserved field from Exchange, however we don't use Exchange/Outlook365 as our email service provider.
In Azure, claim mapping can only be applied to the access and id tokens and not what is returned from the userinfo endpoint. However, these tokens are not available to the lambdas.
Sorry to hear you've been having trouble with this. I've installed FusionAuth many times and not seen this error, but understand how frustrating that must be.
Can you please provide the following information to help us find the issue:
What you are trying to do, specific step by step of clicks you make/scripts you've run, 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.