Slide 1

Slide 1 text

1

Slide 2

Slide 2 text

2 ● Assoc Principal Solution Architect Red Hat (+8) ● Middleware Team Lead ● Teacher MBA Impacta ● AppDev, Cloud, Hybrid Cloud, DevOps ● Microservices, Kubernetes, CloudNative ● +15 anos Trabalhando com TI (EDS, Tata) ● Systems Integration, Middleware, Security ● Data Processing (FATEC-BS) ● Business Administration (FGV) ● Distributed Software Architecture (PUC MG) ● Linkedin ● Twitter ● Github

Slide 3

Slide 3 text

Segurança em Microservices: Como ? Onde ? Por que ? 3 Application “A” Application “B”

Slide 4

Slide 4 text

Segurança em Microservices: Como ? Onde ? Por que ? 4 Application “A” Application “B”

Slide 5

Slide 5 text

Segurança em Microservices: Como ? Onde ? Por que ? 5 Application “A” Application “B”

Slide 6

Slide 6 text

Segurança em Microservices: Como ? Onde ? Por que ? 6 Application “A” Application “B” Identity

Slide 7

Slide 7 text

Segurança em Microservices: Como ? Onde ? Por que ? 7 Application “A” Application “B” Identity

Slide 8

Slide 8 text

Segurança em Microservices: Como ? Onde ? Por que ? 8 Application “A” Application “B” Identity Sync

Slide 9

Slide 9 text

Segurança em Microservices: Como ? Onde ? Por que ? 9 Application “A” Application “B” Identity Sync Source of Truth Inconsistencies

Slide 10

Slide 10 text

Segurança em Microservices: Como ? Onde ? Por que ? 10 Application “A” Application “B” Identity

Slide 11

Slide 11 text

Segurança em Microservices: Como ? Onde ? Por que ? 11 Application “A” Application “B” Identity “External Access” “No direct connectivity”

Slide 12

Slide 12 text

Segurança em Microservices: Como ? Onde ? Por que ? 12 Application “A” Application “B” Identity “External Access” “No direct connectivity”

Slide 13

Slide 13 text

Segurança em Microservices: Como ? Onde ? Por que ? 13 Application “A” Application “B” Identity Format ?

Slide 14

Slide 14 text

Web UI Primariamente Aplicações WEB (ASP, PHP, Java, .NET) com soluções pouco interoperáveis proprietárias para cada plataforma Single Sign ON Geralmente implementando através de Cookies Dispositivos Móveis Inexistência do conceito de "Mobilidade" Redes Sociais Identidades Externas, APIs, Parceiros, Experiência Digital Segurança em Microservices: Como ? Onde ? Por que ? 14 Um pouco da nossa história... Autenticação & Autorização

Slide 15

Slide 15 text

Segurança em Microservices: Como ? Onde ? Por que ? Autenticação & Autorização 15 Contexto Atual e suas Respectivas Necessidades Experiências homogêneas ao usuário independente do device Mobilidade Adoção de protocolos como OAuth/OpenID como fundações e modelos para estratégias de APIs Padrões da Indústria Inclusão de agentes externos principalmente redes sociais como catalisadores de novos clientes/parceiros Redes Sociais Legislações, Compliance Marco Cívil da Internet GLPD Privacidade

Slide 16

Slide 16 text

Tópicos Segurança em Microservices: Como ? Onde ? Por que ? 16 ● Autenticação & Autorização ● OAuth 2.0 ● OpenID Connect ● JSON Web Token (JWT) ● Red Hat Single Sign ON

Slide 17

Slide 17 text

Autenticação & Autorização Autenticação 17 Quem é ... ? https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md The process of establishing confidence in the identity of users or information systems. Authentication is the process of verifying that an individual, entity or website is who it claims to be. Authentication in the context of web applications is commonly performed by submitting a username or ID and one or more items of private information that only a given user should know.

Slide 18

Slide 18 text

Autenticação & Autorização Autorização 18 O que pode ser feito ? https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf https://www.owasp.org/index.php/Category:Access_Control The right or a permission that is granted to a system entity to access a system resource. Access Control, also known as Authorization — is mediating access to resources on the basis of identity and is generally policy-driven (although the policy may be implicit)...also govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects).

