Deploy a dedicated INDIGO IAM (sys-admin nomination required)

Prerequisites

The user has to be registered in the IAM system for INFN-Cloud https://iam.cloud.infn.it/. Only registered users can login into the INFN-Cloud dashboard https://my.cloud.infn.it.

User responsibilities

Important

The solution described in this guide consists on instantiation of Virtual Machines instantiated on INFN-Cloud infrastructure. The instantiation of a VM comes with the responsibility of maintaining it and all the services it hosts.

Please read the INFN Cloud AUP in order to understand the responsibilities you have in managing this service.

Selection of the Deployment type

Important

By default, a local “admin” IAM user is created. The password associated to this account is “password”. You must change immediately this password after the deployment is completed by connecting to the IAM instance via browser. Alternatively, you can register a personal account, give it admin privileges and remove the “admin” user.

Note

If you belong to multiple projects, i.e. multiple IAM-groups, after login into the INFN-Cloud dashboard, from the upper right corner, select the one to be used for the deployment you intend to perform. Not all solutions are available for all projects. The resources used for the deployment will be accounted to the respective project, and impact on their available quota. See figure below.

../../../_images/project_selection.png

Once the project is selected, choose the “INDIGO IAM as a Service” button from the list of solutions available for your group:

../../../_images/dashboard_button.png

Figure 1: The INDIGO IAM as a Service PaaS button.

Select either Automatic or Manual scheduling as shown below:

Auto Scheduling
Manual Scheduling

In the first case, the Orchestrator will take care of choosing the best available provider, in the other case it will be performed a direct submission towards one of the providers available, to be selected from the drop-down menu. In the case of manual scheduling, the flavors displayed on the next page will be those offered by the chosen provider.

A menu is made available, as in the figure below:

../../../_images/dashboard_config.png

Figure 2: The initial configuration panel

“Description” is a mandatory field.

Deployment parameters are split in several pages and their effect is well described by both the corresponding dashboard captions and the official documentation:

  • Basic:
    • letsencrypt_test: default true to use Let’s Encrypt test certificates
    • contact_email: reference person’s address for certificate renewal
    • active_profiles: Spring profiles for IAM allowing user registration and password reset; optionally add oidc or SAML for authentication with external providers
    • jwt_default_profile: by default IAM, used to configure the claims contained in the token; can also be WLCG or AARC
    • environment_variables: docker environment variables (key,value pairs)
    • service_ports: ports to open on the VM to access the service(s). By default only SSH port (22) is opened. Please consult INFN Cloud Rules of participation the “Networking” section in order to see what are the ports that you can specify in this field. If the port you intend to use is in the list of closed-ports, you have to formally request its opening and motivate the request by following the How To: Request to open ports on deployed VMs guide.
    • flavor: number of vCPUs and memory size of the VM
  • Organisation:
    • organisation_name: the name of the organization
    • logo_url: the url the logo image is located at
    • topbar_title: the title shown in each internal IAM page
  • Access token:
    • access_token_include_authn_info: include user information in the token (username, groups, etc.)
    • access_token_include_nbf: add an nbf claim to the token
    • access_token_include_scope: add the scope claim to the token
  • Privacy Policy
    • privacy_policy_url: parameter for policy acceptance by the user; the policy document must be provided via a URL
  • Fine Tuning
    • the most important parameter is the IAM version
  • Database (the DB is shipped with the deployment):
    • db_username: a provided username for the DB user to be created
    • db_password: a provided password for the DB user to be created
  • Redis
    • To manage multiple backends it may be useful to configure redis to keep data consistent for a given user session
  • Registration
    • registration_require_external_authentication: enable authentication for registration via external providers; by default it is false, if set to true you can choose between oidc and SAML; besides, you need to add profile oidc or SAML to active_profiles (see Basic parameters)
    • registration_[…]_attribute: used to indicate which attributes provided by the external provider are taken as registration parameter values
    • registration_[…]_readonly: if set to true prevents the user from changing the registration parameter imported from the external provider
  • Local Auth
    • local_authn_login_page_visibility: allows the user to provide local username and password fields on the IAM login page
    • local_authn_enabled_for: enables local login form to users. It can be ‘all’ or restricted to ‘vo-admins’ or ‘none’
  • Google Auth
    • google_client_id and google_client_secret: parameters of the OAuth client for authentication through as identity provider. NOTE: despite the name recalling “google”, any OpenID provider (e.g.: GitHub) can be used.
  • SAML Auth
    • SAML Authentication is by default configured to use the INFN AAI provider; some required actions before and after deployment are specified in a disclaimer
  • Notification
    • mail_host: by default is set to the INFN mail server, which requires having an enabled account; otherwise you can use another suitably configured mail server

After submitting the deployment, the user is redirected to the deployment list:

../../../_images/deployment_list.png

Figure 3: User deployment list

If the creation of a deployment fails, an additional option (retry) is introduced in the dropdown menu, allowing the user to resubmit the deployment with the same parameters:

Deployment creation failed

Figure 4: Deployment creation failed

If the deletion of a deployment fails, resulting in the status being set to DELETE_FAILED, the “delete (force)” button is displayed in the list of available actions, allowing the user to force the deletion of the deployment:

Deplyment deletion failed

Figure 5: Deployment deletion failed

Below there is an example of the IAM login page after a successful deployment:

../../../_images/final_result.png

Figure 6: Example of an IAM login page