1	January 19, 2005 Andrew Nash Chief Technology Officer, Reactivity
2	Web Service Aggregator Example Browser 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
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
4	User and Transactional Security
5	Overlapping Web Security Standards
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
10	Liberty & SAML
11	Liberty Identity Federation
12	Liberty/SAML Web SSO Model
13	IBM/Microsoft Web Services Architecture
14	What’s in a Name? WS-Security (aka WSS) WS-Trust WS-Policy WS-SecurityPolicy 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
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
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
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
27	WS-Federation Sequence
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
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
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
31	Web Service security dilemma
32	Controlling a Service Oriented Application
33	Reactivity in the enterprise
34	The Reactivity Gateway Message Pipeline
35	The Reactivity Gateway Message Pipeline
36	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
37	Reactivity’s Policy Aware Core
38	Reactivity’s Vision of XML Infrastructure