extension-point/process-user-data for pushing federated user details into community AAI/registry

[skoranda]

Hello,

What is the possibility of adding an extension point, perhaps called "extension-point/process-user-data", that would expect a process function?

The idea is that a federated user may come to a community first through the REMS application in order to seek access to a resource. A process function invoked after the federated user data is transformed and validated could query the community registry/AAI to determine if the federated user is already registered and known to the community, and if not it could register the federated identity into the community AAI/registry to then facilitate other identity management and authorization processes that are out of scope of REMS.

Thanks for your consideration.

[Macroz]

Hi,

The idea is precisely to add more extension points as the need arises. We have only added the bare minimum for a certain use case we have in mind.

Is the idea here to do this registering asynchronously in the background, or synchronously with the login, so that it can also fail the login or at least prevent using REMS before registering is done?

• In the former case, after user has logged in, we need to retry processing until it succeeds (as process function is defined now). The user would be able to use REMS in the meantime.
• In the latter case, the user must wait (with a loading spinner possibly) until the process finishes. The latter case could be likely implemented already as a validate function, but we are missing the spinner if it takes slightly longer.

[skoranda]

My initial thought is that the registration should be asynchronous and the federated user should be able to continue to use REMS. Success can include both "the user is newly registered" and "the user is already registered".

But it sounds like I can begin exploring myself by writing a validate function and plugging it into the existing extension-point/validate-user-data, so that we can quickly do a rough proof of concept. We would just have to understand that we may not see a spinner during external REST API calls that take longer.

[Macroz]

One additional thing to note. We had the idea that perhaps other developers would prefer writing a plugin as an external command-line (shell) program, that receives the input perhaps as JSON in stdin and returns output as JSON in stdout. This could be something we add as a type of plugin, but haven't done it yet. If you can model your idea as a shell executable, then it will be possible to use in the future. I'm sure we haven't included all useful Clojure libraries either in our current implementation (not everything can be imported to use yet).