You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Registration and whitelisting flow, initial premises

  • Done in completely automatic fashion. 
  • SP needs to be listed in one of the metadata that SA is consuming, at the moment: eduGAIN, OpenAthens, SWAMID, InCommon
  • Technical and Administrative contact from the SP metadata are taken as contacts that SA is recognising
  • Advanced (and potentially Standard) implementors will need to register the API keys in order to call the persistence service API 
  • For API key registration domain ownership needs to be proved by inserting a defined record in their DNS? 
  • Once an API key is registered, there needs to be a process for renewal. It can be an automatic job, and the old key is left functioning if there is a job error. 
  • During the registration process, SPs need to accept the terms of use: 
    • Advanced - registration flow in the website, part of click-through, policed through API key registration process 
    • Standard - registration flow in the website, part of click-through, policed through API key registration process if mandatory for standard
    • Limited - registration flow in the website, part of click-through, no way to police


Option 1 -Registration of the SP and acceptance of ToS

  • Registration is done via seamlessaccess.org website. 
  • Person that wants to register SP, 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.
  • Person needs to choose one of the email addresses to prove s/he has access to it, and then clicks "send email"
  • Person 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
  • 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)
    • choose if it is advanced or standard integration
  • For advanced integration, there is an approval process as well as the implementation needs to be approved by the SA.
  •  After registration there is a log created - to be defined what information and in which format, and adding to the lists ? 


Option 1 - Registration of the API key

  • Need to check if SP exists in the log created in the registration flow in the website 
  • ... 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 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 2 -Registration of the SP and acceptance of ToS via entity category 

  • SP expresses its acceptance of ToS by adding entity category (which is TBD) to its metadata. Different EC are used for advanced and standard integration.
  • Seamless Access scans at the metadata periodically (hourly?) and records a list of SPs that has the entity category tag. Each SP seen to use this entity category, is recorded together with timestamp, noting all the changes (add/remove EC). This data is needed to be able to keep the history.
  • Every change is being notified by email to ? 
  • For the advanced integration, the SP needs also to contact the SA team to approve its implementation.  
  • SA team maintains a list of SP entityIDs that have been approved for advanced implementation.
  • Based 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. 

Option 2 - Registration of the API key

  • ... 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 has entity category set in SA metadata and for advanced also if it is in the list of the approved ones. 
  • 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. 
  • No labels