SOA security needs to be by design, not as an afterthought. This session will demonstrate implementing Message Interceptor Gateway security pattern with WSO2 ESB, WSO2 WSAS and WSO2 Identity Server – together with the OpenID/Information Cards integration pattern at the front end. The Message Interceptor Gateway pattern provides a single entry point and allows centralization of security enforcement for incoming and outgoing messages. Further, this session explores adding authentication and fine grained authorization for web services.

1. OSCON July 20 – 24 , 2009 San Jose, California
.
.
The Secured Enterprise:
Leverage OpenID with Web
Services
Prabath Siriwardena
Technical Lead & Product Manager
WSO2

2. WSO2 is an innovative Open Source technology company
devoted to building Web services middleware for your
SOA. Offering leading products, support and other
services, WSO2 was founded in August 2005. It is a
global corporation with offices located in USA, UK
and Sri Lanka.

3. 40,000,000
credit card numbers stolen

5. Security needs to be by design
NOT an after thought

6. What do we need
to secure…
ROUND TABLE DISCUSSION

7. We have a bunch
of services
already developed
and some under
development….
ROUND TABLE DISCUSSION

8. Yes…. we need to
make sure all the
data transferred
are secured….
ROUND TABLE DISCUSSION

9. How about
securing data
transfer between
service and the
client through
HTTPS….
ROUND TABLE DISCUSSION

10. HTTPS is not
bad.. But still it
has certain
limitations…
ROUND TABLE DISCUSSION

11. Transport level encryption
NOTES…… HTTPS
Point to point
Entire message needs to be encrypted
Adds less weight on message payload
Applies only to HTTP

12. ROUND TABLE DISCUSSION
How about
message level
security?

13. End to End
NOTES…… MESSAGE LEVEL SECURITY
Parts of the message can be encrypted
Adds more weight on message payload
Transport Independent

14. Yes – let’s
finalize on
Message level
security….
ROUND TABLE DISCUSSION

15. How can we use
Message Level
Security to protect
our services…
ROUND TABLE DISCUSSION

16. Confidentiality
NOTES…… C-I-A
Integrity
Authentication

17. The assurance that a message has
NOTES…… CONFIDENTIALITY
not been read by anyone other
than the intended reader

18. The assurance that data is
complete and accurate
NOTES…… INTEGRITY

19. The verification of a claimed
NOTES…… AUTHENTICATION
identity

20. Can we make
sure we
interoperate with
the rest…
ROUND TABLE DISCUSSION

21. Yes… we need not
to re-implement
the wheel… what
is the standard to
achieve C-I-A
with message
ROUND TABLE DISCUSSION
level security…?

22. Defines how to achieve
confidentiality, integrity and
NOTES…… WS-SECURITY
authentication with SOAP messages
Does not define a new security
technology only focuses on
applying existing security
technologies to SOAP messages

23. With UserNameToken
defined in WS-
Security enables us to
authenticate users
with
username/password…
ROUND TABLE DISCUSSION

24. NOTES…… USERNAMETOKEN
<wsse:UsernameToken wsu:Id="Example-1">
<wsse:Username> ... </wsse:Username>
<wsse:Password
Type="..."> ... </wsse:Password>
<wsse:Nonce
EncodingType="..."> ... </wsse:Nonce>
<wsu:Created> ... </wsu:Created>
</wsse:UsernameToken>

25. WS-Security brings
XML Encryption to
enable confidentiality
in SOAP Messages….
ROUND TABLE DISCUSSION

26. Shared Key
NOTES…… ENCRYPTION
Key Wrapping

27. A shared key for both encryption
NOTES…… SHARED KEY
and decryption
Can operate on large plain text
messages
Uses public key encryption to manage
shared key distribution securely
Fast

28. Both the client & the service
NOTES…… KEY WRAPPING
need not to have a certificate
A shared key is derived through
the service’s certificate
Further communication being encrypted
with the derived shared key

29. ROUND TABLE DISCUSSION
Integrity comes
through the XML
Signature….

30. Integrity
NOTES…… SIGNATURE
Non repudiation

31. WS - Security
NOTES……
XML Username X.509 Token
XML Signature
Encryption Token Profile Profile

32. Okay… now all
our services are
secured with ws-
security… What is
next?
ROUND TABLE DISCUSSION

33. We need to see
who should be
given access to
our services….
ROUND TABLE DISCUSSION

