Example of an abstract that was submitted and accepted for the 2018 Grace Hopper Conference

1. API Security, a Grail Quest
Paula Paul
Technology Principal, ThoughtWorks
ppaul@thoughtworks.com
@paulapaultweets
ABSTRACT
Software engineers often wrestle with securing business
applications. We've enforced access control with RACF,
Unix file permissions, Windows security descriptors, SQL
grants, and entitlements servers. Microservice
architectures and REST APIs present new challenges for
access control. Join this illustrated quest to protect
application resources in distributed architectures, using
OpenID Connect.
AUDIENCE
This presentation is for software engineers who:
- implement distributed, microservice, event-driven
and/or REST API based systems for the enterprise.
- collaborate with Security or SecOps teams within the
enterprise, to ensure adoption of secure coding
practices and access control for APIs.
This is an Intermediate presentation for the Security
track. It provides a technical overview of a broad topic, to
arm attendees for more in depth quests of their own.
INTRODUCTION
We can learn quite bit about access control from ​Monty
Python and the Holy Grail​ (Python Pictures, 1991).
Enterprise applications are digital models of a business,
enabling access to the products, customer information,
supply chains, and transactions that drive revenue and
profit. We’ve protected access to those digital resources
for decades using the concepts of identity and
authentication (‘what is your name’), scope of access
(‘what is your quest’), and at times, examining additional
attributes or ​claims that are unique to the user (e.g. ‘what
is your favorite color’). The tools we use to define and
enforce access control include simple file system
permissions based on a network id or group name, and
database management systems that have separate
logical access controls or grants specific to database
objects. These approaches work well when the resources
we are trying to protect are centralized in a file system or
a monolithic database. In a distributed microservice
architecture, we no longer have centralized resources to
protect; business resources are scattered ​everywhere​,
including the cloud. When we build microservices and
APIs for Internet based access to distributed resources,
how do we define and enforce access permissions, and
cast unauthorized users into the Gorge of Eternal Peril?
API Security, a Grail Quest
The first question, ‘What is your name?’, addresses
Authentication
and Identity.
When you log in to
an online banking
application, you
are challenged to
identify yourself,
and that identity is
authenticated by a
trusted provider. In the early 2000’s people started
thinking about federated identity for the Internet,
inspired by kerberos and later brought mainstream in
Windows 2000 (Kohl, J., & Neumon, C., 1993). This led to
SAML, and a standard representation of Identity. With
SAML, we can think about identity in terms of:
● The IdP (​Id​entity ​P​rovider): an actor that issues
identity
● The SP (​S​ervice ​P​rovider): an actor that trusts
the IdP as a way to establish who the user is
SAML gave us the concept of identity as a document of
attributes.
Authentication and Identity tells us who you are, but does
not tell us what resources you are authorized to access.
When the social media giants Twitter, Facebook and
Google realized we had no open and standard way to
delegate access to resources, they solved this problem
with OAuth (Hammer, E., 2007). Thanks to OAuth, an
authenticated Facebook user can share their profile with
We envision a future where the people who imagine and build technology mirror the people and societies for whom they build it.

2. friends, without giving those friends their password (yes,
OAuth was born of the need to share embarrassing
information about ourselves).
OAuth also gave us the concept of access ​scope​, which
we see in social media. When a social media site or app
asks for
permission to
access your
photos, profile, or
other resources
you own, access to
those resources is
granted, or
delegated, via
OAuth, without giving out your account name or
password. In our film clip, the ‘quest’ defines a requested
scope of access.
Identity, authentication, and scope of access are the keys
to protecting resources. But, our quest is not complete.
And now for something completely standard
OAuth brought us an open, secure way to delegate access
to our social media resources, but that’s not quite enough
for the enterprise. We don’t really share access to a
financial API the same way we share access to our photos
on Instagram. In addition, OAuth makes an assumption: I
am holding key, therefore I am owner of the resources,
much the way a hotel key card works.
OAuth leaves some
important details up to
the engineer. For
instance, it defines the
concept of scope, but
does not define
standard or default
scopes. It specifies the
use of access tokens, but does not define the token
format. Software engineers building upon OAuth were
left to define their own approaches for tokens, scopes
and claims, for the resources they wanted to protect.
Since the specification is not prescriptive, if you’ve ever
tried to integrate multiple OAuth based APIs, you may
have written more code than you wanted or needed.
OpenID Connect (OIDC)
OIDC extends both SAML and OAuth, and standardizes
what OAuth leaves to choice, such as scopes, endpoint
discovery, and dynamic registration of clients. This makes
it easier to write code that can leverage multiple OIDC
compliant providers such as AzureAD, Okta, or Google.
(The OpenID Foundation, 2014)
OIDC specifies standard access and identity tokens, and
defines a set of specific scope names that can be used to
request specific sets of claims. Since the OIDC
specification dictates the token format, it is easier to
work with tokens across implementations, and possible
for providers to offer consistent libraries that developers
can use to enforce authentication and authorization.
Given the clear separation of identity tokens and access
tokens, it is also possible to use an IdP for identity and
some other service or services for authorization, without
having different authorization approaches and
implementations for each microservice or each API.
Back to our regularly scheduled programming
With OIDC, developers can have consistent interactions
with IdPs and authorization servers to protect business
resources that are exposed via APIs. Several certified
OIDC libraries are available to validate access tokens and
inspect custom scopes and claims in an open and
standard way, in order to enforce access to resources. To
illustrate this, we’ll look at the mechanics of OIDC, using a
simple client that requests an Identity Token and Access
Token, and uses that Access Token to call a specific
microservice API. [demo with multiple IdPs]
Authorization design considerations
Microservice design approaches apply to authorization,
including the principles of Domain Driven Design (DDD)
and bounded context (Fowler, M., 2014, Jan). For
authorization, each bounded context represents a
boundary for logical access control. There is a one-to-one
relationship between an authorization server and a
bounded context, with separate scopes to enforce access
control for individual API endpoints and HTTP Verb
combinations. Custom scopes allow for fine grained
authorization of API endpoints, for example, creating one
scope to authorize GET Products, and another to
authorize POST Products. The use of OIDC tokens can
support messaging and event driven architectures as well,
with choices for trusting queues vs. authorizing
messages. Authorization design follows naturally from
We envision a future where the people who imagine and build technology mirror the people and societies for whom they build it.