Slide 19

Slide 19 text

Tópicos RH-SSO Workshop 19 ● Autenticação & Autorização ● OAuth 2.0 ● OpenID Connect ● JSON Web Token (JWT) ● Red Hat Single Sign ON

Slide 20

Slide 20 text

OAuth 2.0 OAuth 2.0 20 Authorization Framework..Delegated Authorization Source: https://tools.ietf.org/html/rfc6749 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 ▸ Papéis & Responsabilidades ▸ Fluxos, Endpoints ▸ Formato do Token! ▸ Meios para obter identidade do usuário!

Slide 21

Slide 21 text

An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user. OAuth 2.0 OAuth 2.0 21 Papéis e Responsabilidades Source: https://tools.ietf.org/html/rfc6749#section-1.1 An application making protected resource requests on behalf of the resource owner and with its authorization. Client The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. Authorization Server Resource Owner The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. Resource Server

Slide 22

Slide 22 text

Access Token Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client Token Type The access token type provides the client with the information required to successfully utilize the access token to make a protected resource request (along with type-specific attributes) Refresh Token Refresh tokens are credentials used to obtain access tokens. Scope The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. OAuth 2.0 22 Access Token OAuth 2.0 Source: https://tools.ietf.org/html/rfc6749#section-1.4 https://tools.ietf.org/html/rfc6749#section-7.1 https://tools.ietf.org/html/rfc6749#section-1.5 https://tools.ietf.org/html/rfc6749#section-3.3

Slide 23

Slide 23 text

Tópicos OpenID Connect 23 ● Autenticação & Autorização ● OAuth 2.0 ● OpenID Connect ● JSON Web Token (JWT) ● Red Hat Single Sign ON

Slide 24

Slide 24 text

OpenID Connect OpenID Connect 24 Identity Layer sob OAuth 2.0 Source: https://openid.net/specs/openid-connect-core-1_0.html#Introduction 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. ▸ Papéis & Responsabilidades ▸ Fluxos, Endpoints ▸ Token de Identidade ▸ Formato, Claims e Escopos

Slide 25

Slide 25 text

Tópicos OpenID Connect 25 ● Autenticação & Autorização ● OAuth 2.0 ● OpenID Connect ● JSON Web Token (JWT) ● Red Hat Single Sign ON

Slide 26

Slide 26 text

JSON Web Token (JWT) JSON Web Token (JWT) 26 Identity Layer sob OAuth 2.0 Source: https://tools.ietf.org/html/rfc7519 JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. ▸ Formato (Header, Claims, Assinatura) ▸ Criptografia ▸ Assinatura ▸ Tipos

Slide 27

Slide 27 text

JSON Web Token (JWT) JSON Web Token (JWT) 27 Identity Layer sob OAuth 2.0 { "alg": "HS256", "typ": "JWT" } { "iss": "joe", "exp": 1300819380, "human": true, "over 18": true } eyJhbGciOiJIUzI1NiIsIn R5cCI6IkpXVCJ9.eyJp c3MiOiJqb2UiLCJleHAi OjEzMDA4MTkzODAsI mh1bWFuIjp0cnVlLCJv dmVyIDE4Ijp0cnVlfQ.0 LtIxMRXW0VItgVqhQ GUJCEjzWpnXptQO Wxn9wGDyW4 Header Payload JSON Web Token Hash

Slide 28

Slide 28 text

Tópicos RH-SSO Workshop 28 ● Autenticação & Autorização ● OAuth 2.0 ● OpenID Connect ● JSON Web Token (JWT) ● Red Hat Single Sign ON

Slide 29

Slide 29 text

RH-SSO Workshop - Red Hat Single Sign ON Red Hat Single Sign On 29 Identity Access Manager Source: https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.3/html-single/release_notes/index#overview RH-SSO is based on the Keycloak project, and enables you to secure your web applications by providing Web SSO capabilities based on popular standards such as OpenID Connect, OAuth 2.0, and SAML 2.0. The RH-SSO server acts as an OpenID Connect or SAML-based identity provider (IdP), allowing your enterprise user directory or third-party IdP to secure your applications via standards-based security tokens. ▸ Padrões da Indústria (OAuth, OpenID, SAML, Kerberos) ▸ Federação de Usuários ▸ Broker de Identidades ▸ Gestão de Usuários e Sessões

