Access to more data from a Lambda?

[ericher4worximity]

(Access to more data from a Lambda)

Description

I am actually testing FusionAuth and am currently using Lambda to augment the claims into a JWT. According to the documentation, we have access to the user and the registration. This is very limited and I'd like to know if there is a way to get access to more data.

To be more specific, it would be really useful to get the name of the user's group (the user object only returns the groupId,id and insertInstant.It would be also vey useful to get the user's families (including a family name - which is actually missing) as part of the user object.

• Family members
• Families
• Group memberships

Is it already available and I simply missed something and, consequently, do not have access to more data?

Thanks
Eric

Related

• [Feature] Add request/fetch/AJAX support to lambdas #267
• Expose the state param to the jwt populate lambda #946
• Pass encoded id token to openid reconcile lambda #2189

[robotdan]

Thanks for the request, you haven't missed it - currently the user and the registration the only two objects available to you in the lambda invocation.

The family does not have a name attribute, it is simply a grouping of family members.

[ericher4worximity]

Thanks for the quick response.
Would it complicated to add the group name to the user's membership object, along with its id?

[ericher4worximity]

Concerning the family, what was the resining to not include them in the user object available in the lambda invocation? Wouldn't be useful to get the list of families a user belongs to in the lambda invocation? The ids wouldn't be enough tough, it would need a name per family.

[robotdan]

Performance is always a consideration in everything we build, in most cases the family and groups will not be needed.

We can certainly use this feature request to make additional things available to you in the lambda. What we'll likely end up adding is a helper of some sort to ask for these types of things so it can be lazily retrieved so we do not make any additional database requests unless requested.

As I mentioned earlier, the family does not have a name. We do not currently have plans to add a name to the family. If you have a use case please open a feature request and document the use case so we can review it.

Thanks!

[mreschke]

I second this request at least for Groups (membership). Group name is very important to me. So important it would be valuable if it was in the main /api/users/registrations as well. Even if not in main endpoint, having it available in the lambda itself so I can add group names to JWT would be hugely great. Why? Because roles don't work in my particular situation. Long story due to multiple APIs being hit from one OIDC token. In the end groups of users are more valuable to me. I get I can hack roles to mimic the groups which would work but it makes the management of users more particular and error prone. Groups for me are more robust honestly. In the end I suppose just a gruopId could work I would just have to make my own hard coded mapping of Ids->names or of course re-hit your /api/membership a dozen times, but all this just for a name. Names are good. Same with registration names, would be hugely valuable of they were just in the API to begin with.

[sedough]

I would also like be able to get access to additional group information, including name and custom data.

[mgetka]

It would also be useful, if consents details could be injected into JWT via lambda. It would allow the applications to prompt the user for missing consents without querying the API on each login event.

[dkiser]

I'd like to add application.data from an application object, or even the entire application object for the following use case.

As a FA Admin, I Should Be Able To utilize application metadata in JWT Populate So
That I Can re-use a lambda function across multiple applications, but expose app specific metadata values in common lambda definitions

I am running into a use case where there is metadata that we'd like to add at application creation time (and/or update later) that we can utilize in Populate. For example, adding a custom claim for brand, where the values may be different across application definitions.

[ruckc]

We would really like this implemented (We need to manage user group assignments during LDAP logins).

[mooreds]

