Munich CF Meet up: Authentication and Authorization for a microservices World

© 2016 ForgeRock. All rights reserved.

AUTHENTICATION & AUTHORIZATION ARCHITECTURE FOR A µSERVICES WORLD

FORGEROCK AND CLOUDFOUNDRY

MUNICH MEETUP

1

V Í C T O R A K ÉC O - F O U N D E R & V P C U S T O M E R I N N O V A T I O NF O R G E R O C Kv i c t o r . a k e @ f o r g e r o c k . c o m


FORGEROCK IS THE LEADING, NEXT-GENERATION, IDENTITY SOFTWARE PLATFORM

FOUNDED IN 2010 IN NORWAY

OVER HALF BILLION IDENTITIES ENABLED

ACTIVE IN OVER 30 COUNTRIES

OFFICES IN 8 COUNTRIES

IDENTITY AS AN ENABLER FOR GROWING

VCS: ACCEL PARTNERS, FOUNDATION CAPITAL, MERITECH CAPITAL


RISE OF THE MICROSERVICES!

* DIVIDE AND CONQUER

*


IDENTITY & Access Management CHALLENGESSTILL PRESENT

IN MICROSERVICES ARCHITECTURES


ATTACK Surface bigger than in monolithic

Complexity increases

The days of perimeter security are gone

PRIVACY and consent


STILL THE NEED TO PROTECT!USER, DEVICES, THINGS & MICROSERVICES

With privacy and consent in mind


THE IDENTITY LAYERS

WHO OR WHAT LAYERAPP/API CONSUMERS(BROWSER, REST)

SERVICE(API, MYSQL, REDIS, FORGEROCK)

PLATFORM(CF PUSH, DEVMGR)

SYSTEM(OPSMGR, BOSH, SSH)

USERS DEVICES THINGS APPLICATIONS SERVICES

DEVELOPERS

OPERATORS

SERVICES EXTERNAL SERVICES


Microservices

Pivotal Cloud Foundry


MICROSERVICE TIERS – AN IDENTITY VIEW

TIER-2-SERVICE

EXPOSED EXTERNAL AND INTERNALCONSUMER AND SERVICE IDENTITIESHIGH LEVEL OF SECURITY

INTERNALCONSUMER AND SERVICE IDENTITIES

INTERNALSERVICE IDENTITIES ONLY

TIER-1-SERVICE

TIER-2-SERVICE

TIER-1-SERVICE

TIER-3-SERVICE TIER-3-SERVICE


µSvc2

How to protect Microservices

Req Svc2

µSvc1 µSvc3

Req Svc3

Each µService must be protected and provide the service only to other µServices that are authorized.

We all know that to Authorize we need Authentication first

Req Svc1


“You see, in this world there's two kinds of APIs, my friend: Those that are lightweight and those that make you dig”


µSvc2µSvc1 µSvc3Req (user Token)

Req (µSvc1 Token) Req (µSvc2 Token)

Each ENTITY must present a VALID TOKEN with every request to A µservice. When the token expires, the ENTITY should get a new one.

TOKENS, TOKENS, TOKENS


µSvc1TOKEN ISSUER

Service

Request a Token (Credentials)

Provide a Token

Identity/Credentials

Store

TOKEN ISSUER Service for µServices

ValidateCredentials


IF I AM Implementing a µservice, how IS A TOKEN VALIDATED?

DEPENDS ON THE TOKEN TYPE


µSvc2Validate(µSvc1 Token)

ValidatiNG TOKEN for µServices

Req Svc2 (µSvc1 Token)

µSvc1


µSvc2Token Validation

SERVICE

Validate(µSvc1Token)

Valid (DECODED)/Expired/Invalid

Validation Service for µServices


µSvc1


Now that the service has a a token, Authorization is possible as well


µSvc2Validate & Authorize (µSvc1 Token)

Authorization TOKEN for µServices


µSvc1


µSvc2Token Validation

SERVICE

Validate(µSvc1Token)

Valid (DECODED)/Expired/Invalid

AUTHORIZATION Service for µServices


µSvc1

AUTHORIZATIONSERVICE

Authorization(µSvc1 Token)


µSvc1AUTHORIZATION

SERVICEAuthorized + Permissions

Authorization Service for µServices

AuthZ Req (Caller Svc Token) Cache

Token ValidationSERVICE