Slide 30

Slide 30 text

RH-SSO Workshop - Red Hat Single Sign ON Red Hat Single Sign On 30 Identity Access Manager

Slide 31

Slide 31 text

Segurança em Microservices: Como ? Onde ? Por que ? 31 Application “A” Application “B”

Slide 32

Slide 32 text

Segurança em Microservices: Como ? Onde ? Por que ? 32 Application “A” Application “B” Authorization Server

Slide 33

Slide 33 text

Segurança em Microservices: Como ? Onde ? Por que ? 33 Application “A” Application “B” Authorization Server { “scopes”: openid profile email "family_name": "Martinez", "given_name": "Vinicius", "Name": "Vinicius Branda", "Preferred_username": "[email protected]” "sub": "Red Hat" }

Slide 34

Slide 34 text

Segurança em Microservices: Como ? Onde ? Por que ? 34 Application “A” Application “B” Authorization Server { “scopes”: openid profile email "family_name": "Martinez", "given_name": "Vinicius", "Name": "Vinicius Branda", "Preferred_username": "[email protected]” "sub": "Red Hat" } 200 400

Slide 35

Slide 35 text

Segurança em Microservices: Como ? Onde ? Por que ? 35 https://www.company.com Affiliate Website Mobile Partner Widget Internet Shipping Web plan Mobile plan Widget Customers Finance Tracking Logistics $ API Consumers API Products API Backends http://api.widget.local https://database.api/custrs https://finance.dept wss://tracking/api/v1 https://gds.log/api https://widget.company.com https://shipping.company.com Enterprise Boundary

Slide 36

Slide 36 text

Segurança em Microservices: Como ? Onde ? Por que ? 36 “..The API gateway might also implement security, e.g. verify that the client is authorized to perform the request” “..must use either the Client-side Discovery pattern or Server-side Discovery pattern” “..may authenticate the user and pass an Access Token containing information about the user to the services” “..will use a Circuit Breaker to invoke services”

Slide 37

Slide 37 text

Segurança em Microservices: Como ? Onde ? Por que ? 37 ACHIEVE FASTER API RELEASES Successful firms with an agile integration strategy release/update APIs weekly or daily, nearly three times more frequently than less successful firms. We remain concerned about business logic and process orchestration implemented in middleware, especially where it requires expert skills and tooling while creating single points of scaling and control. Vendors in the highly competitive API gateway market are continuing this trend by adding features through which they attempt to differentiate their products. This results in overambitious API gateway products whose functionality — on top of what is essentially a reverse proxy — encourages designs that continue to be difficult to test and deploy. API gateways do provide utility in dealing with some specific concerns — such as authentication and rate limiting — but any domain smarts should live in applications or services.

Slide 38

Slide 38 text

Segurança em Microservices: Como ? Onde ? Por que ? 38

Slide 39

Slide 39 text

Segurança em Microservices: Como ? Onde ? Por que ? 39 North-South Management East-West Management Microservic e Microservic e MS 1 MS 2 MS n Microservices group A Microservic e MS 1 MS 2 MS n Microservices group B API Product Enterprise boundary External facing APIs Internal facing Microservice

Slide 40

Slide 40 text

Use cases 40 ● Manage who can access my APIs ● Manage how they can access my APIs, configuring contracts & limits ● Developers can find my services & sign up for a plan ● Ability to package multiple services into one API product ● Get insights on usage of my APIs API Management Managing relationships ● Application performance, debugging, analytics data, incident management ● Security (mTLS, RBAC) ● Resiliency ● Traffic routing ● Infrastructure rate limiting based on multiple sources Service mesh management Advanced traffic management ● Send invoices and charge developers for API usage API Management External APIs Segurança em Microservices: Como ? Onde ? Por que ?

Slide 41

Slide 41 text

41