Devoxx 2016 - day 3: notes (2016/11/09)

Keynote

• AI / machine learning
  • lots af labeled datasets
  • products
    • tensorflow
• java 9:
  • modules
    • jlink
  • jshell (REPL interface)
• java future
  • small improvements: property-classes
  • Panama: improve JNI
    • demo: opencv (detect image contents)
    • cleaner interaction with native code

---

Security and Microservices

Sam Newman

intro

• http://samnewman.io/books/building_microservices/
• "live attacks" demo for fun http://map.norsecorp.com
• prevention / detection / response / recovery

transport security

• threatmodel
  • attack trees https://www.schneier.com/academic/archives/1999/12/attack_trees.html
  • ms threat model Stride
  • aim: raise cost of attack
• https everywhere:
  • server guarantee / tampering prevention
  • letsencrypt.org
• client side certs: difficult -- Lemur
• auth
  • oauth
  • form auth
  • "confused deputy problem": multiple access paths complicate security
    • saml assertions: complex
    • oauth token validated in services

data at rest

• encrypted datastore
• vault for password storage

docker issue

• scans
• build them yourself

code

• sdlc
• scanner
• connections: https://www.vaultproject.io/

logs

• centralize in ELK

---

The road to Node Package Manager Hell

Paul Watson

dependency checker:

• owasp dependency checker
• commercial: snyk.io / nodesecurity.io

yarn

• alternative npm client
• fast
• autolock dependencies
• deterministic installs
• offline installs

others:

• Nexus / Arifactory
• gradle gulp / node plugin

---

Modern web development using Aurelia

Harro Lissenberg

aurelia http://aurelia.io/

• javascript framework
• clean & non-obstrusive
• no dependencies -- uses its own polyfills
• MIT license

demo

• cli for project setup
• yarn install
• require.js
• recent ecmascript --> export class {}, constructor etc.
• au run -watch for testing
• repeate.for attribute with list of elements

---

Containers, VMs, Processes… How all of these technologies work ? Deep dive and learn about your OS

Quentin ADAM

process isolation

• chroot
  • security risks (root, escape, ...)
• jail / containers
  • linux cgroups: (docker)
    • some security risks
    • filedescriptors shared fS or full OS
• vm (e.g. qemu)
  • simulate cpu
  • VT-X instruction-set
  • performance?
    • cpu / memory- bound? usually not an issue
    • I/O system
      • storage
      • network

others:

• linux trickx
  • alpine linux https://alpinelinux.org/
    • musl
• devops: specialization required

---

100% Stateless with JWT (JSON Web Token)

Hubert Sablonnière

intro:

• cookies
• sessionid
  • shared / distributed cache (memcached etc)
  • or sticky session

jwt

• comparable to sessionids
• types
  • by reference
    • bankcard ref needed
  • by value
    • realmoney --> no extra data needed
• initial
  • wiret +sign
  • set JWT as cookie
• after
  • verify each request
• parts:
  • payload: claims + extra data
    • iss issuer
    • sub subject emaetc
    • times exp / nbf /iat
    • jti id
    • claims
  • signature
    • symetric e.g. hmac256
    • asymetric signature
• oauth2 / openid connect
  • based on jwt
• benefits
  • no loadbalancing:
    • shared secret on all servershtt
    • or public key on all servers en secret only on logon-service
  • multilanguage
• drawbacks
  • revocation
    • blacklist or whitelist?
  • single page applications // security?
    • xss with data in local storage
      • 3rd party scripting
      • solution: HTTPonly cookies
  • mobile apps
    • Authorization: Bearer header instead of cookie
  • csrf:
    • use local storage + add csrf token in payload
    • interceptor to send csrf token on each ajax request
• others
  • multipart forms
  • emails: jwt for reset email
  • api gateway with sessionid, but use internally JWT: api gateway does the transformation

---

Testing Legacy Code

Elliotte Rusty Harold

http://www.cafeaulait.org/slides/sdbestpractices2006/legacy/

• create broader tests first
• prefer unit test over integration test
• concentrate on changes
• junit, testng etc
• create initial setup (before / after) and add easy tests
• trial & error to tweak a new test
• also test obvious cases
• remove dead code
• code coverage: focus on missed elements:
  • Emma, Cobertura.
  • covered != tested...
• autogenerate tests? avoids boilerplate
• static analysis: Findbugs, PMD,...
• refactoring: watch out for reflective access (hibernate, etc)

---

Wait, what!? Our microservices have actual human users?

Stefan Tilkov

• single frontend that connects to multiple services?
• orchestration: complex
  • latency issue
  • "Bff" Backend for Frontends: http://samnewman.io/patterns/architectural/bff/
  • channels: are not that important -- seamless experience -- "everything everywhere"
• functional services
  • services with DB-access -- JDBC in disguise -- too low level
  • reuse is sideeffect
• UIs matter most (not the services)
  • can become a big monolith
  • failure in the long run
• "virtical responsibility": http://scs-architecture.org/
  • single team responsible for full slice
  • modularize frontend
• frontend tech is not an implementation detail!
  • impacts architecture
  • decision to be made upfront
• frontend
  • web: server vs client rendering
    • simple links (=resources)
    • redirection
    • transclusion: embedding other apps with javascript -- Web Components?
    • argument to avoid native
      • "mobile first"
      • responsive design
      • progressive enhancement
      • http://idlewords.com/talks/website_obesity.htm
  • hybrid: try to use webbased
  • native: platform specifics
    • single monolith "by definition"
    • only internal modularization
• solution frontend
  • organizational structure
  • platform interfaces: comparable to EJBs
  • release trains
  • discipline
  • or use hybrid: native with content from app (aka careless SPA)
    • js-apps shouldn't be as bad as native apps
    • forward/backward/refresh support?
    • linking support?
  • html instead of js (js-only reinvents browser)
  • use the browser (or embedded browser)
  • http://roca-style.org/
  • build more than one single page app
  • https://medium.com/@stilkov/why-i-hate-your-single-page-app-f08bb4ff9134#.l6wpi2up2
• summary
  • UIs matter
  • use the correct architectural style
  • frontend monoliths: as good /bad as backend monoliths