Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This is the process we will start with, as eventual method for Option 3 that is fully made more automatic and needs some amount of coding in both front and back end. It This process assumes that there is a semi-manual registration process that SP owner and SA team need to follow.

  • SP owner sends email from the admin or technical contact published in its metadata. Email needs to state: 
    • The integration SP wishes to use: Limited/Standard/Advanced
    • Acceptance of the ToS
    • Whether SP opts-in to be published in SA website as using the SA
    • Whether SP wishes to be added to the SA communication channels - Slack SA general channel, the users mailing list, SA status notification... 
  • Which email and who is looking to that and on which schedule ? What is the response time we want to establish for this? For the sake of this process, lets call this the job of the Level 1 support. 
  • L1 support records the registration, that includes: 
    • Record the request in Airtable or something alike
    • Do we want them to prove they own the domain?  or is it enough of they send request from official email
    • If the requested integration is advanced, then the request is forwarded to the SA xx team. Wait until the SA xx team has approved the integration and then continue...Update the Airtable
    • Record the integration in the website, if opted in (can we use airtable automatically for this?)
    • Add them to the communication channels if opted-in

...

  • ... TO BE DESCRIBED BY LEIF
  • SP admin uses curl call that is described in documentation. Shibboleth SP key is used to sign a message that is then sent to the API server.
  • API server checks if the SP is registered by checking a list of the entity-IDs that is prepared based on the Airtable (check if this is possible) ?  
  • API server responds with JSON and key ?
  • SP should place the key in the environment variable or in the file - documentation for this to be provided. 

Option 3 (eventual process) -Registration of the SP and acceptance of ToS

This is eventual method for Option 3 that is as automatic as possible. It assumes that there is a UI registration process for the SP owner. The SP owner needs to prove the control over the entity and the SA site marks this in metadata that is being aggregated by SA. 

  • Person that wants to register SP, needs to do the registration over the SA website, that looks something like this: 
    • he chooses SP from the list which is being populated from metadata SA is consuming
    • UI presents the email addresses of the administrative/technical contacts that are registered with that SPs metadata.
    • he needs to choose one of the email addresses to prove s/he has access to it, and then clicks "send email"
    • he receives email with a link containing a long string. Click on that link takes s/he to the SP specific registration page on seamlessacccess.org
    • (instead of everything above, we can have login, but I am not sure whether person that administers SP also has and an IdP to login with)
    • This page shows some of the data about the SP that is parsed from the metadata, with message to correct this data through SPs published metadata if needed. 
    • There are checkboxes to :
      • accept ToU (mandatory)
      • choose which SP contact email to add to the users mail list (optional)
      • choose which SP contact email to add to status notifications (?) (optional)
      • opt-in to being listed in the SA site as one of the users
      • choose if it is limited, advanced or standard integration
    • For advanced integration, there is an approval process as well as the implementation needs to be approved by the SA xx team.
    •  After registration there is a log created - to be defined what information and in which format, and adding to the lists ? 
    • Limited and Standard integrations gets immediately added to an internal list, and Advanced after approval (can we do it over UI as well?). This list need only to contain entityID of the SP. 
    • Based on this list, and EC is added to the SA metadata. 
  • Based on SA metadata, we can have an internal and external view on who are SPs that use SA. 
    • internal view would be for the use by the SA team and would have basic info about SP,  contacts from metadata and which integration they use
    • external for start number of SPs using advanced and standard. 

...