@ruckc Thanks for the feedback. Would you like to be able to make arbitrary HTTP calls (with #267 covering your needs) or is there something else that you're looking for?

[ruckc]

Our main use case is looking up existing FA groups and assigning/removing users to/from them based on LDAP Response (memberOf attributes). Currently our only option is to have a static mapping of memberOf DN to FA group hardcoded, which works for a small number of groups, but it doesn't scale as we add more groups over time very easily.

[bostjan]

We can certainly use this feature request to make additional things available to you in the lambda. What we'll likely end up adding is a helper of some sort to ask for these types of things so it can be lazily retrieved so we do not make any additional database requests unless requested.

+1, something like an internal access to the API in a read-only fashion. (Or just allow access to own API, and have us users configure a correct API key+permissions to be able to get to it.)

[S4RD7R]

I have the same request as @dkiser

I'd be happy with an API in the Lambda they let me get additional objects so that this feature didn't affect everyone's performance.

[awoodobvio]

I also wanted to add that we were trying to use Groups to associate "Roles" to users and then send those "Roles" down in the JWT along with the Group names. Ideally, we'd have access to all the "Roles" that the user has associated with them whether directly or indirectly through "Groups". Furthermore, we want to vary this association by a passed in scope. The lambda seemed like a great place to do this, but the data available seems to be lacking to solve our use case.

What we actually want to model is the following:

Below, I've modeled a scope as "Customer". But it would be any data element we want to scope to. Note that there could be a large number of different "Customers". This seems to align roughly with your entity type & entities concept, but it doesn't quite map (as near as we can tell), but happy to be told differently!

User has a particular group for all customers.
(User) ==> Group

User has a particular group for a given customer and would override the above assignment if both are present
(User, Customer) ==> Group

Group has a set of permissions for all customers
(Group) ==> Permission Set

Group has a set of permissions for a specific customer (which would override the global one above)
(Group, Customer) ==> Permission Set

I'm not discussing negated permissions here, which are a possible later scope - for now I'm only trying to get the proper permission set based on aggregating the groups together.

---

Examples

Group -> Permission Mapping
(Sales Associate) ==> Read Customer
(Admin) ==> Read Customer, Write Customer, Discount Product
(Sales Associate, Customer 2) ==> Read Customer, Discount Product

User to Group Mapping
(User A, Customer 1) ==> (Sales Associate)
(User A, Customer 2) ==> (Sales Associate)
(User A, Customer 3) ==> (Admin)
(User B) ==> (Sales Associate)

In the end if pass in the "customer" as a "scope" to the authorize endpoint for authentication code flow, we'd like to craft a JWT with the proper permission set in it.

User Permissions in JWT for given customer scope
(User A, Customer 1) ==> Read Customer
(User A, Customer 2) ==> Read Customer, Discount Product
(User A, Customer 3) ==> Read Customer, Write Customer, Discount Product
(User A, Customer 4) ==> [] (No Permissions)

(User B, Customer 1) ==> Read Customer
(User B, Customer 2) ==> Read Customer, Discount Product
(User B, Customer 3) ==> Read Customer
(User B, Customer 4) ==> Read Customer

We've been trying to model this with Groups, Roles, Applications, Entities, etc. Unfortunately, it doesn't feel that FA is expressive enough to do this currently. I think entities might be very close, but we can't access them from inside Lambdas.

We've started to look at augmenting the JWT token with our own service and something like SpiceDB, but that's less than ideal.

That concept looks something like this:

• Host our own /token endpoint that calls Fusion Auth's API.
• Ask FA for the access token.
• Rebuild a new JWT using external data store with the resulting permissions
• Pass it through FA's JWT signing API endpoint.
• Return that token.

Ideally, we'd like that data to be hosted in FA (entities, data element in an application, etc.) and be able to get to it from inside the lambda functions and also avoid the double call to FA. We could skip the second call by signing the JWT ourselves, but then we are starting to be the source of truth, which means that FA is delegated to just an identity provider.

Alternatively, a webhook that calls out to us to "augment" the JWT before signing would be ok, but we'd still need to store the authorization data separately from FA.

Note also that this data is not "fixed" so hard coding is not an option.

[mooreds]

@awoodsprim just an FYI that this seems like a forum post (because it seems like you are looking for feedback). Here's our forum https://fusionauth.io/community/forum/

If I read that wrong and you are simply sharing a use case that would work better if you had access to more data from a lambda, please feel free to ignore me :).

If you feel like there's an issue with FusionAuth (a missing feature or a bug, like, say, being able to get the roles a user is assigned to via a group from a lambda, which is one thing I see mentioned in your comment), it's best to submit that as a separate issue and reference this one.

Thanks for using FusionAuth!

[robotdan]

Support for HTTP requests will be out in 1.35.0 as part of this deliverable.

• [Feature] Add request/fetch/AJAX support to lambdas #267

With this support you'll be able to make a REST call to FusionAuth over localhost, so in theory that should open a lot of doors for getting more data in the lambda. If you can get it with a FusionAuth API, you can get it in the lambda.

The first release is just a tech preview, we'll be adding more features shortly such as secret management.