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