An Authentication and Authorization Architecture for a Microservices World

© 2016 ForgeRock. All rights reserved.
An Authentication and
Authorization Architecture
for a Microservices World
David Ferriera, Director – Cloud Technology, Forgerock
david.ferriera@forgerock.com
Presented at SpringOnePlatform 2016
1

The Identity Layers
Who or What Layer
App/API
Consumers
(Browser, REST)
Service
(API, MySql, Redis,
OpenAM)
Platform
(cf push, DevMgr,
CI/CD pipeline)
System
(OpsMgr, BOSH,SSH)
Users Devices Things Applications Services
Developers
Operators
Services External ServicesApplications

Microservices
Pivotal Cloud Foundry

OpenAM
Authorization too
A A A
A A
A A
A A
A A
A A
A
Policies
 CONTEXT AWARE USING
ENVIRONMENTAL ATTRIBUTES
 RULES EVALUATED IN REAL TIME
BY THE AUTHORIZATION ENGINE
 FINE GRAINED ACCESS CONTROL
 ROLE NAMES MIGHT BE SEEN AS
ATTRIBUTES
PIP
ATTRIBUTE BASED ACCESS CONTROL

Protocols
Oauth 2 – RFC 6749:
“The OAuth 2.0 authorization framework enables a third-party application to
obtain limited access to an HTTP service, either on behalf of a resource
owner by orchestrating an approval interaction between the resource owner
and the HTTP service, or by allowing the third-party application to obtain
access on its own behalf.”
OpenID Connect (OIDC) :
“OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
protocol. It enables Clients to verify the identity of the End-User based on
the authentication performed by an Authorization Server, as well as to
obtain basic profile information about the End-User in an interoperable and
REST-like manner.”
Oauth 2 – Bearer Token usage - RFC 6750:
“This specification describes how to use bearer tokens in HTTP requests to
access OAuth 2.0 protected resources. Any party in possession of a bearer
token (a "bearer") can use it to get access to the associated resources
(without demonstrating possession of a cryptographic key). To prevent
misuse, bearer tokens need to be protected from disclosure in storage and
in transport.

Tokens: Types/Format
Access Token
• Part of Oauth, presented with each transaction
• can be opaque or JWT
• can be stateful or stateless
• Shorter TTL
Refresh Token
• Part of Oauth, received along with first access token after authentication to the auth server
• Used to request a new access token from the auth server, no credentials required
• Longer TTL
• Must be stored securely
ID Token
• Part of OIDC
• Contains Identity information about authenticated user
• Received in addition to the 2 oauth tokens
• Must be JW
• Longer TTL
JSON Web Tokens (JWT)
• Token format specified by OpenID Connect for the Identity Token
• Multiple levels of security possible (JWE, JWS, JOSE)
• Usually stateless

Tokens: Performance vs. Security
Stateful
• Sessions stored on server
• Token is opaque
• Tokens must be validated with the server
• Server handles authorization
• Better logout
Stateless
• Sessions not stored on server
• Token may be introspected
• Tokens validated locally
• Microservice must handle authorization
• Tokens difficult to revoke before TTL
Token Performance Security
State Stateless Statefull
Encrypt JWT
Body
No Yes
Validate w/Auth
server
No Yes
Validate all
tokens
No Yes
TTL’s Longer Shorter

