January 19, 2005

1
January 19, 2005
xmlCoP Interoperable Trust Networks

• Andrew Nash
• Chief Technology Officer, Reactivity

2
Web Service Aggregator ExampleBrowser Redirection

• Yahoo shopping portal searches for products and
  lowest prices across all storefronts
• Search results displayed at Yahoo
• Users redirected to backend web sites belonging
  to vendors
• Interactions with vendors use browser redirects
• Single Sign On achieved using SAML assertions

HTTPRedirection
3
Web Service Aggregator Example

• Yahoo shopping portal searches for products and
  lowest prices across all storefronts
• Results aggregated at Yahoo instead of
  redirecting users to backend web sites
• Common shopping, payment, shipping and query
  interfaces provided through Yahoo portal
• Interactions with vendors use Web Service
  transactions
• Complimentary to classic Liberty Federation using
  browser redirection avoids changing look and
  feel

WebServices
HTML
4
User and Transactional Security
WebServers
Business transaction model based on XML and Web
Services Applications exchange transactions
users are not directly involved Sender may not
originate transactions does not know the final
destination Security requirements are based on
the content of transaction not the identity of
the applications
Transactional Security
User Security
5
Overlapping Web Security Standards
User Federation
Web Services
WS-SecureConversation
Liberty ID FF
WS-Federation WS-Federation
WS-Trust
SAML
WSS
SOAP
HTTP
6
Security Assertions Markup Language

• Framework for exchanging security assertions
• Profiles will map assertion use to messaging
  frameworks
• Use Cases
• Single Sign-On
• Web user authenticates at a Web site. Web user
  then accesses another Web site without
  re-authenticating
• Authorization Service
• User attempts to access a resource or service.
  The access controller for that resource (policy
  enforcement point) checks the user's rights with
  a policy decision point
• Attribute Service
• User moves from one web site to another
  customer loyalty information or context is passed
  to simplify the users experience as part of a
  federated information services

7
SAML Domain Model
8
SAML Assertion Request Protocol
9
Where Does Liberty Fit?

• Liberty Alliance is focused on SSO and user
  information sharing using a federated identity
  model
• Liberty is an application domain standard
• Builds on standards defined elsewhere to solve
  the application domain problems
• Liberty will uses SAML V2 for infrastructure
  support
• Liberty move to WSS

Liberty Alliance
Other Federation Enabling Standards
WS Security
SAML
SOAP
10
Liberty SAML
Liberty Identity Provider
Liberty Service Provider
AuthenticationAuthority
AttributeAuthority
Attribute Assertion
Authentication Assertion
Authorization Decision Assertion
SAML
SAML
SOAP Foundation
11
Liberty Identity Federation
Circle of Trust
MyCompany.com (ID Provider)
BusUnit1.com
PartnerA.com
Federated ID SecurityDomainBusUnit1.com"
NameJack" SecurityDomainPartnerA.com"
NameJohn"
Federated ID SecurityDomainBusUnit1.com"
Name"dTvIiRcMlpCqV6xX" SecurityDomainPartnerA.
com" Name"pfk9uzUN9JcWmk4RF"
12
Liberty/SAML Web SSO Model
Circle of Trust
Identity Provider
Service Provider
Authentication Authority Attribute Authority
13
IBM/Microsoft Web Services Architecture
WS-Secure Conversation
WS-Federation
WS-Authorization
WS-Policy
WS-Trust
WS-Privacy
WS-Security
SOAP Foundation
StandardsBody
PublishedSpecs
UnpublishedSpecs
14
Whats in a Name?

• SOAP Message Security only, does not cover other
  aspects of security for web services
• Issuance and exchange of security tokens not
  establishment and validation of trust
• Policy definition framework, does not describe
  how policies are managed
• How security information is passed, not how
  security policy is distributed or enforced

• WS-Security(aka WSS)
• WS-Trust
• WS-Policy
• WS-SecurityPolicy

15
WS-Security

• Describes how to secure SOAP messages
• Defines how to identify the creator of the
  message
• Carries multiple credential types including
• Message Integrity
• Integrity of all or part of a message
• Builds on XML-Signature
• Supports multiple and overlapping signatures
• Message Confidentiality
• Confidentiality of all or part of a message
• Builds on XML-Encrypt

16
Securing SOAP Messages

• WSS information stored in SOAP security header
• One or more security tokens carried in header to
  identify the transaction
• XML Signature blocks may be carried to provide
  integrity and link the identity to the
  transaction
• Key information within the security token may be
  used
• Privacy provided using XML encryption

wsse
security token
key info
signature
17
Security Tokens

• Separate profiles define the format and usage
  rules of various token types
• Username/password
• Binary Security Tokens
• Encoding type like Base-64 allows inclusion in
  XRML
• X.509
• Kerberos
• XML Tokens
• SAML
• XRML
• Common Biometric Format
• Great but where do we get these security tokens
  from?

18
WS-Trust

• A Security Token Service (STS) issues tokens that
  can be used in WSS
• Forms the basis for several other WS- standards
  (coming up)
• Token issuance, renewal and validation are
  handled by an STS
• The services of an STS may be required by web
  services and their clients
• Security tokens are a collection of claims about
  a resource
• The claims presented in security token are
  examined in the light of the policy controlling
  the web service

19
Web Services Trust Model
Policy
SecurityTokenService
SecurityToken
Claims
Policy
Requestor
SecurityToken
Claims
Policy
WebService
SecurityToken
Claims
20
WS-Policy

