South African Identity Federation
The technical roadmap for the South African Identity Federation, focusing on AS2018 status, separate servers for hub and metadata, pros and cons of hub and spoke federation, VMware vSphere deployment, BGP implementation, and more.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
South African Identity Federation Draft Technical Roadmap July 2016 2016/07/12
AS2018 Status quo as at July 2016 SCA mesh federation Mesh federation; no hub; no consent; no metadata signing www.safire.ac.za PHP, WordPress discservice.sanren.ac.za PHP, SSP Cannot join eduGAIN without developing metadata practice statement and signing metadata 2
AS2018 Separate servers for hub & metadata improves security; facilitates growth Phase 1 initial deployment This is the only bit end users generally see and then maybe not (proxy endpoints) web-cpt-01.safire.ac.za www.safire.ac.za consentadmin.safire.ac.za testsp.safire.ac.za PHP, SSP, WordPress md-cpt-01.safire.ac.za metadata.safire.ac.za phph.safire.ac.za PHP, PHPH, SoftHSM hub-cpt-01.safire.ac.za discovery.safire.ac.za proxy.safire.ac.za PHP, SSP, goEleven, SoftHSM, BIRK Policy and practice statement development must happen in parallel All stored data here (eases restore after disaster) db-cpt-01.safire.ac.za syslog.safire.ac.za MySQL, rsyslogd 3
Pros Cons Fully functional hub & spoke federation No redundancy No resiliency (ESXi) Assuming admin requirements, can join eduGAIN Geographically all in Cape Town Phase 1 initial deployment Crypto keys on disk Complete separation of hub & metadata handling functionality All data / logs stored centrally 4
Deploy VMware vSphere enterprise, with vSAN + HA Or an equivalent platform Gets us protection from hardware failure, and ability to do maintenance on VM layer without impacting service Phase 1.5 hardware resiliency No real dependencies on SAFIRE can happen at any point during deployment. 5
Use BGP to announce the same address space from CPT and JNB, using AS prepends to prefer CPT Because of caching, loss of metadata is non-service-affecting for about a day AS2018 haproxy-cpt-01.safire.ac.za discovery.safire.ac.za proxy.safire.ac.za metadata.safire.ac.za haproxy, bird haproxy-jnb-01.safire.ac.za discovery.safire.ac.za proxy.safire.ac.za metadata.safire.ac.za haproxy, bird Phase 2 introduce redundancy web-cpt-01.safire.ac.za www.safire.ac.za consentadmin.safire.ac.za testsp.safire.ac.za PHP, SSP, WordPress md-cpt-01.safire.ac.za metadata.safire.ac.za phph.safire.ac.za PHP, PHPH, SoftHSM hub-cpt-01.safire.ac.za discovery.safire.ac.za proxy.safire.ac.za PHP, SSP, goEleven, SoftHSM, BIRK hub-jnb-01.safire.ac.za discovery.safire.ac.za proxy.safire.ac.za PHP, SSP, goEleven, SoftHSM, BIRK Failure of this element means loss of syslog and consent database. Users must (re-)consent for every login irritating, but not service affecting Use haproxy to load balance between active nodes, setting a cookie to ensure session integrity db-cpt-01.safire.ac.za syslog.safire.ac.za MySQL, rsyslogd 6
Pros Cons Redundant hub and BIRK proxy endpoints these are the bits people will notice if broken No redundancy for metadata or web but are these necessary? Not unless load is a problem. Phase 2 introduce redundancy Geographically dispersed No redundancy for DB, but understood failure mode Replication of the database might affect performance. High availability through failover Scalable architecture add more nodes if we need to Crypto keys still on disk 7
AS2018 haproxy-cpt-01.safire.ac.za discovery.safire.ac.za proxy.safire.ac.za metadata.safire.ac.za haproxy, bird haproxy-jnb-01.safire.ac.za discovery.safire.ac.za proxy.safire.ac.za metadata.safire.ac.za haproxy, bird Phase 3 introduce HSM web-cpt-01.safire.ac.za www.safire.ac.za consentadmin.safire.ac.za testsp.safire.ac.za PHP, SSP, WordPress md-cpt-01.safire.ac.za metadata.safire.ac.za phph.safire.ac.za PHP, PHPH, SoftHSM hub-cpt-01.safire.ac.za discovery.safire.ac.za proxy.safire.ac.za PHP, SSP, goEleven, SoftHSM, BIRK hub-jnb-01.safire.ac.za discovery.safire.ac.za proxy.safire.ac.za PHP, SSP, goEleven, SoftHSM, BIRK Initially perhaps something akin to a Raspberry Pi + smartcard based HSM. Fast enough for metadata signing, but not SAML hsm-cpt-01.safire.ac.za goEleven, PKCS#11 db-cpt-01.safire.ac.za syslog.safire.ac.za MySQL, rsyslogd 8
Pros Cons Will need to perform key rollover for metadata key Smartcard based HSMs come with failure/backup concerns Have multiple offline cards Metadata signing key protected this is the crucial key, because is the hardest to roll over Phase 3 introduce HSM SAML assertion signing key still on disk Can be rolled over in metadata within 24 hours Web server key still on disk Can be revoked by CA This is what the rest of the world expects of a production federation. Single point for failure for logging, no escrow 9
Self-service metadata management Monitoring Statistics Log escrow (remote syslog) Elements that are missing from the roadmap Hardware Security Module + operational practices 10