Tokens: OpenAM response
stateless response
{
"access_token":
"eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAic3ViIjogImRlbW8iLCAiYXVkaXRUcmFja2luZ0lkIjogImQ3M2U5MzkwLTUyYWEtNDU5
Ni04NzgxLWZkZjFlNTI0YTE0MCIsICJpc3MiOiAiaHR0cDovL2thanZtLmV4YW1wbGUuY29tOjgwODAvb3BlbmFtL29hdXRoMiIsICJ0b2tlbk5hbW
UiOiAiYWNjZXNzX3Rva2VuIiwgInRva2VuX3R5cGUiOiAiQmVhcmVyIiwgImF1dGhHcmFudElkIjogIjU4MjhkODczLWU4NmMtNGJhYi05ZTQwLT
kwMDFkYjlhYzYyZCIsICJhdWQiOiAiY2xpZW50IiwgIm5iZiI6IDE0Njc3MzU3NjcsICJzY29wZSI6IFsgInNjb3BlIiBdLCAicmVhbG0iOiAiLyIsICJleH
AiOiAxNDY3NzM5MzY3LCAiaWF0IjogMTQ2NzczNTc2NywgImV4cGlyZXNfaW4iOiAzNjAwMDAwLCAianRpIjogIjBmMDE2Zjk3LWMwYjItNGIx
Mi04NjMzLWQwMTQ1Yjk0NDMxYyIgfQ.pq5yJtq1kGi4VaGIMOtusRD2G_f2VJrq2FKx0mhS2rQ",
"refresh_token":
"eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAic3ViIjogImRlbW8iLCAiYXVkaXRUcmFja2luZ0lkIjogImQ5ZmYzMGYwLTUxM2ItNDgw
MS05ZmNlLTFhYzZlNGFiMTNmMyIsICJpc3MiOiAiaHR0cDovL2thanZtLmV4YW1wbGUuY29tOjgwODAvb3BlbmFtL29hdXRoMiIsICJ0b2tlbk5h
bWUiOiAicmVmcmVzaF90b2tlbiIsICJhdXRoTW9kdWxlcyI6ICJEYXRhU3RvcmUiLCAidG9rZW5fdHlwZSI6ICJCZWFyZXIiLCAiYXV0aEdyYW50
SWQiOiAiNTgyOGQ4NzMtZTg2Yy00YmFiLTllNDAtOTAwMWRiOWFjNjJkIiwgImF1ZCI6ICJjbGllbnQiLCAibmJmIjogMTQ2NzczNTc2NywgInNjb
3BlIjogWyAic2NvcGUiIF0sICJyZWFsbSI6ICIvIiwgImV4cCI6IDE0NjgzNDA1NjcsICJpYXQiOiAxNDY3NzM1NzY3LCAiZXhwaXJlc19pbiI6IDYwN
DgwMDAwMCwgImp0aSI6ICI0OWMyMzhkNC1jNmY5LTQzMzMtYTZiMC04YzEzMjNlNGU0MTIiIH0.5TQnJQXqIpW_bG6jbqDX9VdulJByNZm
PTvOmI1Ui6c8",
"scope": "scope",
"token_type": "Bearer",
"expires_in": 3599
}

Tokens: Decoded @ jwt.io

Service to Service: Oauth Bearer token - stateful
mservice-1 OpenAM 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

Microservice Tiers – An Identity View
Tier-2-service
Exposed external and internal
Consumer and service identities
High level of security
Internal
Consumer and service identities
required
Internal
service identities only
Tier-1-service
Tier-2-service
Tier-1-service
Tier-3-service Tier-3-service

Tier 1 and 2 microservices - stateless
Tier-1-
application OpenAM
Tier-2-
service
{Client Credentials}
Request Token
{access token, refresh
token, metadata}
Response
{consumer Access Tokenconsumer
IDToken, service access token
Service Request
{data payload}
Response
External
Consumer
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

Cloud Foundry Route Service
Cloud
Controller
Service Broker
Service Broker
App 1
Service 1
Service 2
OpenAM
Browser
1
2
3
4
5
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.
Router

Forgerock Service Broker Roadmap
Cloud Foundry Integration Release Estimate
Alpha Service Broker Q2 2016
GA Service Broker – Oauth 2 Q3 2016
Pivotal Tile Q3 2016
GA Service Broker - OIDC Q4 2016
GA Route Service – SB enabled Q4 2016

Forgerock Software Download
https://backstage.forgerock.com/#!/downloads

References
OpenID Connect
http://openid.net/specs/openid-connect-core-1_0.html
Oauth 2
https://tools.ietf.org/html/rfc6749
JSON Web Tokens
Javascript Object Signing and Encryption
https://datatracker.ietf.org/wg/jose/documents/

An Authentication and Authorization Architecture for a Microservices World

More Related Content

What's hot (20)

Similar to An Authentication and Authorization Architecture for a Microservices World (20)

More from VMware Tanzu (20)

Recently uploaded (20)

An Authentication and Authorization Architecture for a Microservices World