OpenAM for Beginners
EMEA Summit 2013
Agenda
■

ForgeRock Stack overview

■

OpenAM Overview

■

Authentication

■

Authorization

■

Federation

2
ForgeRock Stack Overview

3
Pillars of IAM

4
Classic scenario I
User wants to use an application...
which does not require any of ForgeRock's
products, but ...

Application

User

5
Classic scenario II
Centralization of Authentication
… and ...
Application

OpenDJ

User

6
Classic scenario III
Central Authorization

OpenAM

OpenDJ

Application

User

7
Classic scenario IV
Federation

Application

OpenAM

OpenAM

OpenDJ

Application

OpenDJ
User
8
Classic scenario V
Identity Management

OpenAM

Application

HR DB

OpenIDM

OpenDJ

User

9
OpenAM Overview

10
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
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
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
Key: Single Sign On

14
Key: Protecting Resources

15
Key: Partner Interaction and Integration

16
OpenAM Integration Paths

17
Authentication

18
Authentication: Who are you?

19
Authentication Flow

20
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
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
Authentication: ID Token

23
Authorization

24
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
Authorization Flow

26
Federation

27
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
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
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
Federation Terminology

31
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
Forgerock University

33

OpenAM - An Introduction

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;