TECHNICAL CASE STUDY: STORK
Download as PPTX, PDF2 likes766 views
This technical case study discusses SAML federations and the STORK project. SAML federations provide single sign-on for web applications using identity providers and service providers. The STORK project established an interoperability platform for electronic identities across Europe. The presentation includes terminology, basic SAML setup and flow, and an IdP proxy setup. It concludes with a demonstration of STORK.
TECHNICAL CASE STUDY: STORK
- 1. Technical Case Study: STORK IRM Summit 2014
- 2. âč#âș IRM Summit 2014 About me â Working with OpenSSO/OpenAM since 2009 â Support/Sustaining Engineer at ForgeRock since 2011 â Contact â @majorpetya â peter.major@forgerock.com â http://blogs.forgerock.org/petermajor â https://github.com/aldaris/
- 3. SAML Federations â Provides a standardized solution for web browser âč#âș IRM Summit 2014 single sign on â Introduces the concept of federated identities â Widely used
- 4. Terminology â Identity Provider (IdP): the authoritative source of âč#âș IRM Summit 2014 identity data â Service Provider (SP): content provider â Assertion: a set of information about the logged in user
- 5. Basic SAML setup âč#âș IRM Summit 2014
- 6. Basic SAML flow âč#âș IRM Summit 2014
- 7. Basic SAML setup âč#âș IRM Summit 2014
- 8. IdP Proxy setup âč#âș IRM Summit 2014
- 9. âč#âș IRM Summit 2014
- 10. âč#âș IRM Summit 2014 STORK â Secure idenTity acrOss boRders linKed â European eID Interoperability Platform â Establish e-relations across borders
- 11. âč#âș IRM Summit 2014 STORK
- 12. âč#âș IRM Summit 2014 STORK
- 13. âč#âș IRM Summit 2014 STORK
- 14. âč#âș IRM Summit 2014 STORK
- 15. âč#âș IRM Summit 2014 Demo
- 16. âč#âș IRM Summit 2014 Questions?
Editor's Notes
- #4: Mention CDSSO Example for federation: OpenAM and SalesForce
- #5: IdP provides the identity data SP performs authorization based on the received identity information
- #6: usually one Identity Provider and several Service Provider applications
- #7: signing/encryption The SP needs to trust the IdP The SP performs its authorization checks once the assertion is received
- #8: So this was the simple setup, letâs see what is the main difference between this and the IdP Proxy use-case
- #9: Provides the capability to have more than one Identity Provider Gives an abstraction layer between the SP and the IdPs, the SPs only have to trust the IdP Proxy! IdP proxy is both IdP and SP
- #10: IdP selection at IdP Proxy IdP Proxy issues new Authentication Request and an Assertion, because the IdP Proxy is both an SP and the IdP
- #16: Adaptable: it allows you to dynamically choose the IdP Borderless: we just removed the border in the STORK project and allow new participants in the deployment with ease