OAuth 2.0 Integration Patterns with XACML

1. Prabath Siriwardena
Senior Architect & Chair, Integration MC

6. Third-­‐party
applications
are
required
to
store
the
resource
owner's
credentials
for
future
use,
typically
a
password
in
clear-­‐
text.

7. Servers
are
required
to
support
password
authentication,
despite
the
security
weaknesses
created
by
passwords.

8. Third-­‐party
applications
gain
overly
broad
access
to
the
resource
owner's
protected
resources,
leaving
resource
owners
without
any
ability
to
restrict
duration
or
access
to
a
limited
subset
of
resources.

9. Resource
owners
cannot
revoke
access
to
an
individual
third-­‐
party
without
revoking
access
to
all
third-­‐parties,
and
must
do
so
by
changing
their
password.

10. Compromise
of
any
third-­‐party
application
results
in
compromise
of
the
end-­‐user's
password
and
all
of
the
data
protected
by
that
password.

17. • Complexity
in
validating
and
generating
signatures.
• No
clear
separation
between
Resource
Server
and
Authorization
Server.
• Browser
based
re-­‐redirections.

18. • An
entity
capable
of
granting
access
to
a
protected
resource.
• When
the
resource
owner
is
a
person,
it
is
referred
to
as
an
end-­‐user.

19. • The
server
hosting
the
protected
resources,
capable
of
accepting
and
responding
to
protected
resource
requests
using
access
tokens.

20. • An
application
making
protected
resource
requests
on
behalf
of
the
resource
owner
and
with
its
authorization

21. • The
server
issuing
access
tokens
to
the
client
after
successfully
authenticating
the
resource
owner
and
obtaining
authorization

23. Client
Credentials
Authorization
Code
Resource
Owner
Password
Credentials
Implicit

24. Scope
OAuth
Handshake

25. Confidential
Client
Type
Web
Application
OAuth
Handshake

26. BasicAuth
client_id
/
client_secret
Client
Authenticates
to
AuthZ
Server
OAuth
Handshake

27. Scope
OAuth
Handshake

28. Public
Client
Type
User
Agent
based
Application
OAuth
Handshake

29. Anonymous
Clients
OAuth
Handshake

30. Scope
OAuth
Handshake

31. Confidential
Client
Type
OAuth
Handshake

32. BasicAuth
OAuth
Handshake

33. Scope
OAuth
Handshake

34. Confidential
Client
Type
OAuth
Handshake

35. BasicAuth
OAuth
Handshake

36. Runtime

37. Bearer
MAC
Runtime

38. Bearer
MAC
Bearer
Any
party
in
possession
of
a
bearer
token
(a
"bearer")
can
use
it
to
get
access
to
the
associated
resources
(without
demonstrating
possession
of
a
cryptographic
key).
Runtime

39. Bearer
MAC
MAC
HTTP
MAC
access
authentication
scheme
Runtime

40. Feed
Clean
Take
out
Medication

41. Feed
Clean
Take
out
Medication

42. ¡ The
de-­‐facto
standard
for
authorization
¡ PAP
/
PDP
/
PEP
/
PIP
¡ XML
based
policies

44. Policy
Enforcement
Point

47. OAuth
XACML
Client
Subject
Resource
Owner
Subject
Scope
Action
+
Resource

48. Resource
Action
Resource
Owner
Client
Scope

49. Only
the
resource
owner
will
be
able
to
access
any
resource
during
weekend
and
after
9
PM
weekdays
Authorization
Rules

50. Day
:
Monday
Time
:
4
PM
Scope
=
“Scooby”+”medication”
Client
:
Foo
Resource
:
Bar

51. Day
:
Monday
Time
:
4
PM
Scope
=
“Scooby”+”medication”
Client
:
Foo
Resource
:
Bar

52. Day
:
Monday
Time
:
10
PM
Scope
=
“Scooby”+”medication”
Client
:
Foo
Resource
:
Bar

53. Day
:
Monday
Time
:
10
PM
Scope
=
“Scooby”+”medication”
Resource
Owner
:
Foo
Resource
:
Bar

54. Only
the
resource
owner
will
be
able
to
perform
Feed,
Take
Out
action
on
Dog
resource
Authorization
Rules

55. Day
:
Monday
Time
:
4
PM
Scope
=
“Scooby”+”feed”
Client
:
Foo
Resource
:
Bar

56. Day
:
Monday
Time
:
4
PM
Scope
=
“Scooby”+”feed”
Client
:
Foo
Resource
:
Bar

57. Day
:
Monday
Time
:
10
PM
Scope
=
“Scooby”+”feed”
Resource
Owner
:
Foo
Resource
:
Bar