34. Definitely all the
internal users…
ROUND TABLE DISCUSSION

35. …also some of our
partner
companies….
ROUND TABLE DISCUSSION

36. Okay… we can
ROUND TABLE DISCUSSION
easily
authenticate
internal users
with
UserNameToken
- since we have
their credentials
internally….

37. But we don’t
maintain
credentials of
external users…
coming from our
partner
ROUND TABLE DISCUSSION
companies….

38. ROUND TABLE DISCUSSION
We need not to
maintain
external user
credentials… we
only need to trust
our partners….

39. ROUND TABLE DISCUSSION
…and that is
what WS-Trust
does….

40. NOTES…… WS-TRUST

41. We need not to authenticate
NOTES…… TRUSTING PARTENERS
individual external users
We only TRUST external partners
All the requests coming through external
users need to be signed by the
corresponding partner companies
Only the requests signed by TRUSTED
partners will let in

42. …also our users
need access to
external systems..
Out of our
domain….
ROUND TABLE DISCUSSION

43. That is exactly
the other side of
what we just
discussed.. We
need to maintain
an internal STS
ROUND TABLE DISCUSSION

44. All the requests going out side from
internal users need to have a security
token issued by the internal STS
NOTES…… STS
Internal users should authenticate them
selves with the internal STS – prior to
obtaining a security token
External services need to trust
our STS

45. WS - Trust
NOTES……
WS - Security
Username X.509
XML XML
Token Token
Signature Encryption
Profile Profile

46. Now… the
question is how
are we going to
communicate our
security
requirements to
ROUND TABLE DISCUSSION
the rest…

47. Let’s first list the
security
requirements…..
ROUND TABLE DISCUSSION

48. Internal users should authenticate with
SECURITY REQUIREMENTS
user name / password when accessing
services directly

49. External users should present a security
SECURITY REQUIREMENTS
token from a trusted STS

50. Email address should be present in the
SECURITY REQUIREMENTS
security token comes with the external
users.

51. Only some parts of the message needs to be
SECURITY REQUIREMENTS
encrypted.

52. Encryption algorithm should be AES.
SECURITY REQUIREMENTS

53. Encryption key size needs to be 256.
SECURITY REQUIREMENTS

54. All the parts in the <Body> must be signed
SECURITY REQUIREMENTS

55. We need a way
to express all
these in a
ROUND TABLE DISCUSSION
standard way….

56. Ws-security
policy exactly
addresses that…
ROUND TABLE DISCUSSION

57. Used to express security requirements of
NOTES…… WS-SECURITY POLICY
a Web service according to, What needs to
be protected… What tokens to use…
Algorithms, reference types, etc….
Security policies can be defined at the
binding level / operation level

58. WS - Trust
WS-
SecurityPo
NOTES……
licy
WS - Security
Username X.509
XML XML
WS-Policy Token Token
Signature Encryption
Profile Profile

59. Everything looks
good…. Is there a
way we could
make sure we
ROUND TABLE DISCUSSION
strictly follow the
security polices
defined…

60. ROUND TABLE DISCUSSION
Okay – that
means we need to
validate each and
every service
developed…

61. Yes – validation
needs to happen
at two stages…
ROUND TABLE DISCUSSION

62. Design time
validations will
make sure we
adhere to proper
standards and
ROUND TABLE DISCUSSION
polices at the
time we develop …

63. Runtime
validations will
make sure we
evaluate all the
requests coming in
ROUND TABLE DISCUSSION
against the
defined security
policies….

64. Design time governance
NOTES…… SOA GOVERNANCE
Runtime time governance

65. NOTES…… DESIGN TIME GOVERNANCE

66. NOTES…… DESIGN TIME GOVERNANCE

67. NOTES…… DESIGN TIME GOVERNANCE

68. NOTES…… DESIGN TIME GOVERNANCE
MONITORING

69. ROUND TABLE DISCUSSION
Yet… we haven’t
figure out how to
enforce policies
on users – or the
requests coming
through to our
services…

70. Yes… we need to
make sure all the
requests comply
with the defined
security polices….
ROUND TABLE DISCUSSION

71. NOTES…… MESSAGE INTERCEPTOR
GATEWAY PATTERN

72. Provides a single entry point and
allows centralization of security
NOTES…… MESSAGE INTERCEPTOR
enforcement for incoming and outgoing
messages.
GATEWAY PATTERN
Helps to apply transport-level and
message-level security mechanisms required
for securely communicating with a Web
services endpoint.

