Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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?
Confidentiality
  The assurance
 that a message
has not been read
 by anyone other
than the intended
     reader
Integrity
The assurance
that data is
complete and
  accurate
Authentication
The verification
 of a claimed
   identity
With HTTPS we
    can have
Confidentiality,
 Authentication
       &
   Integrity
Service
         Authentic     Service
         ates to the
           client




Client
Mutual     Service
         Authentic
           ation




Client
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
                encry...
Let’s
summarize..     2.Service
              authenticates
              to the client
                   via
           ...
Let’s      3.Client can
summarize..
              authenticate
                   via
              certificates,
        ...
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
...
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="..."...
I looked into the
WS-Security spec
– but it does NOT
 provide enough
    details on
UsernameToken….
    Where else
  shoul...
Here it is – you
need to look into
       the
UsernameToken
  Profile spec…
Let’s summarize..
Your findings on    Securing
  Message level
   security and       web
Username Token…
                 ...
Let’s summarize..
Your findings on
  Message level
   security and     1.Defined in
Username Token…
                    WS...
Let’s summarize..
Your findings on
  Message level
   security and     2.End to end
Username Token…     security with
    ...
Let’s summarize..
Your findings on
  Message level
   security and     3.UsernameToken
Username Token…
                   ...
Let’s summarize..
Your findings on
  Message level
   security and     4.UsernameToken
Username Token…
                   ...
Let’s summarize..
Your findings on
  Message level
   security and     5.UsernameToken
Username Token…
                   ...
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
  ...
That sounds good –
  even client not
having a cert – we
   still can have
 encryption…. Let’s
 move to the other
aspect… I...
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
 on...
Okay – that’s
 enough… let’s start
  building the big
  picture on WS-
Security now… from
   what we have
 discussed so fa...
WS - Security




                   XML            Username       X.509 Token
XML Signature
                Encryption   ...
Now we
know how to
authenticate
 users with
message level
 security….
Also how to
     add
confidentiali
     ty…
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 ...
Exactly – we only trust
our partners only… But
    we can let their
employees to access our
system if the company
  says i...
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 al...
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
       ...
Let me build
   the BIG
picture once
  again…..
WS - Trust




                 WS - Security



              XML        Username   X.509
   XML
            Encryptio   ...
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
     request...
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 encry...
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 par...
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
       prote...
We need to have different
   security policies for
 different services… how
    can we associate a
 security policy with a...
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...
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
        ...
<wsdl:binding name="HelloServiceSoap11Binding“
              type="ns:HelloServicePortType">
        <wsp:PolicyReference ...
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=“"/>
        </ws...
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-profil...
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…..
WS - Trust
   WS-
SecurityPo
   licy
                              WS - Security



                           XML        ...
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
t...
Authentication Module



     Authorization Module




Service    Service     Service
   A          B           C
This is a familiar
security pattern…
Message Interceptor
    Gateway…
Let me improve
the diagram a
     bit…..



                        Authentication Module



                         Auth...
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
   particula...
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
 ...
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]


LDAP

       Service    Service     Service
          A     ...
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 P...
Authentication Module


         Authorization Module [PEP]


LDAP

       Service    Service     Service
                ...
Then again –
  PDP has to
retrieve XACML
policies from a
 policy store….
Authentication Module


         Authorization Module [PEP]


LDAP

       Service    Service     Service
                ...
How do we going to
add new policies… we
 also need to have a
policy administration
        point…
Authentication Module              PAP



         Authorization Module [PEP]


LDAP

       Service    Service     Servic...
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 tha...
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
 ...
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
  ...
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            PAP



         Authorization Module [PEP]


LDAP


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


         Authorization Module [PEP]
               ...
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
  Ca...
Authentication Module
                                           PAP


  Authorization Module [PEP]
                      ...
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
                                      PAP




                                                     S...
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 engi...
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
PAP
   Authentication Module




                                      STS
 Authorization Module [PEP]    PDP




Service ...
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….
PAP
   Authentication Module




                                            STS
 Authorization Module [PEP]           PDP...
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….???
…also you can reach us
          through…
       http://wso2.com,
http://wso2.com/about/contact
               &
       bi...
Thank You…!!!
Summer School - Security in SOA
Upcoming SlideShare
Loading in …5
×

Summer School - Security in SOA

6,235 views

Published on

Published in: Technology, Education

