This document discusses authentication and describes how it is becoming more complex and sophisticated. It introduces the concepts of modules, chains, and flags that are used to build authentication processes. Modules perform specific authentication functions and can share information through a shared state. Chains combine modules together, and each module in a chain has a flag to determine if it is required, requisite, sufficient, or optional. The document then proposes moving to a tree structure rather than chains to provide more flexibility, including the ability to branch and loop. It describes stripping functionality out of modules and into decision nodes to avoid coupling.

1. AUTHENTICATION
DAVID LUNA, IDENTITY TECH TALK 2017

2. AUTHENTICATION
COMPLEX AUTHENTICATION
▸ Traditionally, we’ve had usernames and passwords
▸ Can now engage with users without either (!)
▸ Increased sophistication
▸ Multiple services utilised during authentication
▸ Weigh up user convenience vs increased security
▸ Becoming apparent in our day-to-day lives

3. AUTHENTICATION
Source: BBC News, 25 June 2017

4. AUTHENTICATION
INCREASED SOPHISTICATION
▸ Much higher uptake of 2FA, growing more common to
hear the phrases “multifactor” and “two factor”
▸ Remote services, e.g. push can be utilised as out-of-band
communication
▸ Risk management
▸ Location / IP / Device / Requested Resource
▸ Do we trust this user right now? If not, ask for more!

5. AUTHENTICATION
HOW DO WE ADMIN THIS?
▸ Frictionless user experience
▸ Long-lived sessions
▸ Requirements for one app differ to those of another
▸ Utilise policies with transaction authentication
▸ Re-authenticate using a specific authentication process
to access a particular resource once.
▸ Re-access? Re-authenticate.

6. AUTHENTICATION
MODULES
▸ Perform a specific authentication
function
▸ That function’s complexity varies greatly
▸ Once inside a module, result is either
PASS or FAILED
▸ sharedState allows modules to share
information gathered from the user up
to that point in authentication, but
▸ If utilising sharedState must know
which keys to use - couples the
modules themselves

7. AUTHENTICATION
CHAINS
▸ Chains combine sets of
modules together to
form an authentication
process for a user
▸ Modules in a chain each
have a flag
▸ User progresses
through the chain, each
module has access to a
sharedState put things
in, or read things from

8. AUTHENTICATION
FLAGS - REQUIRED
▸ All required modules used in the process must have a
PASS outcome. Authentication process continues even if
they have a FAILED outcome, but will FAIL.

9. AUTHENTICATION
FLAGS - REQUISITE
▸ All requisite modules used in the process must have a
PASS outcome. Authentication process ends in failure if
they have a FAILED outcome.

10. AUTHENTICATION
FLAGS - SUFFICIENT
▸ A sufficient module with a PASSED outcome will end the
chain in PASS. Authentication process continues even if
they have a FAILED outcome.

11. AUTHENTICATION
FLAGS - OPTIONAL
▸ An optional module continues after executing.

12. AUTHENTICATION
PASS AND FAIL
▸ Only two outcomes of authentication:
▸ PASS - Granted a session cookie, redirected to
successURL configured for the chain
▸ FAIL - Redirected to failureURL configured for the chain,
or simply an authentication failed screen

13. AUTHENTICATION
FLEXIBILITY OF CHAINS
▸ String of modules
▸ Flags don’t allow branching
▸ Allow you to skip to another chain by failing and using
failureURL
▸ Gives us a cascade of chains to use if a user fails
▸ Doesn’t allow for decision making in the chain, decisions
can be made in modules only via sharedState

14. DEMO

15. AUTHENTICATION
CHAINS GOOD. GRAPHS ARE BETTER.
▸ They’re graphs, but we’ll call them trees.
▸ No, I know, but we’ll call them trees. Please? Thanks.
▸ Feature:
▸ Source / Sink node(s) (start and end)
▸ Gathering nodes (majority of old Modules)
▸ Decision nodes (components of Modules stripped out)

16. AUTHENTICATION
TREES
▸ Decisions now made outside of modules
▸ Branching can occur to anywhere in the tree
▸ Loops are supported!
▸ Save a tree, and load it within another tree
▸ Modules no longer need to understand specifics of
sharedState - that’s now the decision node’s job
▸ Decision nodes can be easily scripted

17. AUTHENTICATION
TREES CONTINUED
▸ Nodes have one input, and N outputs, not just FAIL and
PASS.
▸ No more flags!
▸ e.g. create an “Optional” module which has a FAIL and
PASS output by putting both FAIL and PASS outcomes to
the same next node
▸ Implement granular functionality using Decision Node
▸ sharedState is now tree-specific, doesn’t couple modules

18. DEMO

19. AUTHENTICATION
David Luna
@ohnomorejuzzo
david@luna.co.uk