Securing web services with message level security and Username Token can be achieved through the following: 1. Defined in WS-Security specification for providing end-to-end security with support for confidentiality, integrity and authentication at the message level. 2. UsernameToken can be used to authenticate users to the service as defined in the UsernameToken Profile specification. 3. WS-SecurityPolicy can be used to express the security requirements and associate security policies with services.

1. Security In SOA
WSO2 Security Team

2. Do we need
security.. It’s extra
cost right…?

3. Everything comes
at a cost… security
is not an option

4. … not an
option.. But
a must..

5. Security is NOT
an option – it’s
a must

6. Security should
be by design –
not an after
thought

7. We run
everything on
HTTPS – aren’t
we yet secured…?

8. It’s NOT the best
of the
assumptions in
the world you
could make…

9. LISTEN..!!! I
know
HTTPS….

10. HTTPS helps
you transfer
data from one
point to
another
point..
Securely..

11. That is..
HTTPS helps
you to encrypt
data
transferred
between a
client and a
server

12. That’s all about
confidentiality –
how about
integrity?

13. Confidentiality
The assurance
that a message
has not been read
by anyone other
than the intended
reader

14. Integrity
The assurance
that data is
complete and
accurate

15. Authentication
The verification
of a claimed
identity

16. With HTTPS we
can have
Confidentiality,
Authentication
&
Integrity

17. Service
Authentic Service
ates to the
client
Client

18. Mutual Service
Authentic
ation
Client

19. Don’t think all
our clients want to
have their own
certificates – can
we have user
name/password
instead???

20. Easy thing –
use BasicAuth
over HTTPS

21. Wait…. Basic
auth sends
username /
password in
clear text..right?

22. But – we are
on HTTPS and
it won’t be an
issue… BTW
what are the
other options…

23. The other
Option is to
use Digest…

24. Let’s
summarize..
Securing
web
services
with HTTPS

25. Let’s
summarize..
1.Provides
confidentiality
through
encryption

26. Let’s
summarize.. 2.Service
authenticates
to the client
via
certificates

27. Let’s 3.Client can
summarize..
authenticate
via
certificates,
basic auth /
digest

28. I need a better subject…
any guesses???

29. That’s actually
Transport-level
security

30. OMG….I remember
somebody saying
Transport level
security – can be
insufficient….???
Who said that…?

31. Patience….
Sir.. It’s
me….

32. I can
explain….

33. Transport
level security
secures a
message only
during the
transfer from
one point to
another point.

34. In other
words.. Only
while the
message is on
the wire…

35. HTTPS HTTPS

36. When we use
Transport level
security [SSL]
our messages are
not secured on
‘intermediaries’

37. Not – just that –
we cant even
encrypt only a
part of the
message – if we
depend on
transport level
security

38. Need a way to
get rid of
transport level
security….

39. We can
handle
security at the
message level…

40. That way – we
can protect
entire message
or even just a
part of it….

41. Just –
confidentiality is
NOT enough – we
need to think
about adding
Integrity and
Authentication at
the Message
level…

42. Let’s start with
one by one – can
anyone tell me
how do we
support
authentication at
the message
level….???

43. It’s simple – I
will add a
custom SOAP
HEADER

44. <Credentials>
<UserName></UserName>
<Password></Password>
</Credentials>

45. I don’t like having custom
headers… that kills
interoperability….

46. Yes – true – we
should not try to re-
implement the wheel..

47. Okay – then
somebody explain –
what do we have on
our hands…?

48. Haven’t you
guys heard of
WS-
Security….

49. It defines how
to achieve
confidentiality,
integrity and
authentication
on SOAP
messages…

50. Let me clarify – ws-
security doesn’t
define new security
technology….

51. It focuses on
applying existing
security technologies
to SOAP messages…

52. Wow… exactly
what we
wanted…

53. For
authentication –
WS-Security
defines
UsernameToken

54. <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>

55. I looked into the
WS-Security spec
– but it does NOT
provide enough
details on
UsernameToken….
Where else
should I look
into..?

56. Here it is – you
need to look into
the
UsernameToken
Profile spec…

