Portal Setup: Onboarding - indiana-university/kumo GitHub Wiki

This document provides a checklist and guidance for configuring DNS, SSL certificates, and federated access for the Kumo web portal. This document is intended for system administrators and/or technical implementers of Kumo at your institution.

Checklist

DNS

  • Secure Kumo domain for your institution
  • Create CNAME record pointing your Kumo domain to cloudstorage.iu.edu

SSL Certificates

  • Procure Server Authentication SSL certificate for your Kumo domain
  • Send SSL certificate details to your Kumo service contact at Indiana University
  • Secure unique domain name for each Accesss Broker (min: 1, recommended: 2)
  • Secure Client + Server Authentication SSL certificate for each Access Broker. The certificate subject name must correspond to the Access Broker domain name (no wildcard certificates.)

Federated Authentication

  • Configure federation trust between your IdP and Kumo’s SP.
  • Configure your IdP to release Email and User Principal Name (UPN) attributes
  • Send your federation details to your Kumo service contact at Indiana University

DNS

The web portal for the Kumo service will be accessed using a URL that is within your institutions domain and must conform to the following naming convention: kumo.[your institution’s domain] (example: kumo.iu.edu). To accomplish this a new CNAME record must be created in your institution’s DNS service to make your Kumo service URL an alias of cloudstorage.iu.edu. For example, the following should be created:

kumo.yourschool.edu CNAME cloudstorage.iu.edu

Consult your DNS system documentation for instructions on adding CNAME records.

SSL Certificates

SSL certificates are required to allow secure communication between all components of Kumo, including the web portal, access brokers, clients, and end users. To ensure a strong level of data encryption, all SSL certificates must use no less than a 2048 bit RSA encryption key and be issued by a globally trusted third party certificate authority such as InCommon or DigiCert (local domain CA’s will not be sufficient).

Portal Certificate

You will need procure one Server Authentication SSL certificate for your institution’s Kumo domain. In order to make the certificate available on the hosted Portal, you must provide your Kumo service contact at Indiana University with a .PFX file that includes both the public and private keys for this certificate. Your service contact will work out the details with you about a secure method of transferring the .PFX and private key password.

Portal Certificate Requirements:

  • Must be signed by a Trusted Root CA (e.g. InCommon)
  • Must be valid for Server Authentication

Access Broker Certificate

Each Kumo Access Broker must be secured with a Client + Server Authentication SSL certificate. The Client Authentication attribute is used to facilitate Mutual Certificate Authentication between the Access Broker and Portal web services. The Server Authentication attribute secures communication between the Access Broker and Kumo Client.

Access Broker Certificate Requirements:

  • Must be signed by a Trusted Root CA (e.g. InCommon)
  • Must be valid for Client Authentication + Server Authentication,
  • Must have a Subject Name that is the same as the FQDN of the VM host on which the Access Broker service will run. (It cannot be a wildcard certificate.)
  • Must be imported to the Local Machine / Personal (My) certificate store.

Federated Authentication

Federated authentication allows your users to securely log in to the Kumo portal using your institution’s login/SSO service. You may need to consult your institution’s Identity Provider (IdP) documentation in order to complete some of these tasks.

  1. Configure a federation trust between your IdP and the Kumo Service Provider (SP). Metadata for the Kumo SP can be found at https://slfed.uits.iu.edu/FederationMetadata/2007-06/FederationMetadata.xml
  2. Configure your IdP to release the following attributes to the Kumo SP
  • Email (Single-value): Only provide the user’s primary/preferred email address.
  • User Principal Name (UPN) (Single-value): Due to how the Kumo service utilizes a locally hosted Access Broker to perform Windows based authentication, the UPN you send to the Kumo SP must be the same value that is assigned to the user’s ‘userPrincipalName’ attribute in your Active Directory domain. If your institution participates in InCommon federation, then this UPN value may be different than the UPN your institution has registered with InCommon (eduPersonPrincipalName). For example, your institution may use [email protected] for eduPersonPrincipalName but the userPrincipalName attribute in Active Directory may be [email protected]; we require the latter to be sent to us.
  1. Send the following information to your Kumo service contact at Indiana University: