...
- 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
Which entity categories we need:
- ToS - assert accept from from incoming feeds and also assert ourselfes as part of pixiedusting - think also about accepting it from
2. Authorisation for using the advanced (they need to read and write to)
Filtering ideas:
- have a special or vanity URL that has special fitelring configured .... (do they need to have a separate )
- this may become
Option 3 (start process) -Registration of the SP and acceptance of ToS
...
- 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
- entityID of the SP they wish to register
- Acceptance of the ToS
- (Whether SP opts-in to be published in SA website as using the SA) - we can just require this but needs to be added to ToS-we also want to publish this to metadata
- Whether SP wishes to be added to the SA communication channels - Slack SA general channel, the users mailing list, SA status notification...
- ??? some form for populating airtable - populate table from some kind of web form ..and how to extract information. ..also if there are any risks with using airtable without payed licence
- 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 alikeDo we want them to prove they own the domain? or is it enough of they send request from official email
- L1 support checks if the SP is published in any of the metadata that SA consumes
- 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
- SA xx team validates that advanced integration is approved: proof that they are following ToS, UX validation
- 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) ? - use api to fetch data from airtable and pixiedust the MD
- 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.
...