Summer School - Security in SOA

  1. 1. Security In SOA WSO2 Security Team
  2. 2. Do we need security.. It’s extra cost right…?
  3. 3. Everything comes at a cost… security is not an option
  4. 4. … not an option.. But a must..
  5. 5. Security is NOT an option – it’s a must
  6. 6. Security should be by design – not an after thought
  7. 7. We run everything on HTTPS – aren’t we yet secured…?
  8. 8. It’s NOT the best of the assumptions in the world you could make…
  9. 9. LISTEN..!!! I know HTTPS….
  10. 10. HTTPS helps you transfer data from one point to another point.. Securely..
  11. 11. That is.. HTTPS helps you to encrypt data transferred between a client and a server
  12. 12. That’s all about confidentiality – how about integrity?
  13. 13. Confidentiality The assurance that a message has not been read by anyone other than the intended reader
  14. 14. Integrity The assurance that data is complete and accurate
  15. 15. Authentication The verification of a claimed identity
  16. 16. With HTTPS we can have Confidentiality, Authentication & Integrity
  17. 17. Service Authentic Service ates to the client Client
  18. 18. Mutual Service Authentic ation Client
  19. 19. Don’t think all our clients want to have their own certificates – can we have user name/password instead???
  20. 20. Easy thing – use BasicAuth over HTTPS
  21. 21. Wait…. Basic auth sends username / password in clear text..right?
  22. 22. But – we are on HTTPS and it won’t be an issue… BTW what are the other options…
  23. 23. The other Option is to use Digest…
  24. 24. Let’s summarize.. Securing web services with HTTPS
  25. 25. Let’s summarize.. 1.Provides confidentiality through encryption
  26. 26. Let’s summarize.. 2.Service authenticates to the client via certificates
  27. 27. Let’s 3.Client can summarize.. authenticate via certificates, basic auth / digest
  28. 28. I need a better subject… any guesses???
  29. 29. That’s actually Transport-level security
  30. 30. OMG….I remember somebody saying Transport level security – can be insufficient….??? Who said that…?
  31. 31. Patience…. Sir.. It’s me….
  32. 32. I can explain….
  33. 33. Transport level security secures a message only during the transfer from one point to another point.
  34. 34. In other words.. Only while the message is on the wire…
  35. 35. HTTPS HTTPS
  36. 36. When we use Transport level security [SSL] our messages are not secured on ‘intermediaries’
  37. 37. Not – just that – we cant even encrypt only a part of the message – if we depend on transport level security
  38. 38. Need a way to get rid of transport level security….
  39. 39. We can handle security at the message level…
  40. 40. That way – we can protect entire message or even just a part of it….
  41. 41. Just – confidentiality is NOT enough – we need to think about adding Integrity and Authentication at the Message level…
  42. 42. Let’s start with one by one – can anyone tell me how do we support authentication at the message level….???
  43. 43. It’s simple – I will add a custom SOAP HEADER
  44. 44. <Credentials> <UserName></UserName> <Password></Password> </Credentials>
  45. 45. I don’t like having custom headers… that kills interoperability….
  46. 46. Yes – true – we should not try to re- implement the wheel..
  47. 47. Okay – then somebody explain – what do we have on our hands…?
  48. 48. Haven’t you guys heard of WS- Security….
  49. 49. It defines how to achieve confidentiality, integrity and authentication on SOAP messages…
  50. 50. Let me clarify – ws- security doesn’t define new security technology….
  51. 51. It focuses on applying existing security technologies to SOAP messages…
  52. 52. Wow… exactly what we wanted…
  53. 53. For authentication – WS-Security defines UsernameToken
  54. 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. 55. I looked into the WS-Security spec – but it does NOT provide enough details on UsernameToken…. Where else should I look into..?
  56. 56. Here it is – you need to look into the UsernameToken Profile spec…
  57. 57. Let’s summarize.. Your findings on Securing Message level security and web Username Token… services with Message level Security
  58. 58. Let’s summarize.. Your findings on Message level security and 1.Defined in Username Token… WS-Security specification
  59. 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. 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. 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. 62. Let’s summarize.. Your findings on Message level security and 5.UsernameToken Username Token… defined in UsernameToken Profile specification.
  63. 63. Let’s move forward – how about Encryption with Message level security
  64. 64. With WS-Security we can encrypt Body, Header and any of those sub- structures…
  65. 65. Can somebody explains me how this encryption happens???
  66. 66. That is basically a shared symmetric key….
  67. 67. It can be with a key already shared or known to both the service and the client
  68. 68. We are going off the topic here.. Anyway here’s some basic explanation….
  69. 69. Symmetric key encryption uses a shared key for both encryption and decryption…
  70. 70. Public key encryption uses different keys for encryption and decryption…
  71. 71. Let me add more….
  72. 72. Symmetric key encryption is fast…
  73. 73. It can operate on large plain text messages…
  74. 74. Symmetric key encryption uses public key encryption to manage shared key distribution securely
  75. 75. Okay..okay.. I know… AES, 3DES are shared key encryption algorithms
  76. 76. Back to the topic…. WS-Security can also use wrapped key encryption as well…
  77. 77. Got the point…. If shared key being used then both client and service have to share the key…..
  78. 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. 79. That sounds good – even client not having a cert – we still can have encryption…. Let’s move to the other aspect… Integrity…..
  80. 80. WS-Security brings XML Signature in to SOAP messages to achieve integrity….
  81. 81. BTW.. Signature not only gives you integrity – but also the non-repudiation
  82. 82. Let me add little more… if you need to know bit more about XML Signature
  83. 83. XML Signature defines three types of Signatures – enveloping, enveloped and detached. WS- Security utilizes only Detached…
  84. 84. Okay – that’s enough… let’s start building the big picture on WS- Security now… from what we have discussed so far….
  85. 85. WS - Security XML Username X.509 Token XML Signature Encryption Token Profile Profile
  86. 86. Now we know how to authenticate users with message level security….
  87. 87. Also how to add confidentiali ty…
  88. 88. And.. Integrity and non- repudiation…
  89. 89. Now – the question is… who should be able to access our system???
  90. 90. All our employees need access…
  91. 91. Some of our partner companies also need access…
  92. 92. We maintain the credentials of our employees - so we can easily authenticate them…
  93. 93. How can we authenticate users from partner companies…
  94. 94. Let’s create individual accounts to each of them and maintain those records locally….
  95. 95. What a dumb idea is that… you want to maintain thousands of external domain user accounts internally…
  96. 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. 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. 98. In simple terms now we need to find out a way to establish trust between our partner companies…
  99. 99. That’s simple… let’s accept requests from out-siders - only if those requests being signed by a trusted partner…
  100. 100. That sounds cool.. So we’ll be maintaining a set of public certs of trusted partners to validate signatures
  101. 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. 102. Listen… I found some thing interesting – WS- Trust – this exactly solves our problem….
  103. 103. We’ll be maintaining an STS – which is connected to our internal user store
  104. 104. Any of our users who needs access to an external service will send a request to our internal STS
  105. 105. Need to authenticate him with a Username Token
  106. 106. Since the internal STS is connected to the internal user store – STS can verify user credentials
  107. 107. Once the credentials validated, the STS will issue a token with the required claims and sign it by our private key
  108. 108. If the external service trusts our STS – our users will let in…
  109. 109. Sounds GREAT..!!! It’s the same for external users who needs access to our services… we will only trust their STS…
  110. 110. Let me build the BIG picture once again…..
  111. 111. WS - Trust WS - Security XML Username X.509 XML Encryptio Token Token Signature n Profile Profile
  112. 112. Now we have secured our system…..
  113. 113. Also we know who to trust and how….
  114. 114. But – how do we let other’s who work with us know security standards we use….
  115. 115. Ah… yes… when external users accessing our system they must provide their email address with all their requests….
  116. 116. Not – just that – they also have to know encryption/signature algorithms we use….
  117. 117. Also – we are not going to encrypt entire message – only some parts – so we need to tell them which parts to encrypt…
  118. 118. I am going to prepare a document which includes all our security requirements..
  119. 119. - 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…
  120. 120. Looks good… we need to extend this further…And this is our security policy…
  121. 121. There should be a standard way of communicating our security policy to others… let me Google….
  122. 122. Oh.. Yes.. WS- SecurityPolicy…
  123. 123. 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….
  124. 124. We need to have different security policies for different services… how can we associate a security policy with a given service….
  125. 125. That’s simple – you can point to a policy from the WSDL
  126. 126. But .. People may access our service with SOAP1.1 over HTTP, SOAP 1.2 over HTTPS, SOAP 1.1 over JMS…
  127. 127. 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….?
  128. 128. Okay – you want to change the policy based on the message format and the protocol
  129. 129. That is… you want to have different security policies for different ‘bindings’… that is possible and it’s the recommendation…
  130. 130. <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>
  131. 131. Now.. Let’s see how we can express some of our requirements in WS-SecurityPolicy
  132. 132. UsernameToken should be included….
  133. 133. <wsp:Policy> <sp:UsernameToken sp:IncludeToken=“”/> </wsp:Policy>
  134. 134. We should accept UsernameToken – only if they are signed…
  135. 135. <sp:SignedSupportingTokens xmlns:sp=""> <wsp:Policy> <sp:UsernameToken sp:IncludeToken=“"/> </wsp:Policy> </sp:SignedSupportingTokens>
  136. 136. Will be using AES with 256 key size…
  137. 137. <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256/> </wsp:Policy> </sp:AlgorithmSuite>
  138. 138. We need entire <Body> of the message to be signed…
  139. 139. <sp:SignedParts> <sp:Body/> </sp:SignedParts>
  140. 140. How about encrypting just a part of the <Body>….
  141. 141. <sp:EncryptedElements XPathVersion="xs:anyURI"? ... > <sp:XPath>xs:string</sp:XPath>+ ... </sp:EncryptedElements>
  142. 142. Also… we need to express the requirement for the required claim set….
  143. 143. <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>
  144. 144. That’s it… let’s move forward… Now we are secured.. We know who to trust and how to trust…
  145. 145. We also know how to communicate our security requirements to the rest….
  146. 146. Let me build the BIG picture once again…..
  147. 147. WS - Trust WS- SecurityPo licy WS - Security XML Username X.509 XML WS-Policy Encryptio Token Token Signature n Profile Profile
  148. 148. Now we need to find out a way to put this all- together…
  149. 149. We should not expose all our services directly to external domain…
  150. 150. Agreed – having multiple entry point into the system could create security holes…
  151. 151. Let’s make sure we authenticate and authorize users centrally…. And we can load balance on that end point….
  152. 152. So let’s not expose any of our services to out side….
  153. 153. We can have proxy service and in front and only the authenticated and authorized requests will flow through to the internal services…
  154. 154. Authentication Module Authorization Module Service Service Service A B C
  155. 155. This is a familiar security pattern… Message Interceptor Gateway…
  156. 156. Let me improve the diagram a bit….. Authentication Module Authorization Module LDAP Service Service Service A B C
  157. 157. Anybody knows what the authorization module does…? We need fine grained authorization….
  158. 158. Yes.. Exactly… we need a way to say.. Users belong to the role X can access Resource Y only during this particular time…
  159. 159. We should also be able to say – any users belong to role Z cannot access any resources….
  160. 160. That’ s simple – give me your requirement – I’ll right a policy for it –and Authorization module will evaluate it…
  161. 161. Oh..NO… don’t panic – we need not to reinvent the wheel… this what exactly XACML does…..
  162. 162. Sounds good – we should go ahead with the standards….
  163. 163. I know XACML….
  164. 164. It’s a specification which defines how to implement fine grained authorization in a standard way…
  165. 165. Let me add XACML to out architecture diagram…
  166. 166. Now – under the XACMl terminology, our Authorization module will act as the Policy Evaluation Point [PEP]
  167. 167. Authentication Module Authorization Module [PEP] LDAP Service Service Service A B C
  168. 168. PEP is not just enough – we need to have a XACML engine to act as a Policy Decision Point….
  169. 169. 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…
  170. 170. Authentication Module Authorization Module [PEP] LDAP Service Service Service PDP A B C
  171. 171. Then again – PDP has to retrieve XACML policies from a policy store….
  172. 172. Authentication Module Authorization Module [PEP] LDAP Service Service Service PDP A B C Policy Store
  173. 173. How do we going to add new policies… we also need to have a policy administration point…
  174. 174. Authentication Module PAP Authorization Module [PEP] LDAP Service Service Service PDP A B C Policy Store
  175. 175. Let’s celebrate – we completed the security design for our backend services…
  176. 176. Now… we need to think about how we authenticate users at the front-end….
  177. 177. 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…
  178. 178. I agree – too many password is a problem…
  179. 179. See… even within our company we need to have different passwords to access different systems…
  180. 180. Okay… let’s solve the too many passwords problem…
  181. 181. Hey…. We need not to worry about it… OpenID is for that…
  182. 182. Also – OpenID facilitates decentralized single sign on…
  183. 183. That’s great – if we use OpenID – we only sign in once…
  184. 184. How can we implement this…?
  185. 185. First thing… our web application needs to be an OpenID relying party…. That is our application will accept OpenID logins….
  186. 186. Also – we can run our own OpenID Provider…
  187. 187. Then all our web applications will redirect users to our own OpenID Provider for authentication….
  188. 188. I don’t like OpenID – it’s phishing heaven…
  189. 189. Hey.. Man… You got it wrong… Phishing is a separate issue – OpenID doesn’t try to address Phishing…
  190. 190. Then who’s going to solve the problem of solving phishing…?
  191. 191. Heard of Information Cards…??? It’s going to address the issue of phishing…
  192. 192. I know Information cards… it’s an application of WS- Trust….
  193. 193. We already decided to run an STS – so we can easily become an information cards provider too…..
  194. 194. Then what…???
  195. 195. Then – at the OpenID provider – we can ask users to authenticate with information cards – in a phishing resistant manner….
  196. 196. Great.. That sounds perfect….
  197. 197. Okay.. We are almost done…
  198. 198. But… yet we need to figure out how to implement this…
  199. 199. Remember guys…. The cost matters the most….
  200. 200. Yes.. We can’t let product vendors kill us…
  201. 201. So… let’s figure out available open source options first….
  202. 202. Let’s use WSAS to deploy our services…
  203. 203. Who knows more about WSAS….?
  204. 204. It is an open source, enterprise- ready, Web services engine based on Apache Axis2….
  205. 205. Authentication Module PAP Authorization Module [PEP] LDAP PDP Service Service Service A B C Policy Store
  206. 206. Now… What.. Anybody knows an open source XACMl engine….
  207. 207. WSO2 Identity Server can do it for sure…
  208. 208. It’s not just an XACML engine… we can use it as our OpenID Provider as well…
  209. 209. Also… it comes with an Information Card provider…
  210. 210. Wow… that looks perfect for us… let’s see how this fits into our architecture diagram….
  211. 211. Authentication Module PAP Authorization Module [PEP] PDP LDAP Service Service Service A B C Policy Store
  212. 212. Looks good…. hmm… a question – can we deploy Identity Server over our LDAP server…?
  213. 213. Yes…. That’s a must – we need to use our existing user store….
  214. 214. That’s easy – you can simply connect Identity Server to our LDAP server…
  215. 215. Exactly – it’s a matter of a simple configuration…
  216. 216. Okay…. That sounds good.. So… Identity Server will be our XACMl engine, OpenID Provider and also the Information Card provider….
  217. 217. Authentication Module PAP Authorization Module [PEP] PDP Service Service Service LDAP A B C Policy Store
  218. 218. How about the STS…? Can we use Identity Server for that…?
  219. 219. One more thing… we need the STS to be claim aware…
  220. 220. … it should connect to our LDAP and pick the user attributes from there… can Identity Server do it?
  221. 221. Look at this… you can do it with Identity Server…
  222. 222. … it has this claim management component… we can easily configure Identity Server STS to use our LDAP…
  223. 223. Authentication Module PAP STS Authorization Module [PEP] PDP Service Service Service LDAP A B C Policy Store
  224. 224. Looks perfect…. What else missing…
  225. 225. How about using WSO2 ESB… as the service bus…?
  226. 226. Yes… that helps us implementing Message Interceptor Gateway pattern easily…
  227. 227. See this… it comes with an Entitlement Mediator – which can connect to the Identity Server’s XACMl engine…
  228. 228. Wow…!!! I like whatever makes us less work…
  229. 229. Who knows more about WSO2 ESB….?
  230. 230. It enables the loose- coupling of services, connecting systems in a managed virtualized manner….
  231. 231. …. allowing administrators to control and direct communication without disrupting existing applications
  232. 232. PAP Authentication Module STS Authorization Module [PEP] PDP Service Service Service LDAP Policy Store A B C
  233. 233. Okay…. Now we need a policy store….
  234. 234. Let me.. Suggest this time… WSO2 Governance Registry will do that….
  235. 235. So.. Clever  I also found the same… It’s very much more than just a policy store – or a registry…
  236. 236. …It is an enterprise-ready open source product for governing SOA deployments…
  237. 237. Sounds great.. Let’s update the diagram… we are almost getting to the end….
  238. 238. PAP Authentication Module STS Authorization Module [PEP] PDP Service Service Service LDAP A B C
  239. 239. Looks great..!!! Finally we came up with a fully open source solution for our security design…
  240. 240. Thanks a lot… for your participation…
  241. 241. Time for questions… I am sure you guys have many….???
  242. 242. …also you can reach us through… http://wso2.com, http://wso2.com/about/contact & bizdev@wso2.com
  243. 243. Thank You…!!!

×