3. the domain of the application and should be part of any
DDD or event storming discussion.
Scope and claim design should reflect business needs
and provide only the minimum sufficient level of fine
grained access control, to minimize complexity. When
authorization requires ad-hoc evaluation of information
specific to the user, an engineer may collaborate with
SecOps stakeholders to create a custom claim, and
associate that claim with scopes created to authorize the
API. For example, you may authorize access to a Votes
API based on a
‘CanVote’ claim that
inspects the birth date
of the user. However,
avoid complex custom
claims when scopes
alone can suffice (i.e.
avoid asking for the
favorite color of each
caller in order to authorize access to an API).
Authorization Operations and Testing
The job of an OIDC authorization server is to issue tokens
for requested scopes. Operating an authorization server
requires defining which clients can request tokens, and
creating policies to define what scopes can be requested.
OIDC provides standards for client registration, and
authorization providers such as ​Auth0 or ​Okta include
administration consoles and APIs for policy management.
As an alternative, In 2003, the OASIS standards body
ratified XACML as a standard access control policy
language (OASIS 2013, Jan). While XACML can be applied
to OAuth, it has not been widely adopted. But, whether
managed via policy configuration language or API,
authorization servers, scopes, claims, and policies should
be managed as code and deployed via a build pipeline.
Engineers who adopt OIDC will collaborate with SecOps
stakeholders on topics such as token and refresh token
lifetimes, and authorization flows. When authorization
artifacts are maintained as code, automated API testing
can include security stakeholders, enforcing positive and
negative validation of scopes and access p0licies. For
example, tokens can be pre-generated to test for proper
handling of invalid or expired tokens. Automated API
testing with tools such as Postman can then then address
both functional and authorization testing needs.
API gateways present another alternative to OIDC
authorization servers. Centrally managed API gateways
can be less flexible that independent authorization
servers per bounded context, may also be limited strictly
to REST, as opposed to a messaging or event driven
architecture. For a more flexible and distributed
approach to enterprise API authorization, multiple
options for lightweight OIDC authorization servers are
available, including open source implementations
(​IdentityServer4​, ​Ory/Hydra​) and authorization servers
integrated with and supported by IdPs (Okta, Auth0).
Have we chosen wisely?
Using separate OIDC compliant authorization servers and
scopes aligned with each product or bounded context, is a
wise choice. This allows engineering teams to
independently define and manage custom scopes that
are specific to application needs, and enforce access
policies with OIDC compliant libraries available for the
languages and frameworks of their choice. When
authorization artifacts managed as code, authorization
can be part of the CI/CD pipeline, the true grail.
OUTCOMES/CONCLUSION
After this presentation, attendees will:
- Understand the concepts of Identity, Authentication and
Authorization as they apply to access control
- Understand the background and history of application
access management, through SAML, OAuth and OIDC
- Understand the benefits of OIDC for microservice and
API authorization
- Take away some design considerations for designing
authorization using OIDC
- Gain some insight to operational, SecOps, and testing
considerations for OIDC and authorization servers
PARTICIPATION STATEMENT
If accepted, I will attend the conference.
REFERENCES/BIBLIOGRAPHY
- Fowler, M. (2014, Jan). Bliki: Bounded Context.
Retrieved March 05, 2018, from ​http://bit.ly/2thC7vJ
- Hammer, E. (2007, Oct). Beginner's Guide to OAuth -
Part I: Overview. Retrieved March 04, 2018, from
http://bit.ly/2CYACly
- Kohl, J., & Neumon, C. (1993, Sep). The Kerberos
Network Authentication Service (V5). Retrieved
March 04, 2018, from ​http://bit.ly/2FsCOXQ
- OASIS (2013, Jan). eXtensible Access Control Markup
Language (XACML) TC. Retrieved March 04, 2018,
from ​http://bit.ly/1cEGf5g
- Python Pictures. (1991). Monty Python and the Holy
Grail. Burbank, CA :RCA/Columbia Pictures Home
Video, from ​http://bit.ly/2Frf2vx
- The OpenID Foundation (2014, Feb). Welcome to
OpenID Connect. Retrieved March 04, 2018, from
https://openid.net/connect/
We envision a future where the people who imagine and build technology mirror the people and societies for whom they build it.

4. BIO
Paula entered the workforce as a software engineer with
IBM in the early 80’s, where she shipped her first product
on magnetic tape. She’s shipped many software products
since then, evangelized .NET with Microsoft, held
executive positions in technology architecture and
operations, and taught people of all ages to code. Paula is
passionate about equal opportunities for technical
literacy, and enjoys (half) joking about how Kubernetes
reminds her of IBM/370 systems programming.
Paula is a ​Technology Principal with ThoughtWorks​,
where she helps clients adopt cloud native technology,
and serves the community as an ABI Syster, diversity
speaker, and mentor.
We envision a future where the people who imagine and build technology mirror the people and societies for whom they build it.