JSR 375: Secure Java apps in the cloud

Copyright © 2016, Creative Arts & Technologies and others. All rights reserved.
Security for Java EE
and the Cloud
Werner Keil
JSR 375 EG Member
@wernerkeil
November 16, 2016

Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
2

© 2016 Creative Arts & Technologies and others. All rights reserved.#JavaSecurity @jsr375
Who am I?
Werner Keil
• Consultant – Coach
• Creative Cosmopolitan
• Open Source Evangelist
• Software Architect
• Spec Lead – JSR363
• Individual JCP Executive Committee Member
[www.linkedin.com/in/catmedia]

Agenda
1. Motivation
2. Identity Use Cases
3. How can JSR 375 help?
4. More Security Use Cases
5. Way Forward?
6. Get Involved

Motivation
• Where enterprise apps run is changing
– In corporate data centers
– In the cloud from one of several vendors
• The shape of the Enterprise app is changing
– A monolith or a collection of microservices
• These factors
– Drive complexity in how apps are built, deployed, managed, operated
– Drive complexity in how apps need to work in their target environment
• Can we still stay secure after these changes?

Deployed On premise
• Deployed within the corporate network
• Authenticates to on premise
identity systems
• May use on premise Single Sign-on to
secure web resources
• Authorization : managed by application,
mapped to on premise identity
• Identity propagation to external entities
relies on SAML, Basic Auth
• Secrets in local stores with several layers
of control

Deployed in the Cloud
• Cloud Vendor for controls on network
• Social logins, external Identity Systems
• SSO using a Cloud Identity provider
• REST needs OAuth
• Identity Propagation - SAML,
Basic Auth plus OAuth and JWT
• More interactions – cloud, on premise
• Authorization - from one of several
identity providers
• Secrets need defense in depth – encryption,
securing the encryption key?

Microservices in the Cloud
• All issues of Java EE App in the cloud Plus
• App Boundary is changing
̶ Distributed processes, scale independently
̶ Identity on every hop?
̶ Each micro service deals with identity?
̶ Each micro service authorizes access?
̶ Each micro service manages secrets?
̶ What about Statelessness, configuration ?
̶ What about the network boundary?
Which micro services are public?

Identity Use Cases
Why are these so important in the
Cloud?

Use Case
Authentication
• Application may manage its users or use externally managed users
• Application must authenticate users against one of several identity
stores
• Application must support one of these authentication methods
̶ Basic Auth, OpenID Connect
• Application is able to handle Authentication events (login, logout)
• Developer is able to use a portable Authentication API regardless
of the identity store

Use Case
Identity Store
• Application may manage its users or use externally managed users
• Application must be able access the identity store
• Application can be bound to one or more identity stores at
deployment
• Identity Store bound to the Application can be reconfigured

Use Case
Identity Representation
• Application must be able to determine identity of the caller
• Application is able to determine user’s groups.
• Application knows caller identity consistently, as identity stores
change

Use Case
Security Context
• Application is able to determine user attributes consistently
̶ Authenticated user
̶ Groups, Roles
̶ Identity Provider that issued claims used in creating the Subject
̶ Local or remote user? Virtual User?
• Application needs a consistent API to access security context

JSR 375
Relevance to the Cloud
• Standardize Terminology
• API for Authentication mechanism
• API for Identity Store
• API for Security Context
• API for Password Aliasing
• API for Role/Permission Assignment
• API for Authorization Interceptors
A necessary foundation for the
Cloud

JSR 375 – Survey Results
Java EE 8 Survey
• Survey results
(from 2014)
• 4500 total responses
• Priorities Pie Chart

Security details

Security details
• Deferred from Java EE 7

JSR 375 – Candidates for EG
Authentication Mechanism
• Portable API for Authentication
̶ Abstracts the specific Identity Store against which to Authenticate
• Simple configuration
• Extensible to support protocols such as OpenID Connect and
OAuth
• Produces a Consistent representation of an authenticated Subject
• Authentication Events
• Use JASPIC (JSR 196) ?

Identity Store
• Abstract the Identity Store used by an application
• Simple configuration
• Support a variety of Identity stores
̶ Lightweight k-v development stores
̶ Traditional stores – LDAP, DB
̶ Cloud-specific stores e.g. Social Logins, 3rd-party Cloud Identity
providers

