Add get_groups or get_all_applications macro functionality to reconcile lambdas

[RhettPrichard]

Reconcile lambda's need a way to gain access to all possible groups and all possible registrations.

Problem

Currently, when I reconcile an active directory user with a lambda, I would have to change the lambda every time I add a new group or applications, so that the lambda would know about those groups or applications and when to add them.
Making changes on a system we do not modify very often, using a language that is not one we use often when we could write it once and cover 90% of our application changes seem a better solution.

Solution

If there was passed in a list of registration/groups that are possible, or a function to call that would provide them, then we can loop though that list in the lambda instead of writing code for each one and making a change to the lambda every time I add a group or application. This would allow my lambda to be much easier to write and have less need to be modified.
Since we would be only adding new applications one or twice a year, this opens us up to making more mistakes.
Since we do not have a javascript coder on staff, I would have to go study it again, and try to find in the documentation things like using JS5.1 and not JS6 before I started writing the code.
While not having a JS coder on staff may be unique to us, touching more parts of the systems that are already tested and working to allow for a new application or groups to be added seem not to add any benefit to any of your customers that do not want to differentiate between which applications they will provide to which users. if we could just add the script once and then only need to remember how to add an application.

Alternatives/workarounds

Currently, I need to update the reconciliation lambda every time I add a new application to make sure that each newly logged in person gets all the registration that they should have. If I don't make a change to the reconciliation lambda the user will never get registered by automation to that application.

Additional context

When we add a new application, it is mostly going to be things like a new curriculum provider, so we have no need to differentiate users, just to pass on their groups and user information so that provider can say read their attributes and make a decision of what access they get. Example: We pass employeeType as an attribute from AD, this will equal student for a student and staff for a staff member. So a curriculum provider will be able to determine basic access levels.
We also pass in all of their AD groups via userAttributes.memberOf and put it into user.data.memberOfRAW so that a later populate lambda can do more detailed access levels. But we still need every users registered for every application. which we currently would have to modify the AD reconciliation lambda to add the new application registration.

Example: I have application A,B,C, D, E and (F)usionAuth.
I would want everyone to have access to each application A,B,C,D,E but not F. This I can do in the current lambda. 6 months later I add another application called G, and now I have to modify my lambda to know about G. With the function modification I am asking for, I would be able to get the list of applications, and loop though them, adding all except the one with the name 'FusionAuth' unless they are a member of a group in AD called FUSIONAUTH-ADMINS or something like that. Currently, I would need to add another statement to add the new registration.

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[jobannon]

related to #229

[hthornton]

This would be incredibly useful to me as I'm trying to maintain >900+ group memberships and need to pass the list of groups a user belongs to on to the application in a SAML response. Right now I would Have to lookup each internal group ID in a hash table to translate it to the group name.

We add a few dozen new groups each year so version control of the lambda code quickly becomes a problem, let alone the risk of a single typo breaking all logins.

[mooreds]

@hthornton would the functionality in #267 solve the problem for you?