Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Identity as Code

Identity as Code

Users now have more complex identities than ever before; federated accounts, second-factor authentication, and multiple devices all these conditions need to be tested, but how? This talk will examine the minefield of identity and authentication in your pipeline and how your team can traverse this to ensure that you are managing identity as an architectural component without resorting to manual steps.

Andy March

June 18, 2019

More Decks by Andy March

Other Decks in Programming


  1. 10+ years working in secure systems Hi! Senior Platform Specialist

    at Okta Software Developer (.NET / Java / JS) @andymarch
  2. Name: Batman Role: Private Name: Superman Role: Major Name: Wonder

    Woman Role: Colonel Reports to Reports to
  3. Login Password Sign In Remember Me Forgot Password? Don’t have

    an account? Sign up Check for code injection Hash, salt, compare Common password Compromised password Account presence exposure Secure reset procedure Federation Data mapping Account linking Account duplication Email verification Consent gathering
  4. Custom code is responsible for 93% of app vulnerabilities Source

  5. The OAuth 2.0 Authorization Framework RFC 6749 The OAuth 2.0

    Authorization Framework: Bearer Token Usage RFC 6750 OAuth 2.0 Token Revocation RFC 7009 JSON Web Token (JWT) RFC 7519 Proof Key for Code Exchange by OAuth Public Clients RFC 7636 * these are just the ones that fit on the slide! *
  6. JSON Web Token Best Current Practices RFC 8725 OAuth 2.0

    Security Best Current Practice draft-ietf-oauth-security-topics-18
  7. Business Logic Monolith AuthN AuthZ AuthN AuthZ User Identity Database

    / Persistence User Identity Business Logic Database / Persistence Service Oriented User/Role Request/Permission
  8. AuthN AuthZ User Identity Business Logic Database / Persistence User/Role

    Request/Permission userid: 12345 role: auditor userid: 12345 permission: read.* Identification userid: [email protected] application: customer-data
  9. Dev Mostly unit tests Individual environment Integration Integration tests Shared

    environment QA Complex tests Single environment Prod Real users Production config
  10. Engine API Engine Client resource "aws_api_gateway_rest_api" "TabAPI" { name =

    "TabulationEngineAPI" description = "Tabulation Engine" } resource "aws_lambda_function" "perform" { function_name = "perform" s3_bucket = s3_bucket.lambda_bucket.id s3_key = s3_bucket.lambda_perform.key handler = "perform.handler" }
  11. provider "okta" { org_name = “babbage” base_url = “okta.com” api_token

    = “isthisarealtoken” } resource "okta_user_schema" "role_extension" { index = "analytical_engine_role" title = "Analytical Engine Role" type = "string" master = "PROFILE_MASTER" } Identity Provider Engine API Engine Client
  12. resource "okta_auth_server" "analytical_engine" { audiences = ["babbage.local"] description = "General

    purpose computing." name = "Analytical Engine API" } resource "okta_auth_server_scope" "tabulate" { description = "tabulate logarithm" name = "tabulate:perform" auth_server_id = "${okta_auth_server.analytical_engine.id}" } AuthZ Server Identity Provider Engine API Engine Client
  13. resource "okta_app_oauth" ”engine_client" { label = “Engine Client” type =

    "web” grant_types = [“authorization_code”] redirect_uris = [“${var.client_callback}”] response_types = ["code"] } resource "okta_app_oauth" ”engine_api" { label = “Engine API” type = ”service” grant_types = [“client_credentials”] } AuthZ Server Identity Provider Engine API Engine Client
  14. Engine.tf Dev.auto.tfvars Identity.tf Terraform plan Terraform apply Dev AuthZ Server

    Dev Identity Provider Dev Engine API Dev Engine Client
  15. resource “okta_user” “Ada” { login = “Ada” email = “[email protected]

    first_name = “Ada” last_name = “Lovelace” custom_profile_attributes = { analytical_engine_role = "Lead Programmer" } depends_on = ["okta_user_schema.role_extension"] } QA AuthZ Server QA Identity Provider QA Engine API QA Engine Client
  16. Engine.tf QA.auto.tfvars Identity.tf Terraform plan Terraform apply QA AuthZ Server

    QA Identity Provider QA Engine API QA Engine Client TestAccounts.tf
  17. data "okta_group" "devs" { name = "Devs" } resource "okta_policy_signon"

    "devSignOn" { name = "Developer policy" status = "ACTIVE" description = "Meet compliance for devs." groups_included = ["${data.okta_group.devs.id}"] } resource "okta_policy_rule_signon" "MFA60" { policyid = "${okta_policy_signon.devSignOn.id}" name = "MFA every hour" status = "ACTIVE" mfa_required = true mfa_prompt = "SESSION" mfa_lifetime = 60 } Identity Provider Engine API Engine Client
  18. • Don’t roll your own, standards are guardrails. • Architect

    for identity. • Test within a boundary, reach beyond when you must. • Define as much environment as you can in code. Recap