WHAT KIND OF TOKENS ARE WE talking abouT?

WHAT PROTOCOL SHALL BE USED TO OBTAIN A TOKEN?

WHAT KIND OF AUTHORIZATION IS POSSIBLE?


OPAQUE TOKEN

TRANSPARENT TOKEN

Type OF TOkens“there Are two kinds of tokens in the world, my friend: Those THAT SHOW you nothing, and those you can introspect”


OPAQUE TOKENBY REFERENCE, ALSO KNOWN AS STATEFULL TOKENMEANINGLESS CONTENT/VALUETYPYCALLY A RANDOM STRINGRequires a central SERVICE

{ "expires_in": 599, "token_type": "Bearer","refresh_token": "f6dcf133-f00b-4943-a8d4-ee939fc1bf29","access_token": "f9063e26-3a29-41ec-86de-1d0d68aa85e9"

}

EXAMPLE:


TRANSPARENT TOKENBY VALUE, ALSO KNOWN AS STATELESS TOKENMEANINGFUL CONTENT/VALUETYPYCALLY A JSON WEB TOKEN (JWT)NO CENTRAL SERVICE REQUIRED

{ "access_token":

"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiMTIzNDUiLCJzaG9ydG5hbWUiOiJtaWNyb3NlcnZpY2UiLCJpYXQiOjE0NzU3NzI0MDYsIm5iZiI6MTQ3NTc3MjQwNiwiZXhwIjoxNDc1NzcyNzA2LCJhdWQiOlsiMTIzNDUiLCJodHRwczovL21zYWEuaWRlbnRpdHl3cmVzdGxlci5jb206MzAwMC92MS92YWxpZGF0ZSIsIiBodHRwczovL21zYWEuaWRlbnRpdHl3cmVzdGxlci5jb206MzAwMC92MS9hdXRob3JpemUiXSwiaXNzIjoiaHR0cHM6Ly90b2tlbnByb3ZpZGVyLmZvcmdlcm9jay5vcmciLCJzdWIiOiIxMjM0NSJ9.Gz2hTOa7gv4Cep2h71-_eT1qcI_2KbSeA0VQmdBwH6o", "issued_token_type": "urn:ietf:params:oauth:token-type:jwt","token_type": "Bearer","expires_in": 300

}

EXAMPLE:


JWT

STANDARD PROTOCOLS And Formats


OAuth 2.0§ DELEGATED Authorization framework § ENABLES A 3RD PARTY TO OBTAIN LIMITED ACCESS

TO A SERVICE/RESOURCE ON BEHALF OF A RESOURCE OWNER

There are several flows and grants to choose from


OAuth 2.0 FLOWSFLOW Typical Use TYPICAL USE

Authorization Code User allows a 3rd Party to access a resource owned by the user

Web App

Implicit Grant User allows a 3rd Party to access a resource owned by the user

Web App

Resource OwnerPassword

Resource Owner trusts the client with its credentials Mobile APP

Client Credentials The Client owns or wants direct access to resources Services/Things


OAUTH 2.0 – BEARER TOKEN§ ANY PARTY IN POSSESSION OF A BEARER TOKEN CAN USE IT

TO GET ACCESS TO THE ASSOCIATED RESOURCES§ TO PREVENT MISUSE, BEARER TOKENS NEED TO BE

PROTECTED FROM DISCLOSURE IN STORAGE AND IN TRANSPORT


OPENID CONNECT (OIDC)§ A SIMPLE IDENTITY LAYER ON TOP OF OAUTH 2.0§ ENABLES CLIENTS TO VERIFY THE IDENTITY OF THE END-

USER§ OBTAIN BASIC PROFILE INFORMATION ABOUT THE END-USER

IN AN INTEROPERABLE AND REST-LIKE MANNER


JSON WEB TOKEN (JWT)A MEANS OF REPRESENTING CLAIMS TO BE TRANSFERRED BETWEEN TWO PARTIES. THE CLAIMS IN A JWT ARE ENCODED AS A JSON OBJECT THAT IS DIGITALLY SIGNED USING JSON WEB SIGNATURE (JWS) AND/OR ENCRYPTED USING JSON WEB ENCRYPTION (JWE).

JWS: JSON Web SignatureJWE: JSON WEB ENCRYPTION

JWA: JSON Web ALGORITHMJWK: JSON WEB KWY


JSON WEB TOKEN (JWT)