57. Let’s summarize..
Your findings on Securing
Message level
security and web
Username Token…
services
with
Message
level
Security

58. Let’s summarize..
Your findings on
Message level
security and 1.Defined in
Username Token…
WS-Security
specification

59. Let’s summarize..
Your findings on
Message level
security and 2.End to end
Username Token… security with
support for
confidentiality,
integrity and
authentication

60. Let’s summarize..
Your findings on
Message level
security and 3.UsernameToken
Username Token…
can be used to
authenticate
users to the
service.

61. Let’s summarize..
Your findings on
Message level
security and 4.UsernameToken
Username Token…
can have
password in
clear text or
as a digest.

62. Let’s summarize..
Your findings on
Message level
security and 5.UsernameToken
Username Token…
defined in
UsernameToken
Profile
specification.

63. Let’s move forward –
how about
Encryption with
Message level
security

64. With WS-Security
we can encrypt
Body, Header and
any of those sub-
structures…

65. Can somebody
explains me how
this encryption
happens???

66. That is basically a
shared symmetric
key….

67. It can be with a key
already shared or
known to both the
service and the client

68. We are going off
the topic here..
Anyway here’s
some basic
explanation….

69. Symmetric key
encryption
uses a shared
key for both
encryption
and
decryption…

70. Public key
encryption
uses
different
keys for
encryption
and
decryption…

71. Let me add more….

72. Symmetric key
encryption is
fast…

73. It can
operate on
large plain
text
messages…

74. Symmetric key
encryption
uses public
key
encryption to
manage shared
key
distribution
securely

75. Okay..okay.. I know…
AES, 3DES are
shared key
encryption
algorithms

76. Back to the topic….
WS-Security can
also use wrapped
key encryption as
well…

77. Got the point…. If
shared key being
used then both
client and service
have to share the
key…..

78. If client doesn’t have
a key – then a
shared key will be
derived through a
key wrapping
algorithm with
service’s certificate

79. That sounds good –
even client not
having a cert – we
still can have
encryption…. Let’s
move to the other
aspect… Integrity…..

80. WS-Security brings
XML Signature in to
SOAP messages to
achieve integrity….

81. BTW.. Signature not
only gives you
integrity – but also
the non-repudiation

82. Let me add little
more… if you need
to know bit more
about XML
Signature

83. XML Signature
defines three types
of Signatures –
enveloping,
enveloped and
detached. WS-
Security utilizes
only Detached…

84. Okay – that’s
enough… let’s start
building the big
picture on WS-
Security now… from
what we have
discussed so far….

85. WS - Security
XML Username X.509 Token
XML Signature
Encryption Token Profile Profile

86. Now we
know how to
authenticate
users with
message level
security….

87. Also how to
add
confidentiali
ty…

88. And..
Integrity and
non-
repudiation…

89. Now – the
question is…
who should be
able to access
our system???

90. All our
employees
need access…

91. Some of our
partner
companies
also need
access…

92. We maintain
the credentials
of our
employees - so
we can easily
authenticate
them…

93. How can we
authenticate
users from
partner
companies…

94. Let’s create
individual
accounts to
each of them
and maintain
those records
locally….

95. What a dumb idea
is that… you want
to maintain
thousands of
external domain
user accounts
internally…

96. We need not to trust
each individual belong
to our partner
companies… we only
trust them until they
belong to our partner
companies…

97. Exactly – we only trust
our partners only… But
we can let their
employees to access our
system if the company
says it’s okay to give
access…

98. In simple terms now
we need to find out a
way to establish trust
between our partner
companies…

99. That’s simple… let’s
accept requests from
out-siders - only if
those requests being
signed by a trusted
partner…

100. That sounds cool..
So we’ll be
maintaining a set
of public certs of
trusted partners to
validate signatures

101. This only solves
part of the
problem… how
about our users
who need access to
external system….
How do we sign all
the requests when
they go out to
external services…

102. Listen… I found
some thing
interesting – WS-
Trust – this exactly
solves our
problem….

104. We’ll be
maintaining
an STS –
which is
connected to
our internal
user store

