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

Compare with Current View Page History

« Previous Version 2 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
  • 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 te test Idp relation with the SP.
  • If we mandate the test IdP shoudl also work without being in eduGAIN, the testIdP must already support metadata checks (well-formed, validation, sense-checking) anyway, though prhaps not to the extend as is done by a national federation.
  • 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)














  • No labels