Summer School - Security in SOA

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

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



Username Token…1.Defined in WS-Security specification



Username Token…

2.End to end security with support for confidentiality, integrity and authentication



Username Token…3.UsernameToken can be used to authenticate users to the service.



Username Token…4.UsernameToken can have password in clear text or as a digest.



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>

http://schemas.xmlsoap.org/soap/http

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>

http://wso2.org/claims

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…


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]


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…



Service A

Service B

Service C

LDAP

PDP

Then again –PDP has to

retrieve XACML policies from a policy store….



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…



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



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



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



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…



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



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



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

&[email protected]

Thank You…!!!

Summer School - Security in SOA

Technology

Transcript of Summer School - Security in SOA