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.

D7c78f8757327b65a637aece98939f01?s=128

Andy March

June 18, 2019
Tweet

Transcript

  1. Identity as Code Photo by Carson Arias on Unsplash

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

    at Okta Software Developer (.NET / Java / JS) @andymarch
  3. Information wants to be free. Stewart Brand

  4. None
  5. None
  6. Information wants to be free. Information also wants to be

    expensive. Stewart Brand
  7. Name: Batman Role: Private Name: Superman Role: Major Name: Wonder

    Woman Role: Colonel
  8. Name: Batman Role: Private Name: Superman Role: Major Name: Wonder

    Woman Role: Colonel Reports to Reports to
  9. Name: Batman Role: Private Name: Batman Role: Major Name: Batman

    Role: Colonel Reports to Reports to
  10. Name: Batman Role: Colonel/Major/Private Reports to

  11. None
  12. Don’t roll your own identity

  13. Login Password Sign In Remember Me Forgot Password? Don’t have

    an account? Sign up
  14. 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
  15. Custom code is responsible for 93% of app vulnerabilities Source

    contrastsecurity.com/state-of-application-security-libraries
  16. Identification and Authentication Failures #7 Broken Access Control #1 Web

    Application Security Risks
  17. None
  18. 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! *
  19. None
  20. Authenticate Authorize Register Account Recovery Identity as a Service

  21. None
  22. JSON Web Token Best Current Practices RFC 8725 OAuth 2.0

    Security Best Current Practice draft-ietf-oauth-security-topics-18
  23. Divide your architecture, divide your responsibility

  24. Business Logic Monolith AuthN AuthZ AuthN AuthZ User Identity Database

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

    Request/Permission userid: 12345 role: auditor userid: 12345 permission: read.* Identification userid: alex@audit.co application: customer-data
  26. Don’t test what you don’t control

  27. Capture Mock / Replay Validate

  28. Sign-in Page Mock (AuthN) Login (user, password) MFA_Required MFA_Response(secret) Accepted

  29. …except when you must

  30. Define Use / Reuse Initialize Cleanup

  31. Dev Mostly unit tests Individual environment Integration Integration tests Shared

    environment QA Complex tests Single environment Prod Real users Production config
  32. Snowflake Environments

  33. Infrastructure as Code

  34. None
  35. 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" }
  36. API.tf Terraform plan Terraform apply

  37. 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
  38. 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
  39. 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
  40. API.tf Identity.tf Terraform apply Terraform plan

  41. API.tf Identity.tf 12c28fb1888dbb64e0ce8e7c5250f621814c3c8b

  42. Engine.tf Prod.auto.tfvars Identity.tf Terraform plan Terraform apply AuthZ Server Identity

    Provider Engine API Engine Client
  43. None
  44. None
  45. None
  46. None
  47. Engine.tf Dev.auto.tfvars Identity.tf Terraform plan Terraform apply Dev AuthZ Server

    Dev Identity Provider Dev Engine API Dev Engine Client
  48. Engine.tf QA.auto.tfvars Identity.tf Terraform plan Terraform apply QA AuthZ Server

    QA Identity Provider QA Engine API QA Engine Client
  49. resource “okta_user” “Ada” { login = “Ada” email = “ada.lovelace@babbage.local”

    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
  50. 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
  51. Integration QA Default

  52. None
  53. None
  54. None
  55. 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
  56. Engine.tf QA.auto.tfvars Identity.tf Terraform destroy TestAccounts.tf QA AuthZ Server QA

    Identity Provider QA Engine API QA Engine Client
  57. Okta Directory Security Hardening using Terraform Managing Multiple Okta Instances

    with Terraform Cloud
  58. • 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
  59. developer.okta.com andy.march@okta.com @andymarch Slides: speakerdeck.com/andymarch/identity-as-code