OpenAM - An Introduction
Download as PPTX, PDF33 likes40,510 views
The document outlines the agenda for the OpenAM for Beginners EMEA Summit 2013, covering topics such as the Forgerock stack, authentication, authorization, and federation. It highlights OpenAM's key functionalities, including single sign-on, centralized policy-based authentication, and support for various federation standards. The content is structured around classic user scenarios and the evolution of OpenAM versions over the years.
OpenAM - An Introduction
- 1. OpenAM for Beginners EMEA Summit 2013
- 2. Agenda ■ ForgeRock Stack overview ■ OpenAM Overview ■ Authentication ■ Authorization ■ Federation 2
- 5. Classic scenario I User wants to use an application... which does not require any of ForgeRock's products, but ... Application User 5
- 6. Classic scenario II Centralization of Authentication … and ... Application OpenDJ User 6
- 7. Classic scenario III Central Authorization OpenAM OpenDJ Application User 7
- 9. Classic scenario V Identity Management OpenAM Application HR DB OpenIDM OpenDJ User 9
- 11. OpenAM Vision and Scope External Parties PaaS Governments SaaS Authenti cate Perform ance JAAS SOAP & REST WSTrust High Availabi lity SSO Partners Outsourcing OpenAM OpenAM SAML External Parties XACML Entitle ments Suppliers OAuth In-house developed applications Federat e Cloud Commercial applications Authentication methods PKI RADIUS Directory Services 3rd party Data Bases Active Directory SecurID 11
- 12. OpenAM Evolution 2008 2009 2010 2011 OpenAM 9.0 2012 OpenAM 9.5 2013 OpenAM 10.0 OpenAM 10.1 OpenAM 11.0 One single product for AAA+Federation OpenSSO Build 7 OpenSSO Build 8 OpenSSO Build 6 OpenSSO Ent 8.0 Some Patch development but no new functionalities Open Source Closed Source 12
- 13. OpenAM Key Functionality Provides single sign-on to web resources and create a sign on once, access everywhere environment Centralized policy based authentication and authorization Enables policy enforcement Tracks all user authentication related events Extends access beyond organizational boundaries Authentication Authorization Single Sign-On Federation Entitlements Web Services Security Auditing/Logging Adaptive AuthN
- 14. Key: Single Sign On 14
- 16. Key: Partner Interaction and Integration 16
- 19. Authentication: Who are you? 19
- 21. Authentication: Where does the request come from? ■ Common use case: User requests access to a web page ■ Other Use Cases: Applications can request authentication programatically through REST or SOAP web services and OpenAM SDK 21
- 22. Authentication: Which Credentials? ■ OpenAM works with most authentication methods without customization ■ 21 out of the box Authentication modules ■ Custom modules can be created easily 22
- 24. Authorization 24
- 25. Authorization ■ Authentication is not enough ■ Authorization determines: – WHO can do – what ACTIONS – with what RESOURCES – under which CONDITIONS? ■ Uses Policies to define those rights 25
- 27. Federation 27
- 28. Federation ■ Federation is the process of linking identities across heterogeneous Access Management products ■ It is a trust relationship whereby a Service Provider (SP) trusts that an Identity Provider (IDP) has successfully authenticated a user ■ It is Standard Based 28
- 29. The Goals of Federation ■ Federation enables Single Sign On and Single Logout between partners ■ Federation allows rapid integration – during company acquisitions – between heterogeneous systems ■ Federation allows basic Identity Data Sharing ■ Helps to keep multiple internet accounts under control 29
- 30. Federation Standard Protocols OpenID Connect OAUTH 1.0 REST/JSON OAUTH 2.0 Liberty IDFF 1.1/1.2 Shibboleth 1.0/1.1 SAML 1.0 SAML 1.x Shibboleth 2 (SAML2) SAML 2.0 OpenAM ADFS2 WSFederation 1.0 SOAP 2002 WSFederation 1.1 ADFS Today 30
- 32. OpenAM Federation ■ OpenAM provides first class federation support ■ Federation Protocol support – SAML2, WS-Federation, ID-FF, OAuth2 ■ Federated Web Services ■ Multi-Protocol Hub – Allows OpenAM to act as a broker between different federation protocols ■ Plug-in points allow for easy customization ■ Fedlet for applications that do not support standard protocols 32
Editor's Notes
- #32: IN this slide the notes – and the instructor – will insist on some basic and unified concept, where one chosen server is used to keep the federated information and issue tokens following user authentication. Relying parties (service provider/resource servers) can consume those tokens to give access to some resources. Trust relationship must exist between the “Assertion provider” and the relying parties; relying parties are ot directly linked/trusting each other; we usually speak of assertion for saml2 (for WS-federation, the assertion is wrapped in what then becomes a token) and token for oauth2;