This document discusses ForgeRock's DevOps and cloud strategy. It outlines ForgeRock's goal of providing the agility of an identity-as-a-service solution with the flexibility of a custom solution. It describes what makes products "DevOps friendly" and focuses on making ForgeRock's products more container and cloud friendly. The roadmap sections outline planned improvements to OpenAM, OpenDJ, and OpenIDM to reduce dependencies and improve automation. It closes with a request for customer feedback to help prioritize efforts.

1. © 2016 ForgeRock. All rights reserved.

2. © 2016 ForgeRock. All rights reserved.
ForgeRock DevOps /
Cloud Strategy
Warren Strange
Director, Customer Engineering
NY Identity Summit 2016

3. © 2016 ForgeRock. All rights reserved.
Why DevOps?
Expectations for time to value are changing
• Months -> Weeks -> Days
The rise of “12 factor” apps & Continuous Integration
• Before: Deploy new features yearly
• Now: Deploy new features weekly
Shift towards cloud deployments and containers
• AWS, Azure, Google, OpenStack, etc.
• Docker / Kubernetes

4. © 2016 ForgeRock. All rights reserved.
ForgeRock DevOps Goal
The agility of an IDaaS, with the flexibility of a custom solution
Flexibility / Power
SpeedofDeployment
IDaaS
Legacy

5. © 2016 ForgeRock. All rights reserved.
What is “DevOps” Friendly?
• Installation / management is easily automated
• Products self tuning / self configuring
• Infrastructure as code
• Repeatable and automated deployments
• Useful configuration file formats
• Toolable / templatable
• Human friendly (not a dump of an internal data structure)
• Phoenix servers
• Blow one up, and another one rises to take its place

6. © 2016 ForgeRock. All rights reserved.
ForgeRock DevOps Focus
• Core engineering work required to make products more
“12Factor” like
• Requires deep & intimate knowledge of internals of OpenAM / OpenDJ
/ OpenIDM / OpenIG
• Where ForgeRock can have the most impact
• Container friendly
• Reduced file system dependencies
• Externalize state
• Dynamic configuration

7. © 2016 ForgeRock. All rights reserved.
Roadmap: OpenAM 14
• “Autonomous Servers”
• No cross-talk, no special servers
• CTS become sole source of state for tokens
• No “home” server concept
• Scale up / down by adding more servers
• Stateless Sessions
• Any server can issue a token, any server can validate it
• Extension of Stateless sessions in AM 13
• Stateless OAuth 2.0

8. © 2016 ForgeRock. All rights reserved.
Roadmap: OpenAM 14
• REST based Configuration
• ssoadm-ng
• REST / JSON Configuration
• Reduced file system dependencies
• Boot using ENV vars (Docker requirement)
• Agents
• Boot from ENV vars

9. © 2016 ForgeRock. All rights reserved.
Roadmap: OpenDJ
• Single persistence engine for the entire stack
• The one component that is most “pet” like
• OpenDJ 3.0
• Pluggable backends
• Foundational work for future alternate backends
• Memory based with snapshots (example: short lived access tokens
)