105. Any of our
users who needs
access to an
external
service will
send a request
to our internal
STS

106. Need to
authenticate
him with a
Username Token

107. Since the
internal STS is
connected to the
internal user
store – STS can
verify user
credentials

108. Once the
credentials
validated, the
STS will issue a
token with the
required claims
and sign it by
our private key

109. If the external
service trusts
our STS – our
users will let
in…

110. Sounds GREAT..!!!
It’s the same for
external users who
needs access to our
services… we will
only trust their
STS…

111. Let me build
the BIG
picture once
again…..

112. WS - Trust
WS - Security
XML Username X.509
XML
Encryptio Token Token
Signature
n Profile Profile

113. Now we have
secured our
system…..

114. Also we know
who to trust
and how….

115. But – how do we
let other’s who
work with us
know security
standards we
use….

116. Ah… yes… when
external users
accessing our system
they must provide
their email address
with all their
requests….

117. Not – just that –
they also have to
know
encryption/signature
algorithms we use….

118. Also – we are not
going to encrypt entire
message – only some
parts – so we need to
tell them which parts
to encrypt…

119. I am going to prepare
a document which
includes all our
security requirements..

120. - Requires Email address…
- Encryption algorithms
AES
- Encryption key size
256
- Encryption algorithms
AES
- All the parts in the
<Body> must be signed
- Parts to be encrypted
depends on the service…

121. Looks good… we need
to extend this
further…And this is
our security policy…

122. There should be a
standard way of
communicating our
security policy to
others… let me
Google….

123. Oh.. Yes.. WS-
SecurityPolicy…

124. We can use it to express
security requirements of
a Web service according
to,
What needs to be
protected…
What tokens to use…
Algorithms, reference
types, etc….

125. We need to have different
security policies for
different services… how
can we associate a
security policy with a
given service….

126. That’s simple – you
can point to a policy
from the WSDL

127. But .. People may
access our service
with SOAP1.1 over
HTTP, SOAP 1.2
over HTTPS, SOAP
1.1 over JMS…

128. We may need to change
our policy based on
different ways people
access…. If we have this
pointed in WSDL – it
will be same for all those
cases… right….?

129. Okay – you want
to change the
policy based on
the message format
and the protocol

130. That is… you want
to have different
security policies
for different
‘bindings’… that is
possible and it’s
the
recommendation…

131. <wsdl:binding name="HelloServiceSoap11Binding“
type="ns:HelloServicePortType">
<wsp:PolicyReference xmlns:wsp=“"
URI="#SgnEncrUsername" />
<soap:binding
transport=http://schemas.xmlsoap.org/soap/http
style="document" />
<wsdl:operation name="greet">
<soap:operation soapAction="urn:greet“
style="document" />
<wsdl:input>
<soap:body use="literal" />
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>

132. Now.. Let’s see how
we can express
some of our
requirements in
WS-SecurityPolicy

133. UsernameToken
should be
included….

134. <wsp:Policy>
<sp:UsernameToken sp:IncludeToken=“”/>
</wsp:Policy>

135. We should accept
UsernameToken –
only if they are
signed…

136. <sp:SignedSupportingTokens xmlns:sp="">
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken=“"/>
</wsp:Policy>
</sp:SignedSupportingTokens>

137. Will be using
AES with 256
key size…

138. <sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>

139. We need entire
<Body> of the
message to be
signed…

140. <sp:SignedParts>
<sp:Body/>
</sp:SignedParts>

141. How about
encrypting just a
part of the
<Body>….

142. <sp:EncryptedElements XPathVersion="xs:anyURI"? ... >
<sp:XPath>xs:string</sp:XPath>+ ...
</sp:EncryptedElements>

143. Also… we need to
express the
requirement for
the required
claim set….

144. <sp:RequestSecurityTokenTemplate xmlns:t="">
<t:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1
</t:TokenType>
<t:KeyType >
http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey
</t:KeyType>
<t:KeySize>256</t:KeySize>
<t:Claims Dialect=http://wso2.org/claims xmlns:ic="">
<ic:ClaimType Uri="http://wso2.org/claims/email" />
</t:Claims>
</sp:RequestSecurityTokenTemplate>

