Pespectives on how graph databases can be used for managing identities and access.

1. How
Graphs
revolu/onize
Access
&
Iden*ty
Management
rik@neotechnology.com
@rvanbruggen

2. Agenda
• About
Graphs
• About
Graph
Databases
• How
graphs
revolu/onize
Access
&
Iden/ty
Management
– Short
demonstra/on
• Case
Studies
• Q&A

3. My
personal
history
• Silverstream
>
Novell
• Novell
Iden/ty
&
Access
Management
• Imprivata
• Courion
– LeH
the
industry
out
of
frustra/on
with
the
lack
of
“real”
solu/ons…
– Funnily
enough,
Graphs
could
probably
have
helped…

4. Introduc/on:
about
Graphs

6. Meet
Leonhard Euler
• Swiss
mathema/cian
• Inventor
of
Graph
Theory
(1736)

7. Königsberg
(Prussia)
-­‐
1736

8. A
B
D
C

9. A
B
D
C
1
2
3
4
7
6
5

10. About
Graph
Databases

11. So
what
is
a
graph
database?
• OLTP
database
– “end-­‐user”
transac/ons
• Model,
store,
manage
data
as
a
graph

12. What
is
a
graph?
Node
Rela/onship

13. Contrast
with
Rela/onal
Graphs are often referred to as “Whiteboard Friendly”. The
data model reflects the way a domain expert would naturally
draw their data on a whiteboard
“The schema is the data”. Schema flexibility allows the system
to change in response to a changing environment

14. What
are
graphs
good
for?
Complex
Querying

15. Examples
of
complex
queries?
1.
Semi-­‐structure
in
datasets
15
– Normaliza/on
introduces
complexity
– Forces
developers
to
develop
all
kinds
of
logic
to
deal
with
this
variability
in
their
applica/on
logic

16. Examples
of
complex
queries:
2.
Connectedness
in
data
Lots
of
normalized
rela/onships
between
the
different
en//es,
forces
developers
to
do
• Deep
joins
• Recursive
joins
• Pathfinding
opera/ons
• “open-­‐ended”
queries

17. Examples
of
Connectedness

18. Graphs
revolu*onize
IAM?

19. “Killing”
IAM
• Sta/c
view
of
the
world
– Iden//es
are
owned,
created
and
managed
by
the
enterprise
– “Add
Move
Leave”
opera/ons
are
too
slow
and
not
aligned
with
core
cons/tuencies
– This
“misalignment”
was
a
huge
frustra/on
to
me:
sooooo
difficult
to
argue
the
business
value,
make
it
truly
mafer
to
business,
…
Many of these points were articulated by Gartner’s Ian Glazer
at http://blogs.gartner.com/ian-glazer/

20. “Killing”
IAM
• “Apart”
from
the
cri/cal
business
applica/ons
(
“A
part
of”
the
cri/cal
business
applica/ons)
– Partner
applica/ons
– Supplier
applica/ons
– SaaS
applica/ons
• Because
of
this,
IAM
projects
oHen
fail,
and
lack
a
real
business
jus/fica/on
– I
have
lived
this:
noone
wants
an
“ok”
solu/on,
and
bespoke
solu/ons
are
very,
very
expensive
Many of these points were articulated by Gartner’s Ian Glazer
20
at http://blogs.gartner.com/ian-glazer/

21. “Killing”
IAM
• Many
of
these
problems
result
from
the
fact
that
IA
is
not
easily
represented
as
a
strict
hierarchy,
anymore
– Hierarchies
cannot
represent
complex,
mul/-­‐dimensional
rela/onships
well
Many of these points were articulated by Gartner’s Ian Glazer
21
at http://blogs.gartner.com/ian-glazer/

22. How
do
graphs
help?
• Hi-­‐Fi
representa/on
of
complex
real-­‐world
rela/onships
• Real-­‐/me
queries
eliminate
need
for
integra/on
and
replica/on

23. 1.
Hi-­‐Fi
representa*on
of
reality
• IA
can
be
described
in
as
many
dimensions
as
we
need
– Mul/ple
hierarchies
form
one
graph:
departments,
suppliers,
partners,
assets,
roles,
projects…
• Cross-­‐cuing
concerns
(eg.
roles
in
mul/-­‐
func/onal
teams)
can
be
easily
described
• Removes
the
need
for
applica/on
specific
directories
/
user+role
management
SeeTed Neward’s The Vietnam of Computer Science

24. 1.a.
On
RBAC
• Cross-­‐cuing
concerns
are
oHen
described
as
RBAC:
“Role-­‐based
Access
Control
• The
truth
about
RBAC
– Role-­‐based
Access
is
“just”
another
mul/-­‐dimensional
view
of
access
iden/ty
– RBAC
systems
are
graph
based
in
theory,
but
oHen
implemented
on
top
of
an
RDBMS
that
manages
the
provisioning
system,
that
manages
the
applica/on
directory,
that
manages
the
applica/on
access
– REALLY???
24

25. 1.b.
On
Applica*on-­‐specific
Directories
• IAM
has
always
been
“difficult”,
because
essen/ally
it
con/nued
to
be
a
complex
integra/on
project:
you
could
not
do
without
Applica/on-­‐specific
Directories
– Too
difficult
/
slow
to
model
all
applica/on-­‐specific
access
in
a
hierarchy
(ie.
LDAP)
– This
is
VERY
feasible
in
a
graph
• So
maybe…
we
would
no
longer
need
to
do
the
integra/on
work?
25

26. 2.
Real
*me
queries
enable
it
all
• Access
control,
modeled
as
a
graph,
is
a
perfect
Neo4j
applica/on
– Traversals
can
be
mul/-­‐dimensional
–
and
prefy
deep:
combining
different
hierarchies
in
one
query
• Asset
Hierarchy
• Organisa/onal
Hierarchy
• Partner
Hierarchy
– Typical
access
control
ques/ons
are
very
“local”,
and
have
excellent
performance
characteris/cs
• Yes/No
answers
to
authorisa/on
ques/ons
26

27. Short
demo

28. Use
Cases
(neo4j.com/use-­‐cases)

29. Customers
(neo4j.com/customers)

30. Graph
Gists
(hfp://gist.neo4j.org/)

31. Neo4j
versions
/
licenses
Neo4j License Overview
Developer!
Seats!
Personal
Startup
/
Departmental
Enterprise
deployment
models
($6K*/Developer/Year)
Test!
Instances!
($6K/Instance/Year)
Production!
Instances!
(Bundle / Core Pricing)
Open
source
Commercial
license
terms
available
Specific
OEM
models
Instances whose purpose is to
ensure that the software accessing
Neo4j is meeting specification.!
!
(e.g. System Test, Integration Test,
UAT, Performance Test, Staging)
Instances that store and process
data in a way that benefits and
advances an organization’s goals.!
!
May be accessed by applications
and/or end users
Includes access by programmers
to licensed test instances, and
private instances on the
programmer’s personal machine
for the sole purpose of writing,
debugging, or testing software
designed to access Neo4j
*Or otherwise, depending on the Bundle, and negotiation

32. Future
trainings
events!
32

33. QA,
Conclusion,
Next
Steps
Neo
Technology
www.neotechnology.com
Neo4j
www.neo4j.org
rik@neotechnology.com
/
+32
478
686800
blog.bruggen.com
/
@rvanbruggen