• Framework for defining policies parameters or
  assertions that affect web services
• WS-PolicyAttachment describes how policies are
  associated with a resource
• WS-PolicyAssertions defines a common set of
  assertions
• Establishes a mechanism for exchanging
  requirements between a web services provider and
  client
• Provides machine readable policy statements that
  describe the operational parameters for
  interactions between a service and a client
• Supports negotiation of the parameters defined
  within a policy

21
WS-Policy

• Policy is defined as a series of assertions
• Each has a usage (required, optional, rejected
  etc) and preference (ranking of this assertion)
• Operators (all, exactlyone, oneormore) define how
  to evaluate child assertions
• WS-PolicyAssertions define common assertion types
• (TextEncoding, Language, SpecVersion)
• WS-PolicyAttachment supports
• a standalone option that allows a standalone
  description of the web service that the policy is
  associated with
• Or integrated with WSDL where a series of
  pointers reference a policy

22
WS-SecurityPolicy

• Defines assertions that address security
  parameters
• SecurityToken identifies
• Types of security tokens accepted
• Issuer of the token
• Optional details about particular token types
  (e.g. what set of user names are supported)
• Integrity
• What parts of a message are signed
• XML signature algorithms used
• Parameters defining how the algorithm should be
  executed

23
WS-SecurityPolicy

• Confidentiality
• What parts of a message are encrypted
• Algorithms and parameters used
• Visibility
• What parts of a message must be visible to
  intermediary web services
• SecurityHeader
• Constrains how the security header is processed
• MessageAge
• Acceptable message lifetime based on the WSS
  timestamp

24
WS-SecureConversation

• Eliminates the overhead of carrying and
  validating authentication information in each
  message
• Establishes a mutually authenticated security
  context
• Multiple messages may be exchanged within this
  context
• Creates an end-to-end secured channel at the
  application layer
• Like SSL it is provides a session oriented
  authenticated and encrypted data pipe
• SSL is restricted to point-to-point sessions
  between intermediate nodes

25
WS-Federation

• Describes how to share identities and attributes
  across multiple trust domains
• Layered on WS-Trust
• Tokens issued by one domains STS are used to
  request a new security token from the STS of
  another domain

26
Federation Token Exchanges
Trust Domain 1
Trust Domain 2
Policy
Trust Relationship
SecurityTokenService
SecurityToken
1
4
2
Policy
Policy
WebService
Requestor
3
SecurityToken
SecurityToken
27
WS-Federation Sequence
Web ServiceSTS
RequestorSTS
Requestor
Web Service
Rqst Security Token
Issue Security Token
Rqst Security Token with Token Reference
Issue Security Token from Service Domain
Invoke Service w Security Token
Validate Security Token
Approve Security Token
Return Service Response
28
Security and Privacy - Today

• Today transactions are secured using WSS toolkits
  to implement the Web Service security standards
• Usually support for X.509 Certificates or
  password credentials

SWS password / X.509 Cert
HTML
29
Security and Privacy Tomorrow

• SAML Tokens for use in WSS security headers to
  support Federated Identities
• User Authentication supplied by CT/FIM
• Requests SAML assertions from SAML authority to
  build SAML tokens
• Crossover from Browser/User security world to Web
  Services

WSS withSAML
WSS SAML Token
HTML
Login
SAML Assertions
SAML Authority
30
Security and Privacy Tomorrow

• Web services infrastructure moves toward WS-Trust
  credential servers for token issuance and support
  of WS-Federation
• WS-Trust toolkits provide messaging and protocol
  support for development of clients and servers

WS-Trust
WSSToken
WS-Federation Ids
WS-Trust Server Tk
Tokens
WS-TrustCredential Server
31
Web Service security dilemma
UserInterface
Security Layer
DatabaseIntegration
Business Logic
CIOs and IT Directors do not believe application
programmers can verifiably implement enterprise
security policies Use of toolkits does not scale
to even modest deployments Tools do not exist to
define, verify or modify security
policy Transactions must be monitored and
audited Security policy management must be
federated
32
Perimeters?
33
Cherry Picking from Different Domains
NetworkDomains
34
Controlling a Service Oriented Application
35
Reactivity in the enterprise
36
The Reactivity Gateway Message Pipeline
37
The Reactivity Gateway Message Pipeline
38
Multi-layer mediation of transactions

• Data transformation
• ex. service virtualization
• Security Credential Mapping
• ex. SSL external to SAML internal
• Transport mapping
• ex. XML/MQ to SOAP/HTTPS
• Cross-layer information sharing with advanced
  header manipulation

39
Reactivitys Policy Aware Core
Functions
Benefits
Delegate Create Policy

• Optional sub-polices allow secure separation
  between projects, business units, geographies

Collaborate Compare Policy

• Visually identify policy conflicts
• Multi-stage approval for efficient workflow

Deploy Policy and Mark Messages

• Policy version linked to message pair ensuring
  consistency and auditability
• One-click deploy rollback for efficiency

Report Audit

• Policy aware event and message logs enable rapid
  issue identification and accurate audits

Policy Aware Core ensures XML Web services
security with speed, flexibility and visibility
Control
Agility
40
Reactivitys Vision of XML Infrastructure
Application Infrastructure Server/Application
Based Functions
XML Infrastructure XML Message based functions
A new layer required for connecting distributed
XML web services and enforcing message transport
policies
Network Infrastructure Packet based functions