Identity Store
• Orderable to support multiple identity stores
• Abstraction to support variety of credential types
̶ Username/Password
̶ OAuth Client ID & Secret
̶ JWT Tokens

Security Context
• Consistent API regardless of container
• Enables Application to determine
̶ User’s identity
̶ Identity Provider that was used to establish identity
̶ Which groups or roles the user belongs to

Security Context Example
// Security Context
public interface SecurityContext{
String getUserPrincipal();
boolean isUserInRole(String role);
List<String> getAllUsersRoles();
boolean isAuthenticated();
}

Authorization
Lots to cover
• OAuth2
• Role/Permission Assignment
• Authorization Interceptors

26
OAuth
OAuth is a protocol to delegate rights for an application to act on
behalf of a user who granted its rights without giving away their
login / password
Developed by Twitter, Magnolia and Google,
it was made standard by IETF in April 2010 under RFC 5849
History

27
OAuth
Version 2.0, simpler to use but often criticized by its too many
implementation s was standardized in October 2012 under RFC
6749 and 6750. It’s already used by many actors (Social Networks
like Facebook, Google, Microsoft as well as other API providers )
All social services are based on OAuth 1.0a or 2.0.
To use OAuth, one has to create an application on the targeted
service to have an entry point for consumer.
OAuth2

28
OAuth
Overview
• An Authorization/Delegation Framework
• Standardized by RFC6749
̶ RFC 6750 using bearer tokens
̶ RFC 6819 Security considerations
• On a foundation of Token standards
̶ JSON Object Signing Encryption (JOSE)
̶ JWT (RFC7519), JWS (RFC7515), JWE (RFC7516),
JWA (RFC7518), JWK (RFC7517)

29
OAuth
Concepts
• Actors
̶ Resource Owner
̶ Client
̶ Resource, Resource server
̶ Authorization Server
• Authorizations represented as ‘scopes’

30
OAuth Dance
Creating an application in the OAuth Social Media service
Initialization : the right granting phase also called the OAuth Dance.
At the end of the dance we obtain an access token (formed by a
public and secret part) to use in next step
Signature : each request is signed with access token and token
identifying the OAuth application that was granted the rights
OAuth has 3 steps

In Memoriam
January 8, 1947 – January 10, 2016
David Bowie
Image © 1983 EMI America Records. All Rights Reserved.

32
OAuth Step 1 : Create an
application

33
OAuth : application settings

34
The OAuth 1.0a «Dance»
client asks for a
resource on the
consuming service
Consuming service server
Social Media Service
(where OAuth application is declared)
Consuming
service
redirect user
on the social
media login
page
token is returned by SM
Consuming service ask a
request token tot he Social
Media (using OAuth
application keys). It also
send a callback url
Once authenticated, social media
redirects user on call back url with a
verification code
with the code and request token
consuming service request an
access token
Social media returns Access
token
user

35
OAuth 2.0 «Dance» now in SSL
client asks for a
resource on the
consuming service
SSL is mandatory
Consuming service server
Social Media Service
(where OAuth application is declared)
Consuming
service
redirect user
on the social
media login
page
Once authenticated, social media
redirects user on call back url with a
verification code
with the code and request token
consuming service request an
access token
Social media returns Access
token
user