73. NOTES…… MIG - IMPLEMENTATION
All the services can be deployed inside
WSO2 Web Services Application Server
[WSAS] – not publicly accessible
An open source web services engine powered
by Apache Axis2

74. NOTES…… MIG - IMPLEMENTATION

75. NOTES…… MIG - IMPLEMENTATION
A
Service
B
Service
C
Service

76. NOTES…… MIG - IMPLEMENTATION
A
Service
B
Service
C
Service

77. NOTES…… MIG - IMPLEMENTATION
Authentication Module
Authorization Module [PEP]
LDAP
Service Service Service
A B C

78. NOTES…… WSO2 ESB – SECURING PROXY
SERVICES

79. NOTES…… WSO2 ESB – SECURING PROXY
SERVICES

80. NOTES…… WSO2 ESB – SECURING PROXY
SERVICES

81. NOTES…… MIG - IMPLEMENTATION
Authentication Module
Authorization Module [PEP]
LDAP
PAP
Service Service Service
STS
A B C
PDP

82. NOTES…… WSO2 IDENTITY SERVER
Claim-based security token service -
mapping user attributes to defined claims,
which can be used to enable identity
federation with claim aware web services.
XACML Policy Administration Point & Policy
Decision Point

83. NOTES…… WSO2 IDENTITY SERVER - STS

84. NOTES…… WSO2 IDENTITY SERVER - STS

85. NOTES…… WSO2 IDENTITY SERVER –
PAP/PDP

86. NOTES…… WSO2 IDENTITY SERVER –
PAP/PDP

87. NOTES…… WSO2 IDENTITY SERVER
PAP
PDP
STS

88. WS-Security / WS-Trust / WS-Security Policy
NOTES…… SUMMARY
Message Interceptor Gateway Pattern
WSO2 Governance Registry / WSO2 WSAS /
WSO2 ESB / WSO2 Identity Server

89. We have secured
access to all our
backend services…
ROUND TABLE DISCUSSION

90. Let’s think of
securing the front
end….
ROUND TABLE DISCUSSION

91. ROUND TABLE DISCUSSION
Yes… our backend
services can be
accessed through
either with a
direct client or
with our web
portal….

92. Also we already
have different
web applications
managed
internally…
ROUND TABLE DISCUSSION

93. And it’s hard to
have different
credentials to
each web
application….
ROUND TABLE DISCUSSION

94. Let’s redesign
authentication
for all our web
applications….
ROUND TABLE DISCUSSION

95. ROUND TABLE DISCUSSION
One more thing…
we also need to
give access to
external users to
the web portal as
well…

96. Too many passwords
NOTES…… PROBLEMS TO BE
Single Sign On
ADDRESSED
Giving access to external domain users

97. Decentralized Single Sign On
NOTES…… OPENID
Single User Profile
Identity Federation

98. NOTES…… OPENID LOGIN FOR WEB PORTAL
BROWSER
OP
WEB PORTAL

99. NOTES…… OPENID LOGIN FOR WEB PORTAL
BROWSER
OP
WEB PORTAL

100. NOTES…… OPENID LOGIN FOR WEB PORTAL
BROWSER
OP
WEB PORTAL

101. NOTES…… OPENID LOGIN FOR WEB PORTAL
BROWSER
OP
WEB PORTAL

102. NOTES…… OPENID LOGIN FOR WEB PORTAL
BROWSER
OP
WEB PORTAL

103. NOTES…… OPENID + INFORMATION CARDS
OP

104. NOTES…… WSO2 IDENTITY SERVER
OpenID Provider
OP InfoCard Provider

105. NOTES…… TRUSTED SUB SYSTEM
WEB PORTAL

106. NOTES…… TRUSTED SUB SYSTEM
WEB PORTAL
OP

107. WS-Security / WS-Trust / WS-Security Policy
NOTES…… SUMMARY
Message Interceptor Gateway Pattern
WSO2 Governance Registry / WSO2 WSAS /
WSO2 ESB / WSO2 Identity Server
OpenID + InfoCard
Trusted Sub System Pattern

108. http://wso2.com
http://wso2.com/about/contact
DISCUSSION…...
bizdev@wso2.com
prabath@wso2.com

109. Thank You…!!!