145. That’s it… let’s move
forward… Now we are
secured.. We know
who to trust and how
to trust…

146. We also know how to
communicate our
security requirements
to the rest….

147. Let me build
the BIG
picture once
again…..

148. WS - Trust
WS-
SecurityPo
licy
WS - Security
XML Username X.509
XML
WS-Policy Encryptio Token Token
Signature
n Profile Profile

149. Now we need to
find out a way to
put this all-
together…

150. We should not expose
all our services
directly to external
domain…

151. Agreed – having
multiple entry point
into the system could
create security holes…

152. Let’s make sure
we authenticate
and authorize
users centrally….
And we can load
balance on that
end point….

153. So let’s not expose any
of our services to out
side….

154. We can have proxy
service and in front
and only the
authenticated and
authorized requests
will flow through to
the internal services…

155. Authentication Module
Authorization Module
Service Service Service
A B C

156. This is a familiar
security pattern…
Message Interceptor
Gateway…

157. Let me improve
the diagram a
bit…..
Authentication Module
Authorization Module
LDAP
Service Service Service
A B C

158. Anybody knows what
the authorization
module does…? We
need fine grained
authorization….

159. Yes.. Exactly… we need
a way to say.. Users
belong to the role X
can access Resource Y
only during this
particular time…

160. We should also be
able to say – any
users belong to role Z
cannot access any
resources….

161. That’ s simple – give
me your requirement
– I’ll right a policy
for it –and
Authorization
module will evaluate
it…

162. Oh..NO… don’t panic
– we need not to
reinvent the wheel…
this what exactly
XACML does…..

163. Sounds good – we
should go ahead with
the standards….

164. I know XACML….

165. It’s a
specification
which defines
how to
implement fine
grained
authorization in
a standard way…

166. Let me add
XACML to out
architecture
diagram…

167. Now – under
the XACMl
terminology, our
Authorization
module will act
as the Policy
Evaluation
Point [PEP]

168. Authentication Module
Authorization Module [PEP]
LDAP
Service Service Service
A B C

169. PEP is not just
enough – we need to
have a XACML engine
to act as a Policy
Decision Point….

170. Yes…. Policy
decision is made
at the PDP –
PEP will build
the Auth’Z
request and
contact PDP…
let’s bring PDP to
the picture…

171. Authentication Module
Authorization Module [PEP]
LDAP
Service Service Service
PDP
A B C

172. Then again –
PDP has to
retrieve XACML
policies from a
policy store….

173. Authentication Module
Authorization Module [PEP]
LDAP
Service Service Service
PDP
A B C
Policy Store

174. How do we going to
add new policies… we
also need to have a
policy administration
point…

175. Authentication Module PAP
Authorization Module [PEP]
LDAP
Service Service Service
PDP
A B C
Policy Store

176. Let’s celebrate – we
completed the
security design for
our backend
services…

177. Now… we need to
think about how we
authenticate users
at the front-end….

178. I hate passwords…
how many
passwords I have to
remember even
now… If this going
to add another
password to that list
– I am against it…

179. I agree – too many
password is a
problem…

180. See… even
within our
company we
need to have
different
passwords to
access different
systems…

181. Okay… let’s solve the
too many passwords
problem…

182. Hey…. We need not to
worry about it…
OpenID is for that…

183. Also – OpenID
facilitates
decentralized single
sign on…

184. That’s great – if we
use OpenID – we only
sign in once…

185. How can we
implement this…?

186. First thing… our web
application needs to
be an OpenID relying
party…. That is our
application will
accept OpenID
logins….

187. Also – we can
run our own
OpenID
Provider…

188. Then all our
web applications
will redirect
users to our own
OpenID Provider
for
authentication….

189. I don’t like
OpenID – it’s
phishing
heaven…

190. Hey.. Man… You got it
wrong… Phishing is a
separate issue –
OpenID doesn’t try to
address Phishing…

191. Then who’s
going to solve the
problem of
solving
phishing…?

