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.
Presentation introduces OpenAM at EMEA Summit 2013 and outlines the agenda including ForgeRock stack overview, OpenAM overview, and topics like authentication, authorization, and federation.
Overview of the ForgeRock Stack and its foundational pillars related to Identity and Access Management (IAM).
Five classic user scenarios demonstrating OpenAM usage, including application access without ForgeRock, authentication centralization, central authorization, federation, and identity management.
Overview of OpenAM features, vision, scope, and its historical developments from 2008 to 2013 including transition from OpenSSO to OpenAM as an AAA+Federation solution.
Key functionalities of OpenAM such as single sign-on, centralized policy-based authentication and authorization, policy enforcement, and user event tracking.
Detailed discussion on authentication processes including user identity verification, available authentication methods, credential types, and common use cases.
Explanation of authorization principles and processes, emphasizing the need for policies defining effective access rights.
In-depth look at federation processes, goals, standard protocols, terminology, and how OpenAM facilitates federation via multi-protocol support.
Introduction to Forgerock University, possibly indicating training or educational resources related to the ForgeRock suite.
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
Authentication:
Where does therequest 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?
■
OpenAMworks with most authentication methods without
customization
■
21 out of the box Authentication modules
■
Custom modules can be created easily
22
Authorization
■
Authentication is notenough
■
Authorization determines:
– WHO can do
– what ACTIONS
– with what RESOURCES
– under which CONDITIONS?
■
Uses Policies to define those rights
25
Federation
■
Federation is theprocess 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 ofFederation
■
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
OpenAM Federation
■
OpenAM providesfirst 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
#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;