Easily create a list of users for your workshop or hackathon and keep it secure.

In my last blog post, “Secure Onboarding for Your Workshops or Hackathons,” I discussed how to set up an IBM Cloud App ID instance and to create an Identity and Access Management (IAM) access group. The goal is to quickly onboard many users at once for a short-lived project like a workshop or hackathon — bring everyone in to a secured environment, have the work phase, clean up and offboard the participants.

We use the Cloud Directory in App ID to manage users. The App ID instance is configured as an external identity provider (IdP) for IBM Cloud. By utilizing custom attributes for users managed by App ID and dynamic rules in IAM access groups, it is possible to map users to an access group and assign the needed privileges.

In this article, I am going to show how to create many user profiles at once in App ID by performing a bulk creation. Then, I discuss the login sequence (i.e., how users sign in to the IBM Cloud account used for the project). Finally, I briefly touch on the subject of cleanup.

App ID REST API for adding users

Like almost all other services, App ID provides a set of REST APIs. They can be used to manage an App ID instance programmatically, including the creation of users and user profiles. From my experience, tables or spreadsheets are the common form of providing and managing participant data for workshops and hackathons. Therefore, it makes sense to start off with a table as input to the bulk creation. Here, we use a CSV file with the given name, family name, email address and the workshop-related attributes to set. The code repository includes this sample set of users:

App ID has a general profile registry and the built-in Cloud Directory to manage users on its own. In order to add users to the Cloud Directory with custom attributes attached, we need to perform the following two steps:

1. Preregister the profile with the custom attributes like {"workshop_roles":["student"]}.
2. Add the user to the Cloud Directory with a status of CONFIRMED. This makes sure that participants don’t need to confirm their email addresses and the registration is “silent.”

The first step can be accomplished with the pre-register API function. For the second step, you can utilize the create user API for Cloud Directory. Both API calls are POST operations, and both require a certain JSON object to be passed in. The Python script addUsers.py, therefore, is quite short and simple. It reads in the CSV file line by line. For each user record, it first populates a new profile by adding the read values to a templated JSON object and calling the API function, then performing it similarly for the API call for the Cloud Directory. The only difference is that the scripts generates a unique, secure password instead of reading it from the file.

Once done for the given CSV file, the new users can be seen in the App ID dashboard for Cloud Directory (see screenshot below). When clicking on a user, it shows the details, including the individual custom attributes. Each user status is “Verified”:

Login sequence

With the users created and the required IAM access groups in place, the next would be for the participants to log in. For that, they visit the IdP URL as shown (and maybe customized) when creating the IdP (i.e., something in the form of https://cloud.ibm.com/authorize/accountID-or-alias/realmID). Once loaded, each users first would need to click on the Forgot password link to reset the password. The reason is that the script generated a random, unknown password:

After clicking on the Reset password button, App ID sends a link to the provided email address. The receiver then has to open the link and set a new personal password before revisiting the IdP URL again. Then, they can fill in their email address and the password as first factor. After submitting the input, they receive a one-time passcode by email (MFA as configured earlier with Terraform) that they have to put into the next form. Then, finally, they are signed in to the IBM Cloud account that is used for the workshop.

The IBM Cloud documentation for managing the account and access includes a flow diagram showing how the parts interact in the background for the login process. Note that Cloud Directory is used instead of a “Federation IdP.”

Offboarding and cleanup

Workshop users can quickly offboarded by disabling their access. To remove an individual or all users, go to the App ID dashboard and its Cloud Directory user management. There, select one, many or all users and then delete them. They will also lose access to the associated IBM Cloud. Additionally, in the IBM Cloud, go to the Access and remove users from the account. You can perform the latter task via CLI, too. The steps before could be scripted, but I prefer the visual control and confirmation before deleting/removing users.

The App ID instance and the IAM objects can be deleted by issuing the “terraform destroy” command for them. See the related README section in the code repository for details. The identity provider in the IAM settings can be reused and associated with another App ID instance. The realm ID does not change in that case, which simplifies the setup of additional workshops.

Conclusions

In this post, I showed that a group of users can be added to App ID all at once. Each user has attributes assigned that map to claims in the identity token and eventually lead to a match with conditions in access group dynamic rules. This way, users pick up the intended set of privileges for the workshop. Because a random password is generated for each user, they first have to request a password reset before being able to log in for the first time. Moreover, one-time passcode for multi-factor authentication is enabled by default for stronger security.

The instructions and code provided in the public GitHub repository allow for the quick, easy and secure project onboarding. They facilitate the user management for workshops and hackathons, including offboarding and cleanup.

To learn more about this topic, I recommend my previous series of blog posts on blueprinting the onboarding of cloud projects with Terraform and the best practices for organizing resources and assigning access in the IBM Cloud documentation.

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.