192. Heard of
Information
Cards…??? It’s
going to address
the issue of
phishing…

193. I know Information
cards… it’s an
application of WS-
Trust….

194. We already decided
to run an STS – so
we can easily become
an information cards
provider too…..

195. Then what…???

196. Then – at the OpenID
provider – we can
ask users to
authenticate with
information cards –
in a phishing
resistant manner….

197. Great.. That
sounds perfect….

198. Okay.. We are
almost done…

199. But… yet we need
to figure out how
to implement
this…

200. Remember guys….
The cost matters
the most….

201. Yes.. We can’t let
product vendors
kill us…

202. So… let’s figure out
available open
source options
first….

203. Let’s use WSAS to
deploy our
services…

204. Who knows more
about WSAS….?

205. It is an open
source, enterprise-
ready, Web
services engine
based on Apache
Axis2….

206. Authentication Module PAP
Authorization Module [PEP]
LDAP
PDP
Service Service Service
A B C
Policy Store

207. Now… What..
Anybody knows
an open source
XACMl engine….

208. WSO2 Identity
Server can do it
for sure…

209. It’s not just an
XACML engine…
we can use it as
our OpenID
Provider as well…

210. Also… it comes
with an
Information Card
provider…

211. Wow… that looks
perfect for us…
let’s see how this
fits into our
architecture
diagram….

212. Authentication Module
PAP
Authorization Module [PEP]
PDP
LDAP
Service Service Service
A B C Policy Store

213. Looks good….
hmm… a question
– can we deploy
Identity Server
over our LDAP
server…?

214. Yes…. That’s a
must – we need to
use our existing
user store….

215. That’s easy – you
can simply
connect Identity
Server to our
LDAP server…

216. Exactly – it’s a
matter of a simple
configuration…

217. Okay…. That sounds
good.. So… Identity
Server will be our
XACMl engine,
OpenID Provider and
also the Information
Card provider….

218. Authentication Module
PAP
Authorization Module [PEP]
PDP
Service Service Service LDAP
A B C Policy Store

219. How about the
STS…? Can we use
Identity Server for
that…?

220. One more thing…
we need the STS to
be claim aware…

221. … it should
connect to our
LDAP and pick
the user attributes
from there… can
Identity Server do
it?

222. Look at this… you
can do it with
Identity Server…

223. … it has this claim
management
component… we can
easily configure
Identity Server STS to
use our LDAP…

224. Authentication Module
PAP
STS
Authorization Module [PEP]
PDP
Service Service Service LDAP
A B C Policy Store

225. Looks perfect….
What else
missing…

226. How about using
WSO2 ESB… as
the service
bus…?

227. Yes… that helps
us implementing
Message
Interceptor
Gateway pattern
easily…

228. See this… it comes
with an
Entitlement
Mediator –
which can
connect to the
Identity Server’s
XACMl engine…

229. Wow…!!! I like
whatever makes
us less work…

230. Who knows
more about
WSO2 ESB….?

231. It enables the loose-
coupling of services,
connecting systems
in a managed
virtualized
manner….

232. …. allowing
administrators to
control and direct
communication
without disrupting
existing applications

233. PAP
Authentication Module
STS
Authorization Module [PEP] PDP
Service Service Service LDAP Policy Store
A B C

234. Okay…. Now we
need a policy
store….

235. Let me.. Suggest
this time… WSO2
Governance
Registry will do
that….

236. So.. Clever 
I also found the
same… It’s very
much more than
just a policy store
– or a registry…

237. …It is an
enterprise-ready
open source
product for
governing SOA
deployments…

238. Sounds great.. Let’s
update the
diagram… we are
almost getting to
the end….

239. PAP
Authentication Module
STS
Authorization Module [PEP] PDP
Service Service Service LDAP
A B C

240. Looks great..!!!
Finally we came
up with a fully
open source
solution for our
security design…

241. Thanks a lot… for
your
participation…

242. Time for
questions… I am
sure you guys
have many….???

243. …also you can reach us
through…
http://wso2.com,
http://wso2.com/about/contact
&
bizdev@wso2.com

244. Thank You…!!!