36
OAuth Signature : original
request
POST /1/statuses/update.json?include_entities=true HTTP/1.1
Accept: */*
Connection: close
User-Agent: OAuth gem v0.4.4
Content-Type: application/x-www-form-urlencoded
Content-Length: 76
Host: api.twitter.com
status=Hello%20Ladies%20%2b%20Gentlemen%2c%20a%20signed%20OAuth%2
0request%21

37
OAuth Signature : request & OAuth
params
status Hello Ladies + Gentlemen, a signed OAuth request!
include_entities true
oauth_consumer_key xvz1evFS4wEEPTGEFPHBog
oauth_nonce kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg
oauth_signature_method HMAC-SHA1
oauth_timestamp 1318622958
oauth_token 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
oauth_version 1.0

38
OAuth Signature : parameter
string
include_entities=true&oauth_consumer_key=xvz1evFS4wEEPTGEFPH
Bog&oauth_nonce=kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg&o
auth_signature_method=HMAC-
SHA1&oauth_timestamp=1318622958&oauth_token=370773112-
GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb&oauth_version=1.0&s
tatus=Hello%20Ladies%20%2B%20Gentlemen%2C%20a%20signed%20OAu
th%20request%21

39
OAuth Signature : Base String
POST&https%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses%2Fupdate.json
&include_entities%3Dtrue%26oauth_consumer_key%3Dxvz1evFS4wEEPTG
EFPHBog%26oauth_nonce%3DkYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS
4cg%26oauth_signature_method%3DHMAC-
SHA1%26oauth_timestamp%3D1318622958%26oauth_token%3D370773112-
GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb%26oauth_version%3D1.0%
26status%3DHello%2520Ladies%2520%252B%2520Gentlemen%252C%2520a%
2520signed%2520OAuth%2520request%2521

40
OAuth Signing key
VQ5CZHG4qUoAkUUmckPn4iN4yyjBKcORTW0wnok4r1k&
LswwdoUaIvS8ltyTt5jkRh4J50vUPVVHtR2YPi5kE
Application consumer key secret part
Access Token secret part

41
OAuth Signature : Signed request
POST /1/statuses/update.json?include_entities=true HTTP/1.1
Accept: */*
Connection: close
User-Agent: OAuth gem v0.4.4
Content-Type: application/x-www-form-urlencoded
Authorization:
OAuth oauth_consumer_key="xvz1evFS4wEEPTGEFPHBog",
oauth_nonce="kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg",
oauth_signature="tnnArxj06cWHq44gCs1OSKk%2FjLY%3D",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1318622958",
oauth_token="370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb",
oauth_version="1.0"
Content-Length: 76
Host: api.twitter.com
status=Hello%20Ladies%20%2b%20Gentlemen%2c%20a%20signed%20OAuth%20request%21

Ideas for OAuth2
Server Side
• Annotate resources to be secured
• Annotate if resource needs BASIC or OAuth2
• For OAuth2 secured resources, standardize scope declaration
• Standardize OAuth Resource registration with Authorization Server
• Adapt to specific Authorization Servers
• Document Auth method, scopes – Swagger?
• Subject to further exploration with EG, JAX-RS and Servlet Specs

Ideas for OAuth2
Client Side
• Lifecycle to handle Client registration
̶ Static or dynamically created Clients
̶ Secure management of Client ID/secrets
• Discover capabilities on Targets for constructing scopes in Token
requests
• Abstractions to acquire Token
̶ OAuth2 Flows as Strategies
̶ Token Expiry handling
• Abstraction to inject Tokens on invocation

44
OpenID Connect (OIDC)
Overview
• Authentication Protocol built on OAuth2
• Session Management – Single Sign on, Out
• An additional Token Type – ID Token
• UserInfo, Discovery, Client Self-registration Endpoints
• Specs : OpenID core, Discovery, Client Registration

OpenID Connect
Use Case
• At deployment, Application is configured to be secured by OIDC
• Application must continue to rely on well known abstractions for
̶ Identity
̶ Authentication
̶ Authentication Events

OpenID Connect
What does this mean to the App?
• An App developer
̶ Needs a consistent API to abstract the Identity store, authentication
mechanism, identity representation
̶ Can rely on configuration alone, to change as the App progresses
• DevOps can easily change configuration to suit the environment

Role/Permission Assignment
Use Case
• Application may manage its users or use externally
managed users
• Application needs to assign roles to users, groups based
on application specific model

Problem Statement
• Users or Groups assigned to Roles changes based on
deployment
• User, Group representations change based on bound
Identity Store
• OAuth2 Scopes vs Roles – do they overlap? Are they
complementary?

Ideas
• Support via Deployment
• descriptors e.g. web.xml
̶ Change binding at deployment
• Assign Scopes on OAuth2 resources to roles?
̶ Enables App to bind Scopes to Roles
̶ While mapped Users, Groups change

