SaToSa <-> Stepup GW needs both persistent SAML NameID AND ePTID
Stepup GW <-> Stepup Portal ONLY needs persistent SAML NameID
Stepup WGGW expects ePTID, CN, mail, persistent SAML NameID, SHO and persistent SAML NameID and ePTID must have the same value
SaToSa must deliver the persistent SAML NameID AND ePTID containing the community identifier

Pilot platform setup and components

Configuration repo for the pilot platform: https://dev.niif.hu/vopaas/stepup-config-dev-mfa-eduteams-org
VM for stepup: dev.mfa.eduteams.org (from: deploy.test.eduteams.org, ssh -A centos@dev.mfa.eduteams.org)
Deployment is done from deploy.test.eduteams.org:/home/debian/stepup-pilot/stepup-config-dev-mfa-eduteams-org using the default methods provided by stepup components (https://github.com/OpenConext/Stepup-Deploy)
According to the eduTEAMS environment, stepup is working together a satosa instance (as you can see in the flowlist above). For the pilot stepup is connected to the lsaai-test satosa instance: welcome.ls-aai.eduteams.org (it runs on lsaai-1.eduteams.org VM). Metadata source and discovery service for this satosa instance is https://mdx.ls-aai.eduteams.org/ which is a pyff runs in lsaai-4.eduteams.org VM. There is an SSP instance outside from the eduTEAMS infrastructure (idp.test.eduid.hu) I used for testing purposes (both as IdP and as SP) with static users, I added the static metadata of this instance to the pyff's static folder, you can do it with your own test IdP as well, or I can generate some additional dummy users if I get valid emailaddress(es). (sitya)
If you want to try stepup from other IdPs, your schacHomeorganization value has to be added to the stepup whitelist in its config.

Selfregister Portal

Note: in the pilot environment now only Yubikey is configured as potential second factor tool.

If you want to add new administrator, you have to configure under deploy.test.eduteams.org:/home/debian/stepup-pilot/stepup-config-dev-mfa-eduteams-org then run the related deployment scripts.Portal