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/
Hiya,
Weird situation. We are using SAML. Our users have two different email addresses. One is used for one particular SP, and the other for everything else. We can store one email address in user.email and another in user.data.otheremail so that is alright.
How can we send the special SP the email address it needs?
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.
@felix Hmmm.
So I read the docs and this is what it looks like to me:
Now, FusionAuth can help you generate the token in the proper format with the following claims:
avatarURL: user.avatarURL, // optional, but preferred
email: user.email,
id: user.id,
name: user.name,
As you allude to, I'd use the JWT populate lambda to do that: https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate/ It can craft a token to contain all the needed 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.
Does that make sense?
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.
Or are you asking if the client can check every so often and refresh the JWT even before it is expired? In this case, you could shorten the lifetime of the JWT, or just refresh the JWT periodically using this API: https://fusionauth.io/docs/v1/tech/apis/jwt/#refresh-a-jwt
Or am I misunderstanding the question?
Hi @Timon ,
We have no integration with password vaults. Please file a github issue with your use case if this is important to you: https://github.com/fusionauth/fusionauth-issues/issues
We store a number of secrets (keys, api keys, client secrets) and outline how to rotate them here: https://fusionauth.io/docs/v1/tech/tutorials/key-rotation/
But FusionAuth isn't a general purpose secrets manager.
Can you explain a bit more about what you are looking to do?
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).
Related documentation is below.
https://fusionauth.io/docs/v1/tech/reference/configuration/
database.connection-timeout [Integer] Defaults to 2,000
The number of milliseconds that FusionAuth will attempt to connect to the database before failing.
database.idle-timeout [Integer] Defaults to 120,000
The number of milliseconds that FusionAuth will leave an idle database connection in its connection pool before recreating it.
Also, as referenced above -
made sure we have enough connections available to the managed database (only about 20 from 47 are used) but the issue still appears.
My understanding is that more connections does not guarantee a better outcome.
If anything else occurs to me, I will post back. I hope this helps!
Thanks,
Josh
Use the managed domains feature. From the docs:
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.
Documentation:
https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/
https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/
I want to limit use of an OIDC or SAML provider to a certain domain or set of domains. For instance, I want my employees to login via a different identity provider, but my customers to login straight against FusionAuth. How can I implement this?
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.
Links are included below
https://fusionauth.io/docs/v1/tech/core-concepts/
https://fusionauth.io/docs/v1/tech/5-minute-setup-guide/
https://fusionauth.io/docs/v1/tech/getting-started/
Regarding roles - there are a number of ways that you can map app users and roles. One common method is with a JWT and a lambda.
https://fusionauth.io/docs/v1/tech/core-concepts/roles/
https://fusionauth.io/docs/v1/tech/lambdas/
Roles are available in the JWT upon successful authorization and are also returned as part of the user’s registrations.
I hope this is a good place to start! Let us know if you have more specific questions and we wil do what we can to address them here.
Thanks,
Josh