10. © 2016 ForgeRock. All rights reserved.
Roadmap: OpenIDM
• Boot from ENV Vars
• Flexible audit log destinations (commons audit)
• Improved Configuration Import / Export
• Export / Version / Import
• Improved conf/* file management
• Clearly separate product config from customizations
• Template environment variables
• OpenDJ as a repository

11. © 2016 ForgeRock. All rights reserved.
Containers
•Phase 1
• ForgeRock will support customers deploying with
Docker
• Provide sample Dockerfiles / Kubernetes Manifests
•Phase 2
• Provide reference Docker images
• Distribution mechanism TBD

12. © 2016 ForgeRock. All rights reserved.
Feedback Needed
• What are your biggest challenges in deployment / management?
• Help us prioritize our efforts
• What is your application AuthN / AuthZ strategy?
• Reverse proxy + HTTP headers - AuthZ at proxy
• Policy Agents (Java EE or .Net)
• OpenID Connect / SAML
• Directly consume OIDC tokens
• AuthZ - use scopes plus custom logic?
• Application landscape
• Java, .Net, NodeJS, Ruby, other?

13. © 2016 ForgeRock. All rights reserved.
Container Questions
• What are your plans for Docker?
• Have you looked at orchestration frameworks such as
Mesos / Kubernetes / Docker Swarm / Amazon ?
• What is your desired Docker support model?
• Would you run ForgeRock curated & tested Docker
images, or is your preference to create your own Docker
images?

14. © 2016 ForgeRock. All rights reserved.
Additional Material

15. © 2016 ForgeRock. All rights reserved.
Docker Tips
• Docker on Mac
• Remember it is running in a VM! “localhost” is relative
to the VM, not your laptop
• To find the IP of your VM host-only network use Kitematic or
docker-machine ip
• Docker Volumes are relative to your guest VM, not your
laptop
• Virtualbox can mount /Users/
• How do I shell into an running image?
• docker ps to get the image id
• docker exec -it image-id /bin/bash

16. © 2016 ForgeRock. All rights reserved.
Docker Registries vs. Repositories
• Registry:
• Service responsible for hosting and distributing docker images.
• Docker Hub is the most popular public registry.
• Others include quay.io (CoreOS team), gcr.io (Google)
• Private registries
• Repository
• Collection of Docker Images. For example “forgerock”
• Tags
• Images are tagged with a version. Example “dev”, “1.0”

17. © 2016 ForgeRock. All rights reserved.
Image Naming Format
{registry}/{repository}/{image}:{tag}
Examples
docker pull quay.io/kubespray/kubernetes-dashboard:latest
docker pull java:8u72-jre
Registry defaults to “hub.docker.com” if omited (Docker Hub)
Repository defaults to _ (“official” repo) if omitted
docker pull java
Tag defaults to “latest” if not specified

18. © 2016 ForgeRock. All rights reserved.
Tags
• Arbitrary schema (invent your own)
• By convention, a release version or git hash
• “latest” is a synonym for “the most recent version”
Example:
forgerock/openidm:latest
forgerock/openidm:nightly
forgerock/openam:13.0.1
Using “latest” is OK for development. Not good for production.
• Does not create repeatable deployment

19. © 2016 ForgeRock. All rights reserved.
Image Considerations
• Do not use proprietary base images!
FROM some-repo/oracle-jdk
FROM java:jre8
• Consolidate RUN commands to keep image size down

20. © 2016 ForgeRock. All rights reserved.
Building Container Friendly Apps
• Base container should be quite “generic”
• Personality is gained at runtime
• Avoid hostname / IP address dependencies
• One service, one container
• Stateless over stateful
• Throw away the container and create a new one
• Log / trace to stdout as a default
• Avoids needing to write special log collectors for each service
• Externalize persistence
• State stored externally (database, DJ)
• Be tolerant of service startup order and availability
• Example: service starts before the database is ready
• Database goes down, comes back up

21. © 2016 ForgeRock. All rights reserved.
Kubernetes
• Provides orchestration, container networking, service lookup,
rolling upgrades, bin packing, placement (affinity / non-
affinity)
• Self healing, horizontal scaling
• Created by Google, based on 10+ years of experience
running containers at scale
• Container agnostic (Docker, Rocket, LXC)
• Open source project
• Adopted by cncf.io
• IP transferred to the Linux Foundation
• Github PR Stats (one month)
• Kubernetes: 213 merged, 461 active
• Docker Swarm: 61 merged, 20 active
• Cloudfoundry-release + bosh: 17 merged, 8 active
J

22. © 2016 ForgeRock. All rights reserved.

23. © 2016 ForgeRock. All rights reserved.
Kubernetes Concepts / Terms
Nodes Servers that run pods
Pods Collection of containers that logically belong together. Scheduled
together. Ports must be unique within a pod
Services Abstraction that defines logical set of pods and how to access them.
Pod IPs are not stable over time. Service provide a Virtual / Stable IP
to access backend pods

24. © 2016 ForgeRock. All rights reserved.
Kubernetes Features
Namespaces Instance isolation on a cluster. For example, dev, QA, Prod. Multi-tenancy of
a kind..
Integrated DNS Service discovery via DNS
Persistent Volumes
Persistent Volume Claims
Abstraction for persistent data volumes attached to containers. For example -
postgres data files, OpenDJ backends.
Secrets / Secret volumes Special Volume type used to securely distribute secrets to your containers.
Secrets can be passwords, keys, keystores, etc.
This removes secrets from the containers themselves.
Replication Controllers Monitor service availability, restarting failed services as required. Autoscaling
support
Ingres API HTTP (Layer 7) and Network load balancing (Layer 3) built in
Jobs API Manage Jobs (one time processes)
Rolling Upgrades Manage upgrade of clusters and services

25. © 2016 ForgeRock. All rights reserved.
Kubernetes Tips
• Easy to use, hard to install
• Recommended (in relative order)
• GKE (Hosted Kubernetes as a service)
• Linux - follow local install instructions
• Kmachine
• https://github.com/TheNewNormal/kube-solo-osx

26. © 2016 ForgeRock. All rights reserved.