"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiMTIzNDUiLCJzaG9ydG5hbWUiOiJtaWNyb3NlcnZpY2UiLCJpYXQiOjE0NzU3NzI0MDYsIm5iZiI6MTQ3NTc3MjQwNiwiZXhwIjoxNDc1NzcyNzA2LCJhdWQiOlsiMTIzNDUiLCJodHRwczovL21zYWEuaWRlbnRpdHl3cmVzdGxlci5jb206MzAwMC92MS92YWxpZGF0ZSIsIiBodHRwczovL21zYWEuaWRlbnRpdHl3cmVzdGxlci5jb206MzAwMC92MS9hdXRob3JpemUiXSwiaXNzIjoiaHR0cHM6Ly90b2tlbnByb3ZpZGVyLmZvcmdlcm9jay5vcmciLCJzdWIiOiIxMjM0NSJ9.Gz2hTOa7gv4Cep2h71-_eT1qcI_2KbSeA0VQmdBwH6o",


"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiMTIzNDUiLCJzaG9ydG5hbWUiOiJtaWNyb3NlcnZpY2UiLCJpYXQiOjE0NzU3NzI0MDYsIm5iZiI6MTQ3NTc3MjQwNiwiZXhwIjoxNDc1NzcyNzA2LCJhdWQiOlsiMTIzNDUiLCJodHRwczovL21zYWEuaWRlbnRpdHl3cmVzdGxlci5jb206MzAwMC92MS92YWxpZGF0ZSIsIiBodHRwczovL21zYWEuaWRlbnRpdHl3cmVzdGxlci5jb206MzAwMC92MS9hdXRob3JpemUiXSwiaXNzIjoiaHR0cHM6Ly90b2tlbnByb3ZpZGVyLmZvcmdlcm9jay5vcmciLCJzdWIiOiIxMjM0NSJ9.Gz2hTOa7gv4Cep2h71-_eT1qcI_2KbSeA0VQmdBwH6o",

{ "alg": "HS256", "typ": "JWT"}

{ ”sub": “12345”,"shortname": "microservice","iat": 1475772406,"nbf": 1475772406,"exp": 1475772706,"aud": [ “12345”,"https://m.forgerock.com/authn”,

“https://m.forgerock.com/authz”, “https://m.forgerock.com/tokexch”],"iss": “https://m.forgerock.com”,"name": “12345”

}

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

JSON WEB TOKEN (JWT)


ACCESS TOKEN

Refresh TOKEN

ID Token

Oauth 2.0 & OIDC Tokens


Oauth 2.0 Tokens{ "expires_in": 599, "token_type": "Bearer","refresh_token": "f6dcf133-f00b-4943-a8d4-ee939fc1bf29","access_token": "f9063e26-3a29-41ec-86de-1d0d68aa85e9”,“scope”: “scope1”

}

{ "expires_in": 599, "token_type": "Bearer","refresh_token": "

eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAic3ViIjogImRlbW8iLCAiYXVkaXRUcmFja2luZ0lkIjogImQ5ZmYzMGYwLTUxM2ItNDgwMS05ZmNlLTFhYzZlNGFiMTNmMyIsICJpc3MiOiAiaHR0cDovL2thanZtLmV4YW1wbGUuY29tOjgwODAvb3BlbmFtL29hdXRoMiIsICJ0b2tlbk5hbWUiOiAicmVmcmVzaF90b2tlbiIsICJhdXRoTW9kdWxlcyI6ICJEYXRhU3RvcmUiLCAidG9rZW5fdHlwZSI6ICJCZWFyZXIiLCAiYXV0aEdyYW50SWQiOiAiNTgyOGQ4NzMtZTg2Yy00YmFiLTllNDAtOTAwMWRiOWFjNjJkIiwgImF1ZCI6ICJjbGllbnQiLCAibmJmIjogMTQ2NzczNTc2NywgInNjb3BlIjogWyAic2NvcGUiIF0sICJyZWFsbSI6ICIvIiwgImV4cCI6IDE0NjgzNDA1NjcsICJpYXQiOiAxNDY3NzM1NzY3LCAiZXhwaXJlc19pbiI6IDYwNDgwMDAwMCwgImp0aSI6ICI0OWMyMzhkNC1jNmY5LTQzMzMtYTZiMC04YzEzMjNlNGU0MTIiIH0.5TQnJQXqIpW_bG6jbqDX9VdulJByNZmPTvOmI1Ui6c8","access_token":

"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiMTIzNDUiLCJzaG9ydG5hbWUiOiJtaWNyb3NlcnZpY2UiLCJpYXQiOjE0NzU3NzI0MDYsIm5iZiI6MTQ3NTc3MjQwNiwiZXhwIjoxNDc1NzcyNzA2LCJhdWQiOlsiMTIzNDUiLCJodHRwczovL21zYWEuaWRlbnRpdHl3cmVzdGxlci5jb206MzAwMC92MS92YWxpZGF0ZSIsIiBodHRwczovL21zYWEuaWRlbnRpdHl3cmVzdGxlci5jb206MzAwMC92MS9hdXRob3JpemUiXSwiaXNzIjoiaHR0cHM6Ly90b2tlbnByb3ZpZGVyLmZvcmdlcm9jay5vcmciLCJzdWIiOiIxMjM0NSJ9.Gz2hTOa7gv4Cep2h71-_eT1qcI_2KbSeA0VQmdBwH6o"}


