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

Compare with Current View Page History

« Previous Version 5 Next »

This document describes pro's and con's for having a test IdP in eduGAIN.
(the sequence does not in any way suggest weight or order)

Test IdP IN eduGAIN

Pro
Con
  • If the SP is not in eduGAIN, then support for the SP is unlikely to be provided through the eduGAIN support team or national federations. It must be provided by the test IdP service, and a central service like that is not guaranteed to know the details about any future federation that the SP will join.

  • Support framework for a testIdP service has not yet been established
  • Should eduGAIN be concerned with national level requirements?
  • Do federations currently understand (or care) about retirements from other federations?
  • How likely is it requirement s from new federations will (be able to) deviate very much from what is best current practice in eduGAIN? (as that would adversely influence inter-op with eduGAIN)
  • Allows for testing with currently registered SPs

  • MUST have technical measures to prevent unintentional usage to login to SPs, but we should not take responsibility of it goes wrong
  • Any SP already in eduGAIN will likely be able to import metadata from a separate test IdP anyway
  • Testing new attribute requirements on a production SP is probably not a good idea, best practice is too have dev/qa platforms for that, who may or may not be in eduGAIN
  • An SP registered in eduGAIN has gone through metadata checks (well-formed, validation, sense-checking). The test IdP would have to duplicate many processes that the federations and eduGAIN already perform.
  • And note that the UK federation has occasionally had SPs join which can't generate metadata and we have helped them construct it.

  • We initially build on SAML metadata as the bootstrapping of the test Idp relation with the SP.
  • If we mandate the test IdP should also work without being in eduGAIN, the testIdP must already support metadata checks (well-formed, validation, sense-checking) anyway, though perhaps not to the extend as is done by a national federation.
  • We should test on eduGAIN metadata requirements, which should be acceptable for any national federation (as that is just what they already get from eduGAIN itself ). Additional national metadata requirements are considered out of scope.
  • We are considering assisting the SP with metadata creation in support of SP products that do not or not full support eduGAIN meatdata requirements
  • If the SP is only integrated through eduGAIN, then it can use a single, well-defined metadata ingest process. Otherwise, you require the test IdP service team to make the metadata integrations; and the SP may end up with two distinct metadata ingest mechanisms (bilateral with the test IdP, multilateral with local federation or eduGAIN)


  • Registering with a federation provides good support for entity categories - can we expect SPs to annotate their own metadata appropriately?

  • This is only only relevant for R&S (I think). In a test environment we might accept R&S as issued by the SP as we are not really ibtrested in the trust aspect of R&S, but just in the ability to exchange attributes in a technically correct way









  • No labels