the secured enterprise: leverage openid with web services
DESCRIPTION
SOA security needs to be by design, not as an afterthought. This session will demonstrate implementing Message Interceptor Gateway security pattern with WSO2 ESB, WSO2 WSAS and WSO2 Identity Server – together with the OpenID/Information Cards integration pattern at the front end. The Message Interceptor Gateway pattern provides a single entry point and allows centralization of security enforcement for incoming and outgoing messages. Further, this session explores adding authentication and fine grained authorization for web services.TRANSCRIPT
The Secured Enterprise: Leverage OpenID with Web
Services
OSCON July 20 – 24 , 2009 San Jose, California
..
Prabath SiriwardenaTechnical Lead & Product Manager
WSO2
WSO2 is an innovative Open Source technology company devoted to building Web services middleware for your SOA. Offering leading products, support and other services, WSO2 was founded in August 2005. It is a global corporation with offices located in USA, UK and Sri Lanka.
40,000,000credit card numbers stolen
Security needs to be by design
NOT an after thought
What do we need to secure…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
We have a bunch of services
already developed and some under development….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Yes…. we need to make sure all the data transferred are secured….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
How about securing data
transfer between service and the client through
HTTPS….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
HTTPS is not bad.. But still it
has certain limitations…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Transport level encryption
Point to point
Entire message needs to be encrypted
Adds less weight on message payload
Applies only to HTTP
NO
TES
……
H
TTP
S
How about message level
security?
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
End to End
Parts of the message can be encrypted
Adds more weight on message payload
Transport Independent
NO
TES
……
M
ES
SA
GE L
EV
EL S
EC
UR
ITY
Yes – let’s finalize on
Message level security….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
How can we use Message Level
Security to protect our services…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Confidentiality
NO
TES
……
C-I
-A
Integrity
Authentication
The assurance that a message has not been read by anyone other than the intended reader
NO
TES
……
CO
NFID
EN
TIA
LITY
The assurance that data is complete and accurate
NO
TES
……
IN
TEG
RITY
The verification of a claimed identity
NO
TES
……
AU
TH
EN
TIC
ATIO
N
Can we make sure we
interoperate with the rest…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Yes… we need not to re-implement the wheel… what is the standard to
achieve C-I-A with message
level security…?
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Defines how to achieve confidentiality, integrity and authentication with SOAP messages
NO
TES
……
WS
-SEC
UR
ITY
Does not define a new security technology only focuses on applying existing security technologies to SOAP messages
With UserNameToken defined in WS-
Security enables us to authenticate users
with username/password…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
NO
TES
……
US
ER
NA
METO
KEN <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>
WS-Security brings XML Encryption to
enable confidentiality in SOAP Messages….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Shared Key
Key Wrapping
NO
TES
……
EN
CR
YP
TIO
N
A shared key for both encryption and decryption
Can operate on large plain text messages
NO
TES
……
S
HA
RED
KEY
Uses public key encryption to manage shared key distribution securely
Fast
Both the client & the service need not to have a certificate
A shared key is derived through the service’s certificate
NO
TES
……
K
EY
WR
AP
PIN
G
Further communication being encrypted with the derived shared key
Integrity comes through the XML
Signature….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Integrity
Non repudiation
NO
TES
……
S
IG
NA
TU
RE
NO
TES
……
XML SignatureXML
EncryptionUsername
Token ProfileX.509 Token
Profile
WS - Security
Okay… now all our services are
secured with ws-security… What is
next?
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
We need to see who should be given access to our services….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Definitely all the internal users…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
…also some of our partner
companies….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Okay… we can easily
authenticate internal users
with UserNameToken - since we have their credentials
internally….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
But we don’t maintain
credentials of external users… coming from our
partner companies….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
We need not to maintain
external user credentials… we
only need to trust our partners….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
…and that is what WS-Trust
does….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
NO
TES
……
W
S-T
RU
ST
We need not to authenticate individual external users
NO
TES
……
TR
US
TIN
G P
AR
TEN
ER
S
We only TRUST external partners
All the requests coming through external users need to be signed by the corresponding partner companies
Only the requests signed by TRUSTED partners will let in
…also our users need access to
external systems.. Out of our domain….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
That is exactly the other side of
what we just discussed.. We
need to maintain an internal STS
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
All the requests going out side from internal users need to have a security token issued by the internal STS
NO
TES
……
S
TS
Internal users should authenticate them selves with the internal STS – prior to obtaining a security token
External services need to trust our STS
NO
TES
……
XML Signature
XML Encryption
Username Token Profile
X.509 Token Profile
WS - Security
WS - Trust
Now… the question is how are we going to
communicate our security
requirements to the rest…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Let’s first list the security
requirements…..
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
SEC
UR
ITY
REQ
UIR
EM
EN
TS Internal users should authenticate with
user name / password when accessing services directly
SEC
UR
ITY
REQ
UIR
EM
EN
TS External users should present a security
token from a trusted STS
SEC
UR
ITY
REQ
UIR
EM
EN
TS Email address should be present in the
security token comes with the external users.
SEC
UR
ITY
REQ
UIR
EM
EN
TS Only some parts of the message needs to be
encrypted.
SEC
UR
ITY
REQ
UIR
EM
EN
TS Encryption algorithm should be AES.
SEC
UR
ITY
REQ
UIR
EM
EN
TS Encryption key size needs to be 256.
SEC
UR
ITY
REQ
UIR
EM
EN
TS All the parts in the <Body> must be signed
We need a way to express all
these in a standard way….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Ws-security policy exactly addresses that…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Used to express security requirements of a Web service according to, What needs to be protected… What tokens to use… Algorithms, reference types, etc….
NO
TES
……
WS
-SEC
UR
ITY
PO
LIC
Y
Security policies can be defined at the binding level / operation level
NO
TES
……
XML Signature
XML Encryption
Username Token Profile
X.509 Token Profile
WS - Security
WS - Trust
WS-Policy
WS-SecurityPo
licy
Everything looks good…. Is there a way we could make sure we
strictly follow the security polices
defined…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Okay – that means we need to validate each and
every service developed…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Yes – validation needs to happen at two stages…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Design time validations will make sure we
adhere to proper standards and polices at the
time we develop …
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Runtime validations will make sure we
evaluate all the requests coming in
against the defined security
policies….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Design time governance
NO
TES
……
S
OA
GO
VER
NA
NC
E
Runtime time governance
NO
TES
……
D
ES
IG
N T
IM
E G
OV
ER
NA
NC
E
NO
TES
……
D
ES
IG
N T
IM
E G
OV
ER
NA
NC
E
NO
TES
……
D
ES
IG
N T
IM
E G
OV
ER
NA
NC
E
NO
TES
……
D
ES
IG
N T
IM
E G
OV
ER
NA
NC
E
MONITORING
Yet… we haven’t figure out how to enforce policies
on users – or the requests coming through to our
services…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Yes… we need to make sure all the requests comply with the defined security polices….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
NO
TES
……
M
ES
SA
GE I
NTER
CEP
TO
R
GA
TEW
AY
PA
TTER
N
Provides a single entry point and allows centralization of security enforcement for incoming and outgoing messages.
NO
TES
……
M
ES
SA
GE I
NTER
CEP
TO
R
GA
TEW
AY
PA
TTER
N
Helps to apply transport-level and message-level security mechanisms required for securely communicating with a Web services endpoint.
All the services can be deployed inside WSO2 Web Services Application Server [WSAS] – not publicly accessible
NO
TES
……
M
IG
-IM
PLEM
EN
TA
TIO
N
An open source web services engine powered by Apache Axis2
NO
TES
……
M
IG
-IM
PLEM
EN
TA
TIO
N
NO
TES
……
M
IG
-IM
PLEM
EN
TA
TIO
N
Service C
Service B
Service A
NO
TES
……
M
IG
-IM
PLEM
EN
TA
TIO
N
Service C
Service B
Service A
NO
TES
……
M
IG
-IM
PLEM
EN
TA
TIO
N
Service C
Service B
Service A
Authentication Module
Authorization Module [PEP]
LDAP
NO
TES
……
W
SO
2 E
SB
–S
EC
UR
IN
G P
RO
XY
S
ER
VIC
ES
NO
TES
……
W
SO
2 E
SB
–S
EC
UR
IN
G P
RO
XY
S
ER
VIC
ES
NO
TES
……
W
SO
2 E
SB
–S
EC
UR
IN
G P
RO
XY
S
ER
VIC
ES
NO
TES
……
MIG
-IM
PLEM
EN
TA
TIO
N
Service C
Service B
Service A
Authentication Module
Authorization Module [PEP]
LDAP
PAP
PDP
STS
Claim-based security token service -mapping user attributes to defined claims, which can be used to enable identity federation with claim aware web services.
NO
TES
……
W
SO
2 I
DEN
TITY
SER
VER
XACML Policy Administration Point & Policy Decision Point
NO
TES
……
W
SO
2 I
DEN
TITY
SER
VER
-S
TS
NO
TES
……
W
SO
2 I
DEN
TITY
SER
VER
-S
TS
NO
TES
……
W
SO
2 I
DEN
TITY
SER
VER
–P
AP
/P
DP
NO
TES
……
W
SO
2 I
DEN
TITY
SER
VER
–P
AP
/P
DP
NO
TES
……
W
SO
2 I
DEN
TITY
SER
VER
PAP
PDP
STS
WS-Security / WS-Trust / WS-Security Policy
Message Interceptor Gateway Pattern
NO
TES
……
S
UM
MA
RY
WSO2 Governance Registry / WSO2 WSAS / WSO2 ESB / WSO2 Identity Server
We have secured access to all our
backend services…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Let’s think of securing the front
end….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Yes… our backend services can be
accessed through either with a
direct client or with our web
portal….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Also we already have different
web applications managed
internally…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
And it’s hard to have different credentials to
each web application….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Let’s redesign authentication for all our web applications….
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
One more thing… we also need to give access to
external users to the web portal as
well…
RO
UN
D T
AB
LE D
IS
CU
SS
IO
N
Too many passwords
NO
TES
……
PR
OB
LEM
S T
O B
E
AD
DR
ES
SED
Single Sign On
Giving access to external domain users
Decentralized Single Sign On
NO
TES
……
OP
EN
ID
Single User Profile
Identity Federation
NO
TES
……
OP
EN
ID
LO
GIN
FO
R W
EB
PO
RTA
L
OP
BROWSER
WEB PORTAL
WEB PORTAL
NO
TES
……
OP
EN
ID
LO
GIN
FO
R W
EB
PO
RTA
L
OP
BROWSER
NO
TES
……
OP
EN
ID
LO
GIN
FO
R W
EB
PO
RTA
L
OP
BROWSER
WEB PORTAL
NO
TES
……
OP
EN
ID
LO
GIN
FO
R W
EB
PO
RTA
L
OP
BROWSER
WEB PORTAL
NO
TES
……
OP
EN
ID
LO
GIN
FO
R W
EB
PO
RTA
L
WEB PORTAL
OP
BROWSER
NO
TES
……
OP
EN
ID
+ I
NFO
RM
ATIO
N C
AR
DS
OP
NO
TES
……
WS
O2
ID
EN
TITY
SER
VER
OP
OpenID Provider
InfoCard Provider
NO
TES
……
TR
US
TED
SU
B S
YS
TEM
WEB PORTAL
NO
TES
……
TR
US
TED
SU
B S
YS
TEM
OPWEB PORTAL
WS-Security / WS-Trust / WS-Security Policy
Message Interceptor Gateway Pattern
NO
TES
……
S
UM
MA
RY
WSO2 Governance Registry / WSO2 WSAS / WSO2 ESB / WSO2 Identity Server
OpenID + InfoCard
Trusted Sub System Pattern
http://wso2.com
DIS
CU
SS
IO
N…
... http://wso2.com/about/contact
Thank You…!!!