OIDC Tokens{ "expires_in": 599, "token_type": "Bearer","refresh_token": "f6dcf133-f00b-4943-a8d4-ee939fc1bf29","access_token": "f9063e26-3a29-41ec-86de-1d0d68aa85e9”,”id_token":

"eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAic3ViIjogImRlbW8iLCAiYXVkaXRUcmFja2luZ0lkIjogImQ5ZmYzMGYwLTUxM2ItNDgwMS05ZmNlLTFhYzZlNGFiMTNmMyIsICJpc3MiOiAiaHR0cDovL2thanZtLmV4YW1wbGUuY29tOjgwODAvb3BlbmFtL29hdXRoMiIsICJ0b2tlbk5hbWUiOiAicmVmcmVzaF90b2tlbiIsICJhdXRoTW9kdWxlcyI6ICJEYXRhU3RvcmUiLCAidG9rZW5fdHlwZSI6ICJCZWFyZXIiLCAiYXV0aEdyYW50SWQiOiAiNTgyOGQ4NzMtZTg2Yy00YmFiLTllNDAtOTAwMWRiOWFjNjJkIiwgImF1ZCI6ICJjbGllbnQiLCAibmJmIjogMTQ2NzczNTc2NywgInNjb3BlIjogWyAic2NvcGUiIF0sICJyZWFsbSI6ICIvIiwgImV4cCI6IDE0NjgzNDA1NjcsICJpYXQiOiAxNDY3NzM1NzY3LCAiZXhwaXJlc19pbiI6IDYwNDgwMDAwMCwgImp0aSI6ICI0OWMyMzhkNC1jNmY5LTQzMzMtYTZiMC04YzEzMjNlNGU0MTIiIH0.5TQnJQXqIpW_bG6jbqDX9VdulJByNZmPTvOmI1Ui6c8”}


Tokens: Performance vs. Security

StatefulL• Sessions stored on server• Token is opaque• Tokens must be validated with the server• Better logout

Stateless• Sessions not stored on server• Token may be introspected• Tokens CAN BE validated locally• Tokens difficult to revoke before TTL• PAYLOAD LIMITS (HTTP)

Token Performance Security

State Stateless Statefull

Encrypt JWT Body No Yes

Validate w/Authserver

No Yes

Validate all tokens

No Yes


MICROSERVICE TIERS – AN IDENTITY VIEW

TIER-2-SERVICE

EXPOSED EXTERNAL AND INTERNALCONSUMER AND SERVICE IDENTITIESHIGH LEVEL OF SECURITY

INTERNALCONSUMER AND SERVICE IDENTITIES

INTERNALSERVICE IDENTITIES ONLY

TIER-1-SERVICE

TIER-2-SERVICE

TIER-1-SERVICE

TIER-3-SERVICE TIER-3-SERVICE


Service to Service: OAuth Bearer token - stateful

mservice-1 FORGEROCK mservice-2

{Client Credentials}Request Token

{access token, refresh token, metadata} Response

{Access Token}Service Request

{Client Credentials, access token} Token Validation Request

{token_expires}Response

{data payload} Response


Tier 1 and 2 microservices - statelessTier-1-

application ForgEROCK Tier-2-service

{Client Credentials}Request Token

{access token, refresh token, metadata} Response

{consumer Access Tokenconsumer IDToken, service access tokenService Request

{data payload} Response

ExternalConsumer

302 redirect – Auth server

302 redirect – w/ auth code

Request protected app

{username,password} + consent

{Auth code}

{access token, refresh token, ID Token metadata}

{data payload}

Stateless token validated by microservice


AUTHENTICATION


FORGEROCK AUTHENTICATION

AuthenticationService

CONTEXTUAL

ADAPTIVE

STRENGHTSMULTIFACTOR

EXTENSIBLE

FRICTIONLESS

Module

STEP UP

Module

Module

CustomModule

ANY IDENTITYPLUG-IN

SCRIPTABLE

EXTERNAL CRED STORES

EXTERNAL CRED STORES


AUTHORIZATION


AUTHORIZATION TERMINOLOGY

PEP PDP

PIP

PAP

PRP

PROTECTEDRESOURCE

PEP – POLICY ENFORCEMENT POINTPDP – POLICY DECISION POINTPIP – POLICY INFORMATION POINTPRP – POLICY RETRIEVAL POINTPAP – POLICY ADMINSTRATION POINT

CLIENT

ADMIN


RBAC - ROLE BASED ACCESS CONTROL

Role A

Role B

Role C

PPPP

PPP

PPPP

PermissionsRoles§ MODEL WIDELY USED IN THE

ENTERPRISE

§ HEAVY ARCHITECTING WORK TO DEFINE ROLES AND PERMISSIONS

§ NOT VERY AGILE WHEN IT COMES TO CONTEXTUAL AUTHORIZATION

§ EASY TO AUDIT

§ EASY TO ADMINISTER


AuthorizationEngine

ABAC - ATTRIBUTE BASED ACCESS CONTROL

A A A

A A

A A

A A

A A

A A

A

Policies

§ MODEL ADOPTED FOR ENTERPRISE AND CUSTOMER FACING APPS

§ CONTEXT AWARE USING ENVIRONMENTAL ATTRIBUTES

§ RULES EVALUATED IN REAL TIME BY THE AUTHORIZATION ENGINE

§ FINE GRAINED ACCESS CONTROL

§ MORE AGILE

§ REQUIRES BETTER ADMINISTRATION

§ ROLE NAMES MIGHT BE SEEN AS ATTRIBUTES

PIP


IDENTITY RELATIONSHIPS

Located at

§ RELATIONSHIPS CONVEY AUTHORIZATION INFORMATION

§ CAN BE USED TO FEED A POLICY ENGINE TOGETHER WITH ATTRIBUTES


AUTHORIZATION SERVICE

AuthorizationService

CONTEXTUAL

ABACRELATIONSHIPS

EXTENSIBLE

FRICTIONLESS

Resource

RBAC

ANY IDENTITY

Directory

3rd Party

Subject

Environemt

ResponseAttributes

Scripted


CloudFoundry – Forgerock IDM Joint solutionCommon, repeatable way of integrating Identity Services into Cloud Foundry applications


Cloud Foundry Route Service

Router

CloudController

Service Broker

Service Broker

App 1

Service 1

Service 2

Browser

1

2

34

Cloud Foundry

1. A previously logged in user makes a request to an app with a bound route service. (Could be browser flow or API flow)

2. Router sends request to the service 3. Service validates token and grabs

additional data from profile and adds it to the body of the JWT, and sets the appropriate header to tell the router the request can continue.

4. Router passes the request through to the appropriate app.

5. The app, using the key it received at bind time, validates the signature of the token, unpacks the data from the body and acts accordingly.

5

FORGEROCK


UMA Provider Mobile App Synchronization Auditing

LDAPv3 REST/JSON

Replication Access Control

Schema Management

Caching

Auditing

Monitoring

Groups

Password Policy

Active Directory Pass-thru

Reporting

Authentication/SSO Authorization Provisioning User Self-Service Authentication OIDC / OAuth2

OAuth2/OIDC/SAML2 User Self-Service Workflow Engine Reconciliation Password Replay SAML2

Adaptive Risk Stateless/Stateful Registration Aggregated User View

Message Transformation

API Security Scripting

UMA Resource

Access Management Identity Management Identity Gateway

Directory Services

Com

mon

RES

T AP

I

Com

mon

Use

r Int

erfa

ce

Com

mon

Aud

it/Lo

ggin

g

Com

mon

Scr

iptin

g

FORGEROCK IDENTITY PLATFORM

Can be deployed, on premises, on the Cloud, on an IaaS like AWS, Azure, GCS, Docker containers, etc


AUTHENTICATIONFOR MODERN AND LEGACY SYSTEMS

§ 24+ OUT-OF-BOX MODULES INCLUDING DEVICE ID, OTP, ADAPTIVE RISK, GOOGLE, FACEBOOK, MS

§ AUTHENTICATION METHODS CAN BE CHAINED TOGETHER FOR ENFORCING DIFFERENT LEVELS OR STRENGTH OF SECURITY

§ SCRIPTED AUTHN MODULES EXTEND FUNCTIONALITY ON CLIENT SIDE AND SERVER SIDE USING GROOVY AND JAVASCRIPT

Create New Authentication Chain

SAML2 Authentication

Adaptive Risk / Device ID

ForgeRock Mobile Authenticator

Save Device Profile


ADAPTIVE RISKENABLES BETTER USER EXPERIENCE

§ THE ADAPTIVE RISK MODULE ASSESSES THE RISK BASED ON PRE-CONFIGURED PARAMETERS

§ OVER 20 PARAMETERS, INCLUDING IP ADDRESS, IP HISTORY, COOKIE VALUE, LOGIN HISTORY, GEO-LOCATION, ETC.

§ RISK SCORES ABOVE THE RISK THRESHOLD REQUIRE ADDITIONAL STRONGER AUTHENTICATION

§ CAN BE USED IN AUTHENTICATION CHAIN OR FOR STEP-UP RE-AUTHENTICATION

94

RISK SCORE


FORGEROCK AUTHENTICATOR

§ MULTI-FACTOR AUTHENTICATION WITH ONE-TIME PASSWORDS CAN BE DELIVERED VIA MAIL, SMS OR USING THE FORGEROCK MOBILE AUTHENTICATOR APP FOR IOS AND ANDROID

§ CONTEXT USING ADAPTIVE AUTHN AND DEVICE ID CAN ADD ADDITIONAL LEVEL OF ASSURANCE

§ THIRD PARTY OPTIONS FOR SMART CARDS, BIOMETRICS, MOBILE PHONE AS A TOKEN, ETC.

One Time Password585026


OAUTH2/OIDC

RESOURCESERVER

RESOURCE REQUEST

AUTHORIZATIONSERVER

OAUTH2/OPENID CONNECTSERVER

CLIENT

RESOURCE OWNER

ACCESS TOKEN REQUEST

AUTHORIZATION REQUEST

CONSENT


USER MANAGED ACCESS (UMA)PRIVACY AND CONSENT

RESOURCESERVER

AUTHORIZATIONSERVER

OAUTH2/OPENID CONNECT/UMA SERVER

CLIENT

RESOURCE OWNER

FINE GRAINEDCONSENT

REQUESTINGPARTY


Cloud Foundry UAA and/OR FORGEROCK

UAA

• Used to manage access to the CF platform

• It is the CF component in charge of providing access management services for the Cloud Foundry platform

• Its primary role is as an OAuth2 Provider, issuing tokens for client applications to use when they act on behalf of Cloud Foundry users.

ForgeRock• Integrates and augments the UAA capabilities by

providing the full set of IDM/IRM functions such as Multi-factor and Risk-Based Authentication, Authorization, Federation (OAuth2, OpenID Connect and SAML2), User Managed Access.

• Identity Management for customer facing applications, Identity Repository and Routing services.

• Provides digital identities for users, devices, services, things and models the relationshipsbetween them.

Confidential


ForgeRock IDENTITY MICROSERVICES PREVIEW

FORGEROCK SIMPLE MICROSERVICES COMING

• ForgeRock TOKEN ISSUER

• FORGEROCK TOKEN VALIDATION

• FORGEROCK AUTHORIZATION

• FORGEROCK TOKEN EXCHANGE

Confidential

Deployable in CloudFoundry or in a docker container


ForgeRock

ForgeRock

ForgeRockIdentity

ForgeRock

Forgerock.com

Blog.forgeroclk.com

THANK YOU!

Some Icons used in this presentation: Icon made by Freepik from www.flaticon.com

VÍCTOR AKÉCO-FOUNDER & VP CUSTOMER [email protected]

Technology

Munich CF Meet up: Authentication and Authorization for a microservices World