Security In SOA WSO2 Security Team
Security In SOA
WSO2 Security Team
Do we need security.. It’s extra
cost right…?
Everything comes at a cost… security is not an option
… not an option.. But
a must..
Security is NOT an option – it’s
a must
Security should be by design –not an after
thought
We run everything on
HTTPS – aren’t we yet secured…?
It’s NOT the best of the
assumptions in the world you could make…
LISTEN..!!! I know
HTTPS….
HTTPS helps you transfer data from one
point to another point..
Securely..
That is.. HTTPS helps
you to encrypt data
transferred between a
client and a server
That’s all about confidentiality –
how about integrity?
ConfidentialityThe assurance that a message
has not been read by anyone other than the intended
reader
IntegrityThe assurance that data is complete and accurate
AuthenticationThe verification of a claimed identity
With HTTPS we can have
Confidentiality, Authentication
&Integrity
Service
Client
Service Authenticates to the
client
Service
Client
Mutual Authentic
ation
Don’t think all our clients want to
have their own certificates – can
we have user name/password
instead???
Easy thing –use BasicAuth over HTTPS
Wait…. Basic auth sends username / password in
clear text..right?
But – we are on HTTPS and it won’t be an issue… BTW what are the
other options…
The other Option is to use Digest…
Let’s summarize..
Securing web
services with HTTPS
Let’s summarize..
1.Provides confidentiality
through encryption
Let’s summarize.. 2.Service
authenticates to the client
via certificates
Let’s summarize..
3.Client can authenticate
via certificates, basic auth /
digest
I need a better subject… any guesses???
That’s actually Transport-level
security
OMG….I remember somebody saying Transport level
security – can be insufficient….??? Who said that…?
Patience…. Sir.. It’s me….
I can explain….
Transport level security
secures a message only during the
transfer from one point to another point.
In other words.. Only while the
message is on the wire…
HTTPS HTTPS
When we use Transport level security [SSL] our messages are not secured on ‘intermediaries’
Not – just that –we cant even
encrypt only a part of the
message – if we depend on
transport level security
Need a way to get rid of
transport level security….
We can handle
security at the message level…
That way – we can protect
entire message or even just a part of it….
Just –confidentiality is NOT enough – we
need to think about adding Integrity and
Authentication at the Message
level…
Let’s start with one by one – can anyone tell me
how do we support
authentication at the message level….???
It’s simple – I will add a
custom SOAP HEADER
<Credentials><UserName></UserName><Password></Password>
</Credentials>
I don’t like having custom headers… that kills interoperability….
Yes – true – we should not try to re-implement the wheel..
Okay – then somebody explain –what do we have on
our hands…?
Haven’t you guys heard of
WS-Security….
It defines how to achieve
confidentiality, integrity and
authentication on SOAP messages…
Let me clarify – ws-security doesn’t
define new security technology….
It focuses on applying existing
security technologies to SOAP messages…
Wow… exactly what we wanted…
For authentication –
WS-Security defines
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>
I looked into the WS-Security spec – but it does NOT provide enough
details on UsernameToken….
Where else should I look
into..?
Here it is – you need to look into
the UsernameToken Profile spec…
Let’s summarize.. Your findings on
Message level security and
Username Token…
Securing web
services with
Message level
Security
Let’s summarize.. Your findings on
Message level security and
Username Token…1.Defined in WS-Security specification
Let’s summarize.. Your findings on
Message level security and
Username Token…
2.End to end security with support for confidentiality, integrity and authentication
Let’s summarize.. Your findings on
Message level security and
Username Token…3.UsernameToken can be used to authenticate users to the service.
Let’s summarize.. Your findings on
Message level security and
Username Token…4.UsernameToken can have password in clear text or as a digest.
Let’s summarize.. Your findings on
Message level security and
Username Token…5.UsernameToken defined in UsernameToken Profile specification.
Let’s move forward –how about
Encryption with Message level
security
With WS-Security we can encrypt
Body, Header and any of those sub-
structures…
Can somebody explains me how this encryption
happens???
That is basically a shared symmetric
key….
It can be with a key already shared or known to both the
service and the client
We are going off the topic here.. Anyway here’s
some basic explanation….
Symmetric key encryption
uses a shared key for both encryption
and decryption…
Public key encryption
uses different keys for
encryption and
decryption…
Let me add more….
Symmetric key encryption is
fast…
It can operate on large plain
text messages…
Symmetric key encryption uses public
key encryption to manage shared
key distribution securely
Okay..okay.. I know… AES, 3DES are
shared key encryption algorithms
Back to the topic…. WS-Security can also use wrapped key encryption as
well…
Got the point…. If shared key being used then both
client and service have to share the
key…..
If client doesn’t have a key – then a
shared key will be derived through a
key wrapping algorithm with
service’s certificate
That sounds good –even client not
having a cert – we still can have
encryption…. Let’s move to the other
aspect… Integrity…..
WS-Security brings XML Signature in to
SOAP messages to achieve integrity….
BTW.. Signature not only gives you
integrity – but also the non-repudiation
Let me add little more… if you need to know bit more
about XML Signature
XML Signature defines three types
of Signatures –enveloping,
enveloped and detached. WS-
Security utilizes only Detached…
Okay – that’s enough… let’s start building the big picture on WS-
Security now… from what we have
discussed so far….
XML SignatureXML
EncryptionUsername
Token ProfileX.509 Token
Profile
WS - Security
Now we know how to authenticate users with
message level security….
Also how to add
confidentiality…
And.. Integrity and
non-repudiation…
Now – the question is…
who should be able to access our system???
All our employees
need access…
Some of our partner
companies also need access…
We maintain the credentials
of our employees - so we can easily authenticate
them…
How can we authenticate users from partner
companies…
Let’s create individual accounts to
each of them and maintain those records
locally….
What a dumb idea is that… you want
to maintain thousands of
external domain user accounts internally…
We need not to trust each individual belong
to our partner companies… we only trust them until they belong to our partner
companies…
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…
In simple terms now we need to find out a way to establish trust between our partner
companies…
That’s simple… let’s accept requests from out-siders - only if those requests being signed by a trusted
partner…
That sounds cool.. So we’ll be
maintaining a set of public certs of
trusted partners to validate signatures
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…
Listen… I found some thing
interesting – WS-Trust – this exactly
solves our problem….
We’ll be maintaining an STS –which is
connected to our internal user store
Any of our users who needs access to an external
service will send a request to our internal
STS
Need to authenticate him with a
Username Token
Since the internal STS is connected to the internal user store – STS can verify user credentials
Once the credentials
validated, the STS will issue a token with the required claims and sign it by our private key
If the external service trusts our STS – our users will let
in…
Sounds GREAT..!!! It’s the same for
external users who needs access to our services… we will only trust their
STS…
Let me build the BIG
picture once again…..
XML Signature
XML Encryptio
n
Username Token Profile
X.509 Token Profile
WS - Security
WS - Trust
Now we have secured our system…..
Also we know who to trust and how….
But – how do we let other’s who work with us know security standards we
use….
Ah… yes… when external users
accessing our system they must provide their email address
with all their requests….
Not – just that –they also have to
know encryption/signature algorithms we use….
Also – we are not going to encrypt entire message – only some parts – so we need to tell them which parts
to encrypt…
I am going to prepare a document which includes all our
security requirements..
- 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…
Looks good… we need to extend this
further…And this is our security policy…
There should be a standard way of
communicating our security policy to others… let me
Google….
Oh.. Yes.. WS-SecurityPolicy…
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….
We need to have different security policies for
different services… how can we associate a
security policy with a given service….
That’s simple – you can point to a policy
from the WSDL
But .. People may access our service
with SOAP1.1 over HTTP, SOAP 1.2
over HTTPS, SOAP 1.1 over JMS…
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….?
Okay – you want to change the
policy based on the message format and the protocol
That is… you want to have different security policies
for different ‘bindings’… that is possible and it’s
the recommendation…
<wsdl:binding name="HelloServiceSoap11Binding“type="ns:HelloServicePortType">
<wsp:PolicyReference xmlns:wsp=“" URI="#SgnEncrUsername" />
<soap:bindingtransport=http://schemas.xmlsoap.org/soap/httpstyle="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>
Now.. Let’s see how we can express some of our
requirements in WS-SecurityPolicy
UsernameToken should be included….
<wsp:Policy><sp:UsernameToken sp:IncludeToken=“”/>
</wsp:Policy>
We should accept UsernameToken –only if they are
signed…
<sp:SignedSupportingTokens xmlns:sp=""><wsp:Policy><sp:UsernameToken sp:IncludeToken=“"/>
</wsp:Policy></sp:SignedSupportingTokens>
Will be using AES with 256
key size…
<sp:AlgorithmSuite><wsp:Policy>
<sp:Basic256/></wsp:Policy>
</sp:AlgorithmSuite>
We need entire <Body> of the message to be
signed…
<sp:SignedParts><sp:Body/>
</sp:SignedParts>
How about encrypting just a
part of the <Body>….
<sp:EncryptedElements XPathVersion="xs:anyURI"? ... ><sp:XPath>xs:string</sp:XPath>+ ...
</sp:EncryptedElements>
Also… we need to express the
requirement for the required claim set….
<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>
That’s it… let’s move forward… Now we are
secured.. We know who to trust and how
to trust…
We also know how to communicate our
security requirements to the rest….
Let me build the BIG
picture once again…..
XML Signature
XML Encryptio
n
Username Token Profile
X.509 Token Profile
WS - Security
WS - Trust
WS-Policy
WS-SecurityPo
licy
Now we need to find out a way to
put this all-together…
We should not expose all our services
directly to external domain…
Agreed – having multiple entry point into the system could create security holes…
Let’s make sure we authenticate and authorize
users centrally…. And we can load balance on that
end point….
So let’s not expose any of our services to out
side….
We can have proxy service and in front
and only the authenticated and authorized requests will flow through to the internal services…
Authentication Module
Authorization Module
Service A
Service B
Service C
This is a familiar security pattern…
Message Interceptor Gateway…
Authentication Module
Authorization Module
Service A
Service B
Service C
Let me improve the diagram a
bit…..
LDAP
Anybody knows what the authorization module does…? We need fine grained authorization….
Yes.. Exactly… we need a way to say.. Users belong to the role X
can access Resource Y only during this particular time…
We should also be able to say – any
users belong to role Z cannot access any
resources….
That’ s simple – give me your requirement – I’ll right a policy
for it –and Authorization
module will evaluate it…
Oh..NO… don’t panic – we need not to
reinvent the wheel… this what exactly XACML does…..
Sounds good – we should go ahead with
the standards….
I know XACML….
It’s a specification
which defines how to
implement fine grained
authorization in a standard way…
Let me add XACML to out architecture diagram…
Now – under the XACMl
terminology, our Authorization
module will act as the Policy Evaluation Point [PEP]
Authentication Module
Authorization Module [PEP]
Service A
Service B
Service C
LDAP
PEP is not just enough – we need to have a XACML engine
to act as a Policy Decision Point….
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…
Authentication Module
Authorization Module [PEP]
Service A
Service B
Service C
LDAP
PDP
Then again –PDP has to
retrieve XACML policies from a policy store….
Authentication Module
Authorization Module [PEP]
Service A
Service B
Service C
LDAP
PDP
Policy Store
How do we going to add new policies… we also need to have a
policy administration point…
Authentication Module
Authorization Module [PEP]
Service A
Service B
Service C
LDAP
PDP
Policy Store
PAP
Let’s celebrate – we completed the
security design for our backend
services…
Now… we need to think about how we authenticate users at the front-end….
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…
I agree – too many password is a
problem…
See… even within our company we need to have
different passwords to
access different systems…
Okay… let’s solve the too many passwords
problem…
Hey…. We need not to worry about it…
OpenID is for that…
Also – OpenID facilitates
decentralized single sign on…
That’s great – if we use OpenID – we only
sign in once…
How can we implement this…?
First thing… our web application needs to be an OpenID relying party…. That is our application will accept OpenID
logins….
Also – we can run our own
OpenID Provider…
Then all our web applications
will redirect users to our own OpenID Provider
for authentication….
I don’t like OpenID – it’s
phishing heaven…
Hey.. Man… You got it wrong… Phishing is a
separate issue –OpenID doesn’t try to address Phishing…
Then who’s going to solve the
problem of solving
phishing…?
Heard of Information Cards…??? It’s
going to address the issue of phishing…
I know Information cards… it’s an
application of WS-Trust….
We already decided to run an STS – so
we can easily become an information cards
provider too…..
Then what…???
Then – at the OpenID provider – we can
ask users to authenticate with
information cards –in a phishing
resistant manner….
Great.. That sounds perfect….
Okay.. We are almost done…
But… yet we need to figure out how
to implement this…
Remember guys…. The cost matters
the most….
Yes.. We can’t let product vendors
kill us…
So… let’s figure out available open source options
first….
Let’s use WSAS to deploy our services…
Who knows more about WSAS….?
It is an open source, enterprise-
ready, Web services engine
based on Apache Axis2….
Authentication Module
Authorization Module [PEP]
LDAP
PDP
Policy Store
Service C
Service B
Service A
PAP
Now… What.. Anybody knows an open source XACMl engine….
WSO2 Identity Server can do it
for sure…
It’s not just an XACML engine… we can use it as
our OpenID Provider as well…
Also… it comes with an
Information Card provider…
Wow… that looks perfect for us…
let’s see how this fits into our architecture diagram….
Authentication Module
Authorization Module [PEP]
LDAP
Policy StoreService
CService
BService
A
PAP
PDP
Looks good…. hmm… a question – can we deploy Identity Server over our LDAP
server…?
Yes…. That’s a must – we need to use our existing
user store….
That’s easy – you can simply
connect Identity Server to our LDAP server…
Exactly – it’s a matter of a simple
configuration…
Okay…. That sounds good.. So… Identity Server will be our
XACMl engine, OpenID Provider and also the Information
Card provider….
Authentication Module
Authorization Module [PEP]
Policy StoreService
CService
BService
A
PAP
PDP
LDAP
How about the STS…? Can we use Identity Server for
that…?
One more thing… we need the STS to be claim aware…
… it should connect to our LDAP and pick
the user attributes from there… can Identity Server do
it?
Look at this… you can do it with
Identity Server…
… it has this claim management
component… we can easily configure
Identity Server STS to use our LDAP…
Authentication Module
Authorization Module [PEP]
Policy StoreService
CService
BService
A
PAP
PDP
LDAP
STS
Looks perfect…. What else missing…
How about using WSO2 ESB… as
the service bus…?
Yes… that helps us implementing
Message Interceptor
Gateway pattern easily…
See this… it comes with an
Entitlement Mediator –which can
connect to the Identity Server’s XACMl engine…
Wow…!!! I like whatever makes us less work…
Who knows more about
WSO2 ESB….?
It enables the loose-coupling of services, connecting systems
in a managed virtualized manner….
…. allowing administrators to control and direct communication
without disrupting existing applications
Policy StoreService C
Service B
Service A
PAP
PDP
LDAP
STS
Authentication Module
Authorization Module [PEP]
Okay…. Now we need a policy
store….
Let me.. Suggest this time… WSO2
Governance Registry will do
that….
So.. Clever I also found the same… It’s very
much more than just a policy store – or a registry…
…It is an enterprise-ready
open source product for
governing SOA deployments…
Sounds great.. Let’s update the
diagram… we are almost getting to
the end….
Service C
Service B
Service A
PAP
PDP
LDAP
STS
Authentication Module
Authorization Module [PEP]
Looks great..!!! Finally we came up with a fully
open source solution for our security design…
Thanks a lot… for your
participation…
Time for questions… I am sure you guys
have many….???
Thank You…!!!