Example
<security-role-map>
<group>SalesSupport</group>
<role-name>CSR</role-name>
</security-role-map>
public class Customers{
@RolesAllowed(“CSR”)
@GET
public String get()
...
}

Authorization Interceptors
Use Case
• Application must restrict access to functionality
• Roles alone are too coarse grained
• Application business model determines rules that drive
access

Problem Statement
• No Consistent Interceptor for policy enforcement
• No Consistent externalizable Rules
• Need to be bindable to changing identities by Business and
Operations

Ideas
• Standardize Interceptors
• Enable Security teams to build custom Authorization logic
• Externalized, standardized rule language
• Identity and SecurityContext aware

Secrets
Use Case
• Application needs to be able to securely manage secrets
• Secrets may include passwords to resources e.g. OAuth Client ID +
secrets
• Applications are able secure secrets in a portable way
• Secrets are never stored in clear text
• Values change and are bound per deployment
• State has to be externalized
̶ Application may consume secrets from a Key Management System
(KMS)

Secrets
Ideas
• Application refers to secrets via Aliases
• Aliases configured via Annotations or Deployment Descriptors
• Lifecycle
̶ Bundle Alias + value as a secrets archive with the application
̶ Bind values to Aliases at Deployment
̶ From an external KMS?
̶ Tooling to manage secrets archive
• Rely on PKCS12 support in java.security.KeyStore ?

58
Consistently Secure
On premise to Cloud

Way Forward?
• Standardize Terminology
• Authentication mechanism
• Identity Store
• Security Context
• Authentication – OpenID Connect
• Authorization (incl. OAuth)
• Secret Management (incl. Password Aliasing)
• Security micro services
• Packaging, Configuration, Binding
Java EE 8
Java EE 9

60

Java EE 9 Candidates
Open ID Connect
Problem Statement
• Enable using OIDC for Authentication at Deployment
• Transparent to the Application
• Solely through Configuration
• Regardless of specific OIDC Implementation

Open ID Connect
Ideas
• OIDC Flows as an AuthenticationMechanism
• Standardize, abstract necessary configuration
• Configurable at deployment

Open ID Connect
Ideas
• Encapsulate within the SecurityContext
̶ Representations of user identity, group memberships
̶ Based on Claims in OIDC Identity Token from Open ID Provider (OP)
• Provide Applications access to /userInfo endpoint via the
IdentityStore abstraction

Authorization
• Discover/publish OAuth Resources
• OAuth Client registration
• Authorization Interceptors
• Authorization Rules EL
• Role/Permission assignment

Secret Management
• Abstracting secrets the application needs
• Bind secret values at deployment
• Standardize binding values from KMS systems

Security Micro Services
Identity Services
• Authentication implementations
• Authentication Configuration
• IdentityStore Configuration, handling
• Token Acquisition, Exchange

Secrets Management
• APIs to manage secrets
• APIs to get secrets
• Abstracts persistence, state management

Authorization Service
• APIs to publish, manage policy, role mapping
• APIs to get decisions
Mix-in Services as functionally needed
Packaging and Lifecycle
• Standardize Security Configuration
• Externalize Configuration
• Bind Values at deployment

Identity Services
• Encapsulate within the SecurityContext
̶ Representations of user id entity, group memberships
̶ Based on Claims in OIDC Identity Token from Open ID Provider (OP)
• Provide Applications access to /userInfo endpoint via the
IdentityStore abstraction

Links
JSR detail page on JCP.org: https://www.jcp.org/en/jsr/detail?id=375
Spec Page on java.net: https://java.net/projects/javaee-securityspec
Java.net Mailing List : users@javaee-security-spec.java.net
Experts Google Group: jsr375-experts@googlegroups.com
Contributors Group: jsr375-contributors@googlegroups.com
Twitter Account: @jsr375
Project website on GitHub: https://github.com/javaee-security-spec
Project Agorava: http://www.agorava.org

JSR 375: Secure Java apps in the cloud

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (16)

Similaire à JSR 375: Secure Java apps in the cloud

Similaire à JSR 375: Secure Java apps in the cloud (20)

Plus de Werner Keil

Plus de Werner Keil (20)

Dernier

Dernier (20)

JSR 375: Secure Java apps in the cloud